For build-fingerprinted static assets such as `/static/app.8f3a1c.js`, teams often send `Cache-Control: public, max-age=31536000, immutable`. Explain what `immutable` adds on top of the long `max-age`, and what breaks if you use that header on a non-fingerprinted URL.

## The two-layer pattern Modern asset delivery separates a **mutable index** from **immutable content**. The HTML document is short-lived or revalidated on every navigation; the assets it references carry content hashes in their filenames and are cached effectively forever. Deploying a new build writes new asset URLs and updates the HTML; clients pick up the new HTML, follow the new URLs, and the old files simply stop being referenced. No cache invalidation is required anywhere — the problem is designed out rather than managed. ## What max-age alone does not cover `max-age=31536000` (one year, the practical maximum) makes the stored response fresh for the whole period, so during ordinary browsing the client never contacts the origin. What it does not cover is user-initiated reload. Browsers treat a reload as a signal that the user suspects something is wrong, and historically revalidate subresources — issuing conditional requests with `If-None-Match` or `If-Modified-Since`. Those almost always return `304 Not Modified` with no body, so bandwidth is small, but the *latency* is not: on a high-RTT mobile link, forty conditional requests is a visible delay for zero benefit when the content is provably unchanged. ## What immutable adds RFC 8246 defines `immutable` as an assertion that the representation **will not change while it is fresh**. A client that understands it should not send a conditional request for that resource even on a normal reload. It has no effect on when the response expires, no effect on the freshness calculation, and no effect once the response is stale — at that point the client revalidates normally. It is purely a reload-behaviour optimisation, and it is safe only because the fingerprint makes the assertion true by construction. A hard reload (typically Ctrl/Cmd+Shift+R) still bypasses the cache: browsers send `Cache-Control: no-cache` on the request, and request directives outrank the stored response's `immutable`. Users always retain an escape hatch. ## What goes wrong on a stable URL Suppose `/static/app.js` — no hash — is served with `max-age=31536000, immutable`. Ship a bug, then ship the fix, and you discover the fix cannot reach anyone who loaded the page: - The browser considers its copy fresh for a year, so it makes **no request at all**, conditional or otherwise. There is no request for your CDN or origin to answer differently. - Purging the CDN does nothing, because clients are not asking the CDN. - Changing the response headers does nothing, because delivering new headers requires a request. The only real remedies are changing the URL (`app.js?v=2`, which is what fingerprinting does properly) and waiting. Query-string versioning works but is weaker: some intermediaries historically treated query strings specially, and it is easy to forget one reference. A content hash in the path is the robust form. ## Getting the HTML layer right The pattern collapses if the HTML is also cached aggressively, because clients then keep resolving the old asset URLs. Serve the entry document with `Cache-Control: no-cache` (store it, but revalidate every time — cheap, since a `304` costs no body) or a very short `max-age`. Then a deploy propagates in one round trip. The same reasoning applies to any manifest or index: service worker scripts, `manifest.json`, and API discovery documents should be revalidated, while the versioned things they point at can be immutable. ## Operational checks Before turning this on, verify three things. That the build genuinely changes the fingerprint for every content change — including for source maps, fonts and CSS referenced from CSS. That nothing rewrites asset content in place at deploy time, such as an environment-variable substitution step that mutates a built file without rehashing it. And that your CDN is not configured to strip or shorten the header. A single asset whose content changes under a stable fingerprint produces a class of bug that is essentially undebuggable from the server side, because the affected clients never make a request you can observe.