Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Restrict allowed HTTP methods in HiddenHttpMethodFilter [SPR-16836] #21376

Closed
spring-projects-issues opened this issue May 17, 2018 · 2 comments
Assignees
Labels
in: web Issues in web modules (web, webmvc, webflux, websocket) status: backported An issue that has been backported to maintenance branches type: enhancement A general enhancement
Milestone

Comments

@spring-projects-issues
Copy link
Collaborator

Brian Clozel opened SPR-16836 and commented

Currently the HiddenHttpMethodFilter allows requests to change the HTTP method to any method. Both Servlet and Reactive variants should restrict the allowed HTTP methods to : PUT, PATCH and DELETE.


Backported to: 4.3.18

@spring-projects-issues
Copy link
Collaborator Author

Cory Hahlbeck commented

Hey, is there any reason GET is not in the list of allowed methods? We used GET as a method parameter in a POST whenever requests would have exceeded the URL length limit, so this change breaks some functionality. It seems like it was decided to not include GET since there is no need to simulate it from a browser, but some of the other use cases of this class might be being overlooked.

@spring-projects-issues
Copy link
Collaborator Author

Brian Clozel commented

Hi Cory Hahlbeck,

That's right - the main goal of this filter is to work around the inability of browsers to send HTTP forms with specific HTTP methods.

I'm not really in favor of adding the possibility for GET methods:

  • PUT, PATCH, DELETE methods can semantically change state of a resource on the server side, GET is not supposed to; I find rather strange to turn a side-effect method into an idempotent one
  • the use case you're describing is about the inability to update the server application to accept POST requests where it should be (the fact that the client is trying to send too much data for a GET request is a smell)

The implementation of this filter is really straightforward and your use case seems to be more about a workaround to a specific issue than a general use case for applications. In this case, I think your best bet is to create your own filter that will suit your needs.

Thanks for your feedback and don't hesitate to add more comments if you've got other use cases in mind for this.

@spring-projects-issues spring-projects-issues added status: backported An issue that has been backported to maintenance branches type: enhancement A general enhancement in: web Issues in web modules (web, webmvc, webflux, websocket) labels Jan 11, 2019
@spring-projects-issues spring-projects-issues added this to the 5.0.7 milestone Jan 11, 2019
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
in: web Issues in web modules (web, webmvc, webflux, websocket) status: backported An issue that has been backported to maintenance branches type: enhancement A general enhancement
Projects
None yet
Development

No branches or pull requests

2 participants