Ideal HTTP cache control headers for different typ

Question

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:

(1) Forever cacheable (public / equal for all users)

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

(2) Changing occasionally (public / equal for all users)

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

(3) Individual for each request (private / user specific)

^{Example: JSON responses}

• These resources should never be cached unencrypted to disk under no circumstances. (Except maybe I'll have a few specific requests that could be cached.)

---

I have a general idea on which headers I would probably use for each type, but there's always something I could be missing.

Answer 1

I would probably use these settings:

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

2. 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.
3. Cache-Control: no-store – Caches must not cache the representation under any condition.

See Mark Nottingham’s Caching Tutorial for further information.

Answer 2

Cases one and two are actually the same scenario. You should set Cache-Control: public and then generate a URL with includes the build number / version of the site so that you have immutable resources that could potentially last forever. You also want to set the Expires header a year or more in the future so that the client will not need to issue a freshness check.

For case 3, you could all of the following for maximum flexibility:

"Cache-Control", "no-cache, must-revalidate"
"Expires", 0
"Pragma", "no-cache"