Etag/Last Modified - the numpty question I've always wanted to know.

[jesper_mortensen]

(01-28-2011 03:12 PM)Thompson Wrote:  I've always heard (askapache.com) that for static content (JS/CSS), it's best to set far futures headers by setting *both* cache-control and expires headers. And then unsetting *both* etags and last modified.

Anybody have any thoughts on this?

Cache-Control is a "strong" caching header, in the sense that it's unconditional. When you instruct caches via the cache-control header, they are allowed to cache the content for the indicated time without checking back with you. Expires acts in the same way.

Cache-Control is a HTTP 1.1 header, and as such requires a HTTP 1.1 compliant cache. Expires is a HTTP 1.0 header.

Personally, I don't serve both HTTP 1.1 and 1.0 caching headers anymore, I exclusively use the HTTP 1.1 Cache-Control.

ETags and Last-Modified are not "weak" caching headers, they are conditional download / content headers. ETag is a header used for conditional downloads, with a clear meaning and pretty consistent implementations. Last-Modified is, well, the timestamp for when the content was last modified. But since it is timestamp-based, and quite old, you can find some inconsistent behavior when Last-Modified is used as the sole criteria for conditional downloading.

If you want to manage caching, and have something that is simple to reason about, then there are IMHO 2 good solutions:

• Serve content with the HTTP 1.1 Cache-Control header as the only 'caching' header.
• Serve content with both Cache-Control and Expires, with both headers indicating the exact same expiry time.
  

In both cases, removing ETag and Last-Modified just makes things a little simpler to reason about, especially if ancient and weird proxy caches are involved.

I base my suggestion of not using 304's in part on the following quote:
"Cache Updates:
Caches are required to be updated by the headers in 304 responses,[...]
In practice, updates were spotty; a lot of the time, the test suite couldn’t get the cache into a state where it could tell, but when it could, there were failures. As a result, it’s probably not a good idea to rely on 304 responses or HEAD requests to update headers; better to just send a 200 back with a whole new representation."

Mark Nottingham has a really good write-up on HTTP mechanisms for controlling caches here:
http://www.mnot.net/cache_docs/