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 requires resources support HEAD #34217

Open
chubbard opened this issue Jan 9, 2025 · 0 comments
Open

URLResource requires resources support HEAD #34217

chubbard opened this issue Jan 9, 2025 · 0 comments
Labels
in: web Issues in web modules (web, webmvc, webflux, websocket) status: waiting-for-triage An issue we've not yet triaged or decided on

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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
in: web Issues in web modules (web, webmvc, webflux, websocket) status: waiting-for-triage An issue we've not yet triaged or decided on
Projects
None yet
Development

No branches or pull requests

3 participants