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

Static resource are not accessible via HTTP POST method [SPR-17608] #22140

Closed
spring-issuemaster opened this issue Dec 18, 2018 · 1 comment

Comments

@spring-issuemaster
Copy link
Collaborator

@spring-issuemaster spring-issuemaster commented Dec 18, 2018

Govinda Sakhare opened SPR-17608 and commented

I tried to access resource lying under static resource folder but as it seems static resource access via POST is not supported in spring.

I have already raised an issue in Spring boot project: spring-projects/spring-boot#15485


Reference URL: https://stackoverflow.com/questions/36476638/spring-boot-allowing-post-access-to-static-content

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

@spring-issuemaster spring-issuemaster commented Dec 18, 2018

Brian Clozel commented

Spring Framework resource handling is meant for serving static resources and providing infrastructure around that, like HTTP caching or serving resources from various locations.

Allowing POST methods on static resources would be in my opinion really surprising to most Spring developers. What is it supposed to do? In HTTP terms, POST is supposed to change the underlying resources, and here we're not talking about replacing the resource by something provided by the client.

You're suggesting that a POST, by default, does nothing to the resource and acts as a GET.

If we take a step back, it seems that the actual need is to map a POST request to something that you'd normally serve as a GET. In your particular case, you're serving your HTML view as a static resource, and probably rendering the UI on the client side. This is actually more a product of a constraint of your authentication system and the way you chose to handle views in your application. Other developers might choose another authentication system or render views with a templating engine.

Again, in your case, I believe you'd be in a much better place if you used actual controllers (and a templating engine) to show that view. In that case, you'd be in control of allowed HTTP methods on specific endpoints. If you're looking for an application-wide solution, then maybe a Servlet filter updating/forwarding the requests for those authentication cases would work best.

I'm closing this issue as I don't believe we'll implement this solution but rather focus on the issue.

Thanks!

 

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.