Skip to content

Make HandlerInterceptor play nice with @ResponseBody [SPR-7897] #12553

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

Closed
spring-projects-issues opened this issue Jan 19, 2011 · 1 comment
Closed
Assignees
Labels
status: duplicate A duplicate of another issue type: enhancement A general enhancement

Comments

@spring-projects-issues
Copy link
Collaborator

spring-projects-issues commented Jan 19, 2011

Kenny MacLeod opened SPR-7897 and commented

Currently, if you try and use @ResponseBody and HandlerInterceptor together, you don't get the expected behaviour.

Specifically, the @ResponseBody is written and committed by ServletHandlerMethodInvoker before HandlerInterceptor.postHandle is called. I would have expected the order to be similar to if I had omitted the @ResponseBody and used a MarshallingView instead, i.e.

  • HandlerInterceptor.preHandle
  • (handler is invoked)
  • HandlerInterceptor.postHandle
  • (response is written)
  • HandlerInterceptor.afterCompletion

With @ResponseBody, the 3rd and 4th steps are reversed.

Looking at the code, this wouldn't seem an easy refactoring to make, but could it be done?


Affects: 3.0.5

Issue Links:

2 votes, 3 watchers

@spring-projects-issues
Copy link
Collaborator Author

spring-projects-issues commented May 19, 2014

Rossen Stoyanchev commented

#15486 scheduled for 4.1 RC1 should address this concern by providing an additional interception point.

Since @ResponseBody relies on use of HttpMessageConverter's that write to the response immediately after the controller method is invoked. As a consequence it is too late for HandlerInterceptor's postHandle to get involved.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
status: duplicate A duplicate of another issue type: enhancement A general enhancement
Projects
None yet
Development

No branches or pull requests

2 participants