UrlResource should leniently handle HTTP endpoints which do not support HEAD

[chubbard]

Problem:
Spring frequently uses Resource implementations often. I encountered a problem with URLResource if the underlying resource doesn't implement the HTTP HEAD verb. I found this problem when using spring security saml2 provider when parsing saml metadata. The code below will demonstrate the problem:

AssertingPartyMetadataRepository repo = OpenSaml4AssertingPartyMetadataRepository.withTrustedMetadataLocation("https://mocksaml.com/api/saml/metadata").build();

That URL does exist, but it just doesn't respond to HEAD requests. Using a GET it will return the content.

The exists(), checkReadable(),contentLength(), lastModified(), methods all set the HTTP method to HEAD (see AbstractFileResolvingResource). However, not all resources implement HEAD. Because this is so low level there are whole parts of the API that would need to be re-implemented work around this. I don't see a workaround for this ATM.

If the case of a 405 was explicitly handled it could revert to a GET request which would work even if it may not be as performant. Spring could recover from this case and allow people to continue using Resource based APIs.

Expected
If URLResource / AbstractFileResolvingResource gracefully fell back to GET when encountering a 405 it could recover gracefully and the URLResource would just work as expected.

[jhoeller]

@chubbard please give a 6.2.3 snapshot a try if you have the chance, and let me know whether the HEAD/GET fallback works for you.