Skip to content
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

Closed
chubbard opened this issue Jan 9, 2025 · 7 comments
Closed
Assignees
Labels
in: core Issues in core modules (aop, beans, core, context, expression) type: enhancement A general enhancement
Milestone

Comments

@chubbard
Copy link

chubbard commented Jan 9, 2025

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.

@spring-projects-issues spring-projects-issues added the status: waiting-for-triage An issue we've not yet triaged or decided on label Jan 9, 2025
@snicoll snicoll added the in: web Issues in web modules (web, webmvc, webflux, websocket) label Jan 9, 2025
@jhoeller jhoeller added in: core Issues in core modules (aop, beans, core, context, expression) type: enhancement A general enhancement and removed in: web Issues in web modules (web, webmvc, webflux, websocket) status: waiting-for-triage An issue we've not yet triaged or decided on labels Jan 12, 2025
@jhoeller jhoeller self-assigned this Jan 12, 2025
@jhoeller jhoeller added this to the 6.2.x milestone Jan 12, 2025
@jhoeller jhoeller changed the title URLResource requires resources support HEAD URLResource should leniently handle resources which do not support HTTP HEAD Jan 20, 2025
@jhoeller jhoeller modified the milestones: 6.2.x, 6.2.3 Jan 20, 2025
@jhoeller jhoeller changed the title URLResource should leniently handle resources which do not support HTTP HEAD UrlResource should leniently handle HTTP endpoints which do not support HEAD Jan 20, 2025
@jhoeller
Copy link
Contributor

@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.

@chubbard
Copy link
Author

@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?

@jhoeller
Copy link
Contributor

@chubbard it should be sufficient to add https://repo.spring.io/snapshot as a repository next to Maven Central, and then bump the Spring Framework version to 6.2.3-SNAPSHOT.

@bclozel
Copy link
Member

bclozel commented Jan 31, 2025

@chubbard you can override the Spring Framework version in your build tool with the version property managed by Boot.

For Gradle, this is:

ext['spring-framework.version'] = '6.2.3-SNAPSHOT'.

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.

@sbrannen
Copy link
Member

sbrannen commented Feb 1, 2025

@chubbard, instructions for working with snapshots is also documented in our wiki.

@chubbard
Copy link
Author

chubbard commented Feb 6, 2025

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.

@jhoeller
Copy link
Contributor

jhoeller commented Feb 7, 2025

Good to hear! No worries, this was timely pre-release testing in any case :-)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
in: core Issues in core modules (aop, beans, core, context, expression) type: enhancement A general enhancement
Projects
None yet
Development

No branches or pull requests

6 participants