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

Http method interceptor to handle method not allowed [SPR-17227] #21760

spring-projects-issues opened this issue Aug 30, 2018 · 4 comments
status: declined


Copy link

@spring-projects-issues spring-projects-issues commented Aug 30, 2018

Philip Kaufmann opened SPR-17227 and commented

Hello there

In our daily work with http resources, we found it very useful to control whether a specific HTTP method (e.g. PUT) is allowed or not. In the latter case, we like to handle the error code 405 by ourselves.

For example: a PUT on a "task" resource is not possible anymore, if the "task" has the state completed. We then want to respond with a Method not allowed (405).

We wrote a prototype to see if there's any interest in implementing this into the spring framework mvc module directly. Please see the reference URL.

We wrote a method interceptor that evaluates an expression similar to @PreAuthorize, that intercepts calls before any validation takes place. Allowing to return very early and not fill the handler method with boilerplate code.


@PutMapping(value = "/task/{name}")
public String putWithMethodAllowed(@PathVariable String name) {
	return name;

This feature, if generalized, could also be used to return other client errors e.g. a 404 not found.


Remark for the prototype:

For simplicity, we only check if there are any more methods with the same path and add them to the "Allow" header. In future, we're also willing to implement a way that we check, if those methods are annotated with @HttpMethodAllowed, run the given method with the variables there and check, if it's still allowed or not to give a better response in the "Allow" header.

To manage this, we only take @PathVariable into consideration, we're not checking for queryparams or requestbodies etc.


Reference URL:

2 votes, 3 watchers

Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Sep 4, 2018

Brian Clozel commented

Interesting Philip Kaufmann,

I'm moving this to the general backlog to see if the community would be interested in this feature.

In my opinion, this relies on resources and state transfer, which is a concept at the heart of Spring HATEOAS and Spring Data REST. I'm not sure annotations are the right path for this, since it is a cross cutting concern, but still local to the resource at hand. Let's see what others think about this.

@spring-projects-issues spring-projects-issues added type: enhancement in: web labels Jan 11, 2019
Copy link

@julien-may julien-may commented Mar 4, 2020

@bclozel: Any updates on this topic?

Copy link

@bclozel bclozel commented Mar 4, 2020

@julien-may Not really. Demand for this is really low, and my comment about this feature probably being a better fit for Spring HATEOAS/Spring Data REST still stands. I'm closing this issue as a result.

@bclozel bclozel closed this as completed Mar 4, 2020
@bclozel bclozel removed this from the General Backlog milestone Mar 4, 2020
@bclozel bclozel added status: declined and removed in: web type: enhancement labels Mar 4, 2020
Copy link

@rstoyanchev rstoyanchev commented Mar 6, 2020

This may be possible to achieve via custom conditions.

That said it is not very clear why this needs to be done in a declarative way as opposed to making the same check within the controller method and conditionally returning ResponseEntity<String>.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
status: declined
None yet

No branches or pull requests

4 participants