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

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

spring-issuemaster opened this Issue May 17, 2018 · 2 comments


None yet
2 participants
Copy link

spring-issuemaster commented May 17, 2018

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


This comment has been minimized.

Copy link
Collaborator Author

spring-issuemaster commented Jun 27, 2018

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.


This comment has been minimized.

Copy link
Collaborator Author

spring-issuemaster commented Jul 5, 2018

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment