Allow MVC interceptors to handle requests for URLs that aren't mapped to any handler [SPR-8468]

[spring-projects-issues]

Keith Donald opened SPR-8468 and commented

A good example would be signout control logic. Such logic might be part of a UserInterceptor and triggered if the request URI is /signout. However, if /signout is not mapped to a handler, a 404 will be thrown even if UserInterceptor is capable of processing a /signout request.

The workaround seems to be "use a filter". However filters are difficult to configure and do not natively benefit from Spring DI.

The other workaround is to register a dummy handler for something like /signout.

---

Affects: 3.1 M2

Issue Links:

• Provide support for Filter registrations in AbstractDispatcherServletInitializer [SPR-9696] #14330 Provide support for Filter registrations in AbstractDispatcherServletInitializer

1 votes, 3 watchers

[spring-projects-issues]

Rossen Stoyanchev commented

HandlerInterceptors are configured on a HandlerMapping, which returns a HandlerExecutionChain. Given that MappedInterceptors have URLs, in theory we could return a HandlerExecutionChain with the MappedInterceptor even if no controller was found.

This can lead to unexpected side effects though. In this case we know the HandlerInterceptor can handle the request. In other cases, what would be invalid URLs otherwise might end up being "handled" by a broadly mapped interceptor (e.g. ConversionServiceExposingInterceptor).

Also what is the handler in the resulting HandlerExecutionChain? If you returned false from preHandle() that would work okay. But what if an interceptor doesn't do that? Further processing with a null handler is problematic.

I think this pushes the semantics of HandlerInterceptor as defined presently and may cause unexpected side effects. With considerations for async processing we may end up revisiting some of this.

For the time being I'm wondering if a SignOutController would be so bad in this case? After all Sign-in is a cross-cutting need that fits the bill for interception while Sign-out is a very specific task that can be fulfilled by a controller.

[spring-projects-issues]

Keith Donald commented

Yes, SignOutController would be bad as the logic to perform the SignIn/SignOut belongs in one place.

[spring-projects-issues]

Keith Donald commented

I think this may come down it's difficult and inconsistent to configure request interception logic in MVC. I thought for a second WebRequestInterceptor would fit the bill but it seems to have the same limitations as HandlerInterceptor, despite being positioned as more general. The only workaround I seem to have is javax.filter, which again is a pain to configure and a pain to get DI support.

[spring-projects-issues]

Keith Donald commented

This issue can be demonstrated in the spring-social-samples quickstart app.

[spring-projects-issues]

Rossen Stoyanchev commented

Adding link to comment that relates to this issue:

https://jira.springsource.org/browse/SPR-7812?focusedCommentId=68282&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-68282

[spring-projects-issues]

Juergen Hoeller commented

Closing this as "Won't Fix" from the perspective of interceptors just applying to pre-mapped handlers.