I want to find a minimal set of headers, that work with "all" caches and browsers (also when using HTTPS!)
On my web site, I'll have three kinds of resources:
Example: 0A470E87CC58EE133616F402B5DDFE1C.cache.html (auto generated by GWT)
These files are automatically assigned a new name, when they change content (based on the MD5).
They should get cached as much as possible, even when using HTTPS (so I assume, I should set Cache-Control: public
, especially for Firefox?)
They shouldn't require the client to make a round-trip to the server to validate, if the content has changed.
Examples: index.html, mymodule.nocache.js
These files change their content without changing the URL, when a new version of the site is deployed.
They can be cached, but probably need a round-trip to be revalidated every time.
Example: JSON responses
I have a general idea on which headers I would probably use for each type, but there's always something I could be missing.
I would probably use these settings:
Cache-Control: max-age=31556926
– Representations may be cached by any cache. The cached representation is to be considered fresh for 1 year:
To mark a response as "never expires," an origin server sends an Expires date approximately one year from the time the response is sent. HTTP/1.1 servers SHOULD NOT send Expires dates more than one year in the future.
Cache-Control: no-cache
– Representations are allowed to be cached by any cache. But caches must submit the request to the origin server for validation before releasing a cached copy.Cache-Control: no-store
– Caches must not cache the representation under any condition.See Mark Nottingham’s Caching Tutorial for further information.
@Gumbo: One thing I'm pretty sure about is, that I need to set public, when I want Firefox 3+ to cache public files to disk while using HTTPS: stackoverflow.com/questions/174348/…
Some browsers, such as IE, are starting to treat Cache-Control: no-cache as if it was no-store. This is admittedly not according to the RFC, but it is knowingly done to "fix" the mistake done by MANY of using no-cache to prevent sensitive data from being stored unencrypted on disk.
@chris_l, I happened across this link: palisade.plynt.com/issues/2008Jul/cache-control-attributes . I don't remember how previous versions behaved, though I think IE7 did this too.
Also, Firefox no longer requires PUBLIC in the Cache-Control to cache HTTPS resources. But your best bet overall is to just test your site while watching the traffic, e.g. with Fiddler.
Setting a cache control value of 100 years is not advised. First off, the spec recommends a max of 1 year. Secondly, any value over 68 years results in immediate expiration for IE8 and below: blogs.msdn.com/b/ieinternals/archive/2010/01/26/…