HTTP caching should be decoupled from WebContentGenerator [SPR-2779]

[spring-projects-issues]

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:

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

Referenced from: commits 38f32e3

0 votes, 6 watchers

[spring-projects-issues]

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

Juergen

[spring-projects-issues]

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.

[spring-projects-issues]

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.