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 caching should be decoupled from WebContentGenerator [SPR-2779] #7466

spring-issuemaster opened this issue Oct 30, 2006 · 3 comments


None yet
2 participants
Copy link

commented Oct 30, 2006

Matthew Sgarlata opened SPR-2779 and commented

The WebContentGenerator class has several methods that help manage HTTP caching for controllers (cacheForSeconds, preventCaching, etc). These methods are great for controllers that extend from WebContentGenerator (or one of its subclasses like AbstractController) but are unavailable if you have a controller that doesn't want to or can't extend from WebContentGenerator or one of its subclasses. It's also unavailable if you are using a HandlerInterceptor to catch exceptions and forward to a special exception view.

I recommend the HTTP caching methods be moved into a new class to which WebContentGenerator delegates. The new class could be called HttpCacheHelper or something similar.

I ran into this in my application because we have HandlerInterceptors that redirect to JSPs if certain conditions are met. For example, if a user doesn't have the correct permissions to view a page a HandlerInterceptor sends them to a page that lets the user know they don't have permission to view the page they requested.

This is also a problem with ExceptionResolvers. They currently do not offer an easy way to work with HTTP caching out-of-the-box. I will open a separate bug report for that.

Affects: 2.0 final

This issue is a sub-task of #16413

Issue Links:

  • #7467 Add HTTP cache control options to SimpleMappingExceptionResolver ("is depended on by")
  • #13194 Provide controller method level alternative to WebContentInterceptor

Referenced from: commits 38f32e3

0 votes, 6 watchers


This comment has been minimized.

Copy link
Collaborator Author

commented Oct 30, 2006

Juergen Hoeller commented

Have you noticed the WebContentInterceptor class? That's a HandlerInterceptor that derives from WebContentGenerator and allows to apply its settings as part of the interceptor chain, fronting any Controller as well as any subsequent HandlerInterceptor or HandlerExceptionResolver that might kick in. This actually seems like an appropriate solution for some of the scenarios that you outlined...



This comment has been minimized.

Copy link
Collaborator Author

commented Oct 31, 2006

Matthew Sgarlata commented

I hadn't noticed that, thanks for pointing that out! I suppose we can also extend from the WebContentGenerator class for our custom HandlerExceptionResolvers. So, there is a way to do this, but it does smell a bit of the bad designs you see in Struts with functionality embedded in base classes rather than helper classes that can be delegated to.


This comment has been minimized.

Copy link
Collaborator Author

commented Mar 23, 2015

Brian Clozel commented

The WebContentGenerator and WebContentInterceptor deprecate several methods, including HTTP1.0 related ones.

A new CacheControl builder class allows more flexible configurations for the "Cache-Control" HTTP; this is now decoupled from the WebContentGenerator itself and in fact reused in other parts of the framework.

See #16413 for more details.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.