Cache Control puzzle

Understand it by use case

http cache control by use case

  • public: default
  • no-cache == max-age=0, must-revalidate

The practice is...

Cache nothing

If having to serve all kinds of clients/proxies: some only work under HTTP 1.0; some do not work over HTTPS if only no-store

# HTTP 1.1
Cache-Control: no-cache, no-store, must-revalidate

# HTTP 1.0 (dated clients)
Pragma: no-cache

# For HTTP-1.0 proxies only (For HTTP-1.1 ones, Cache-Control takes precedence)
Expires: 0

If dropping all dated HTTP-1.0 client/proxy supports

Cache-Control: no-store, must-revalidate

The must-revalidate is still needed (although the according to the specs, it's unneeded) for "broken" browsers

Make use of the cache

Notice that, choosing public or private depends on the sensitiveness of the resources to be cached.

Cache forever

Typically for static resources: JS, CSS, Images...

# a year
Cache-Control: max-age=31536000

in conjunction with changing the URL every time the content changes, for example: href="/styles-dfas231ddsxa.css"

Cache, unless got changes

Cache-Control: no-cache
ETag: xyz

At the server side, remember to implement a logic to answer requests with header If-None-Match: ETag value

  • Responds 304 - Not Modified if the resource isn't changed,
  • Otherwise responds 200 - OK with full resource content.

Similarly, if Last-Modified is used instead of ETag, answers If-Modified-Since: last-modified value requests.

The "back" button

The back/forward button is about the history buffer, not the cache. The behavior varies between different browser engines. Even with no-store, the browser is allowed to use a response stored in the history buffer.

  • no-cache doesn't impact the "back/forward" button. That means, no server validation occurs.
  • Using Cache nothing mechanism above won't affect the back/forward button in Safari and Opera.