I have an issue that my application deployment always returns response headers with:
Cache-Control: no-cache
Cache-Control: no-store
Expires:Thu, 01 Jan 1970 00:00:00 GMT
Pragma:no-cache
I'm using:
Spring 3.1.2.RELEASE
Primefaces JSF 3.4.1
Spring Webflow 2.3.0.RELEASE
JBoss AS 7.0.1
I've tried nearly every solution on the application side I could find:
- Configuring the WebContentInterceptor (tried various permutations of it) Right out of the box cache-control header filter?
- Writing a custom interceptor that adds different Cache-Control header (tested with Cache-Control: private)
- Writing a customer filter that adds HTTP response parameters. Configure it with Cache-Control: private as init-params in web.xml
- Use the context.xml file (tried both in META-INF/ and WEB-INF/) to disable the Cache-Control in JBoss/Tomcat http://daveharris.wordpress.com/2007/07/09/how-to-configure-cache-control-in-tomcat/
In all of the above cases, the response headers never ended up different, always no-cache, no-store, 1970 expires, pragma: no-cache
I'm running out of ideas, does anyone know what is setting these headers in my response so I can target the appropriate deployment component to resolve this?
The root code causing this is in Spring MVC, called from the WebContentGenerator. This class is used as base class for several classes in the MVC/Webflow stack: WebContentInterceptor (MVC interceptor), AbstractController (MVC controller), AbstractHandlerMethodAdapter (MVC HandlerAdapter), AnnotationMethodHadlerAdapter (MVC HandlerAdapter), FlowHandlerAdapter (Webflow HandlerAdapter), JsfFlowHandlerAdapter (Webflow + JSF HandlerAdapter)
The CacheControl seconds setting of 0 calls the preventCaching method. So it seems the application is defaulting to a setting of 0.
org.springframework.web.servlet.support.WebContentGenerator
I found out that since I am using JSF + Webflow, the JsfFlowHandlerAdapter is handling the server requests for the flows/views first. This is why configuring interceptors does not help because the JsfFlowHandlerAdapter has already set the Cache-Control and other HTTP Headers at this point. It turns out I had already extended the JsfFlowHandlerAdapter to handle FlowExecutionRestorationFailureException (see Sping Web Flow Preventing Back Button Use) so all I needed to do was set the configuration I wanted ala WebContentInterceptor (since the configurations belong to the base class WebContentGenerator).
Custom JsfFlowHandlerAdapter
webmvc-config.xml
CacheControlInterceptor (to set your own HTTP Headers. The methods that do it in WebContentGenerator are final so cannot @Override)