1

After spending 2 days reading about cache headers, I'm still unsure what's the best combination to ensure that a PHP page with dynamic content will always be re-fetched from the server.

I believe a Cache-Control: no-cache header seems to be enough, and maybe an Expires header with a value in the past to ensure compatibility with HTTP 1.0 proxy caches.

Pragma

Pragma is not specified as a response header:

Note: because the meaning of "Pragma: no-cache as a response header field is not actually specified, it does not provide a reliable replacement for "Cache-Control: no-cache" in a response

The behavior of the Pragma header in the response is implementation-specific, and I believe it doesn't add much when the headers already include:

Cache-Control: no-cache 
Expires: Sat, 01 Jan 2000 00:00:00 GMT

Pragma: no-cache is non-standard and seems completely unnecessary.

Cache-Control

The Cache-Control header accepts many values, so here is the breakdown I've got to:

  • no-cache means to treat the resource as stale and re-validate (through If-Modified-Since/If-None-Match) on subsequent requests. It implies max-age=0, must-revalidate, so I don't need those headers. Some recent browsers even treat no-cache as no-store.
  • no-store is mostly related to security, to prevent storing responses containing sensitive data in the computer. Not only I normally wouldn't need it, but it also seems completely redundant as the response is served with a Cache-Control: no-cache header (must be re-validated) and no means of validation (no Last-Modified/ETag), rendering the response unusable by any cache. Hence, it seems completely redundant.
  • proxy-revalidate seems redundant due to the same reason above.
  • public/private seem redundant as well, as the response is unusable by any cache mechanism.
  • pre-check=0, post-check=0 are IE-specific values, which I believe to be unnecessary as well.

Context

I'm not using SSL/HTTPS, so the IE8 bugs which are said to appear with Cache-Control: no-cache don't apply to this question. I also don't care whether the browser uses a stored copy or re-fetches resources when pressing the back/forward buttons.

Question

Are all my assumptions above correct? Anything I've overlooked? Or any possible improvements?

References

Community
  • 1
  • 1
Fabrício Matté
  • 65,581
  • 23
  • 120
  • 159

1 Answers1

1

I believe your assumptions are correct. I've done a lot of projects involving dynamic data and we never needed anything more than Cache-Control: no-cache (a HTTP/1.1 header). Setting an Expires: date in the past is also good practice to cover HTTP/1.0 user agents.

That said, if you want to specifically inform requesting agents that the page is definitely distinct from the previous access, it might be worth sending an Etag: header which is time-based. That way, any previously fetched copy will have a different Etag and the agent will be aware that the copy now being sent is new. This will marginally increase request header size as the request will contain the previous Etag if any.

  • Are there such a thing as HTTP/1.0 user agents? I've looked around for a list but couldn't find anything. I'm assuming the IE <= 5.5 era. +1 for the feedback, I'll leave the question open a bit longer even though I'm rather positive that `Cache-Control: no-cache` should be enough. – Fabrício Matté Feb 28 '14 at 00:08
  • See [this](http://stackoverflow.com/questions/2073392/is-http-1-0-still-in-use) post. As of 2010, `wget` still used HTTP/1.0. –  Feb 28 '14 at 00:13