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

[spring-issuemaster]

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.

e.g.

@HttpMethodAllowed("!isCompleted(#name)")
@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: https://github.com/pkaufi/httpmethodallowed

2 votes, 3 watchers

[spring-issuemaster]

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.

[julien-may]

@bclozel: Any updates on this topic?

[bclozel]

@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.

[rstoyanchev]

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>.