Is cache-control header changed by browser itself?

Question

In my servlet filter I set the following response header to enable caching of some resources:

Cache-Control: public,max-age=604800,must-revalidate

When I look at the response headers in Google Chrome version 46, I can see the same values for the cache-control header mentioned above. Chrome also shows GET 200 (from cache) 0ms.

However, Firefox 38, shows GET 304 and to my surprise Cache-Control: "no-cache" as the value of the cache-control header instead of the values set by my servlet filter.

Internet Explorer 10 shows GET 200 and also "no-cache" as the value of the cache-controle header.

So, can you explain to me why or how the value that I set in my servlet filter (in my JSF/PrimeFaces app deployed on JBoss AS 7) as a http response header, shows up unmodified in chrome but changed in firefox and IE. I didn't code any javascript myself that might have overridden this header. I am actually trying to enable the "same" caching strategy for all three browsers mentioned.

Regards, Ronald Wouters.

did you try this with a 'plain' html page? I doubt this is jsf or PrimeFaces related (why no servlet-filter tag btw?) And if this filter is homegrown, maybe showcase.omnifaces.org/filters/CacheControlFilter is is a nice alternative — Kukeltje
Actually the CacheControlFilter is one of the first things I checked but it actually skips jsf resources (javax.faces.resource). I want IE to cache primefaces resources like jquery.js or at lease send a conditional get query. — Ronald Wouters
It skips the resources because they are already handled by the resourceHandler as mentioned there. Since there is versioning in the resources, skipping them and let the normal resourceHandler handle it works fairly well at least for us (otherwise BalusC would have optimized it ;-) — Kukeltje
The "normal" resource handler and resource implementations (com.sun.faces.application.resource.ResourceHandlerImpl and especially ResourceImpl itself in jsf-impl jar) check for the if-modified-since request header. That request header is not sent by IE if a "no-cache" response header was "received" previously. That's why, at least in my case, IE10 does not send a conditional get and does not cache any resources from ln=primefaces. Hence my original question. — Ronald Wouters
Hmmm we never heard problems with IE10 but If I find the time I will check in the weekend, but we never send a no-cache for resources, so maybe we do not run into this or I fail to see tge issue — Kukeltje

Ronald Wouters Ronald Wouters · Accepted Answer · 2015-11-16T14:15:12

To answer my own question:
The problem was not related to response headers at all. All JSF resources in my app had the follwing url layout:

https://myserver/myapp/javax.faces.resource/jquery/jquery.js.xhtml?ln=primefaces&v=5.2

Notice the xhtml suffix after jquery.js ?
It was added automatically by the jsf runtime I think.

I also had the following in my web.xml:

  <security-constraint>
    <web-resource-collection>
      <web-resource-name>All pages</web-resource-name>
      <description>Protects all resources</description>
      <url-pattern>*.xhtml</url-pattern>
    </web-resource-collection>
  </security-constraint>

Apparently this security constraint caused jsf resources NOT being cached by internet explorer.

After changing the url-pattern to /mypages/* instead of *.xhtml, primefaces resources like jquery.js but also other resources (example: h:graphicImage library="images") were correctly cached (http 304) in Internet Explorer 10.

I still would like to have an explanation of why having a security constraint interferes with, or alters the behaviour of, caching of jsf resources. Can someone explain that to me please ?

Regards, Ronald Wouters

Is cache-control header changed by browser itself?

1 Answers