Explain what the HTTP directive Cache-Control: s-maxage does that max-age does not, and how CDN-Cache-Control and Surrogate-Control let you give a CDN a different lifetime from the browser.

## Why one lifetime is not enough A response typically passes through three storage tiers: the origin's own cache, a shared cache at the edge (CDN or reverse proxy), and the user's browser. These tiers have very different properties. The **edge copy is controllable**. There is one of it per POP, you own the account, and you can purge it in seconds when content changes. The **browser copy is not**. Once `max-age=86400` is on a response, that user will not ask again for a day. You cannot reach into their disk. If you shipped a bug, they keep it. So the sensible policy is asymmetric: short in the browser, long at the edge. A single `max-age` cannot express that, which is why `s-maxage` exists. ## s-maxage `s-maxage=N` gives a freshness lifetime in seconds that applies **only to shared caches**, and where present it overrides `max-age` for them. Private caches ignore it entirely and continue to use `max-age` (or `Expires`). ``` Cache-Control: max-age=60, s-maxage=86400 ``` Browser: fresh for 60 seconds. CDN: fresh for a day. Behind that, a deploy or a content change is handled by purging the edge, and stale browser copies age out within a minute. A second, less-known effect: like `public` and `must-revalidate`, the presence of `s-maxage` also authorises a shared cache to store a response that came from a request bearing an `Authorization` header. Do not sprinkle it onto authenticated per-user routes. ## proxy-revalidate `must-revalidate` forbids any cache from serving a stale entry without checking with the origin first - it turns "stale but usable in an emergency" into "must be validated". `proxy-revalidate` is the same instruction scoped to shared caches only, letting a browser be lenient while the edge stays strict. In practice it is used where serving a slightly stale shared copy to *other* users is the unacceptable case: pricing, quotas, availability. ## Targeting the CDN specifically `s-maxage` says "shared cache", but a corporate proxy is also a shared cache, and increasingly you want to say "the CDN, and only the CDN". Two headers do that. **`CDN-Cache-Control`** is the standardised targeted-header form: only a CDN reads it, and for a CDN it overrides `Cache-Control` entirely. **`Surrogate-Control`** is the older Edge Architecture convention (`Surrogate-Control: max-age=600`), supported by most CDNs and by Varnish-family caches. A surrogate that acts on it is expected to **remove it from the response** it forwards, so it never confuses the browser or an intermediate cache. `CDN-Cache-Control` is likewise not meant to be acted on by browsers. A CDN resolving a response picks the most specific directive set it understands: its own vendor-prefixed header if present, then `CDN-Cache-Control`, then `Surrogate-Control`, then plain `Cache-Control`. Exact ordering is vendor-specific, so verify with your provider rather than assuming. The result is three independently tunable tiers: ``` Cache-Control: max-age=0, must-revalidate CDN-Cache-Control: max-age=600 ``` Browsers revalidate on every use; the CDN serves from its own copy for ten minutes and absorbs the traffic. ## Practical guidance - Default shape for public content: small `max-age`, large `s-maxage` or `CDN-Cache-Control`, and a purge on publish. - For immutable, content-hashed assets the calculus inverts - a year-long `max-age` plus `immutable` is correct precisely because the URL changes when the content does. - Never rely on browser TTL as your rollback mechanism; there is none. Rely on the edge, which you can purge. - Verify what actually reached each tier. Requesting through the CDN and directly at the origin, and comparing the returned `Cache-Control`, `Age` and any vendor cache-status header, tells you which tier answered and under which lifetime.