-
Notifications
You must be signed in to change notification settings - Fork 38.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
UrlResource should leniently handle HTTP endpoints which do not support HEAD #34217
Comments
@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. |
@jhoeller I'm using springboot. What is the preferred way to switch my spring version since 6.2.3 isn't available within a released springboot version? Do I just bump up my core version? |
@chubbard it should be sufficient to add |
@chubbard you can override the Spring Framework version in your build tool with the version property managed by Boot. For Gradle, this is:
You will need to add the repo.spring.io repository configuration to your build. You can get a sample by creating an app on start.spring.io with a Boot snapshot version. |
@chubbard, instructions for working with snapshots is also documented in our wiki. |
I just tested it, and viola it worked! Thank you so much for fixing this so quickly. I only wish I was as quick to validate. |
Good to hear! No worries, this was timely pre-release testing in any case :-) |
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:
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.
The text was updated successfully, but these errors were encountered: