ETag and Last-Modified Validation

## Freshness versus validation HTTP caching has two phases. While a response is **fresh** - inside the lifetime given by `Cache-Control: max-age` or `Expires` - a cache serves it with no network traffic at all. Once it is **stale**, the cache does not throw it away. It asks the origin one cheap question: *is what I have still correct?* That question is a conditional request, and the token it carries is a **validator**. ## The entity tag An `ETag` is an opaque quoted string chosen by the server to identify one specific representation of a resource: ``` ETag: "33a64df551425fcc55e4d42a148795d9f25f89d4" ``` Opaque means the client must never parse it - it is a hash, a version number, an inode-and-mtime tuple, whatever the server likes. The only contract is: **the tag changes when the representation changes, and stays the same when it does not.** ## The handshake 1. `GET /style.css` -> `200 OK`, `ETag: "v7"`, `Cache-Control: max-age=600`, body. The client stores the body keyed with `"v7"`. 2. Within 600 seconds, reuse is silent - no request leaves the machine. 3. After 600 seconds the entry is stale. The client sends `GET /style.css` with `If-None-Match: "v7"`. 4. The server computes the current tag. Still `"v7"` -> `304 Not Modified`, no body. Now `"v9"` -> `200 OK` with the new body and `ETag: "v9"`. On a 304 the client **reuses its stored body** and updates the entry's metadata from the 304's headers - a new `Cache-Control` restarts the freshness clock, so the next 600 seconds are again request-free. This is why a 304 must include the headers a cache needs to refresh the entry; a 304 with no `Cache-Control` leaves the entry stale, and the client revalidates on every single use. ## Comparison rules For a conditional GET the comparison is **weak**: the tags need only be semantically equivalent, so `W/"v7"` matches `"v7"` and matches `W/"v7"`. That is deliberate - for "may I reuse my copy?" equivalent-enough is enough. (Write preconditions and range requests use strong comparison instead, where a weak tag never matches.) `If-None-Match: *` means "match if the resource exists at all" and is used to make a create-only PUT safe, not for caching. ## Why not just refetch Three reasons. Bandwidth: a 304 is a few hundred bytes against a payload that may be megabytes. Latency and rendering: reusing bytes already on disk avoids decode and layout work. Origin cost: the server can often answer a conditional request from a cheap version lookup without rendering the representation - though only if you implement it that way. A handler that fully builds the response body and then discards it to send a 304 saves the client's bandwidth but none of your CPU. ## Where it goes wrong Several practical failure modes are worth naming: - **The tag never changes** because it is derived from something that does not track content, so clients serve outdated data indefinitely. - **The tag always changes** - a timestamp folded in, or a load balancer sending each request to a node that hashes differently - so every revalidation is a full 200 and the mechanism buys nothing. Multi-node deployments must generate the tag deterministically from the content or a shared version, not from per-node state. - **Compression changes the bytes.** If a proxy gzips a response after the ETag was computed on the uncompressed body, the tag no longer identifies the transmitted representation. Servers typically distinguish encodings by suffixing the tag; combined with `Vary: Accept-Encoding`, this keeps variants apart. - **304 sent with a body**, which is a protocol violation - 304 never carries one. ## Relationship to Last-Modified `Last-Modified` plus `If-Modified-Since` is the older handshake with the same shape, comparing dates instead of tokens. Servers commonly send both validators; a client that has both should send both, and the server evaluates `If-None-Match` first, using the date only if no entity tag condition was supplied.