Caching
Cache-Control: multiple-choice review
Crux Multiple-choice synthesis across the Cache-Control unit — storage vs revalidation, shared-cache TTLs, the private leak, immutable assets, and stale serving.
Your altitude — climbing toward senior
ZeroJuniorMiddleSenior
You are at senior altitude — in orbitSix questions across the whole unit. Each maps to a header you would actually ship — and to the silent incident that follows when a directive does something other than what its name suggests.
Goal
Confirm you can pick the right directive for storage vs revalidation, separate browser TTLs from CDN TTLs, and reason about the leaks and traps that the defaults set up.
Quiz
Completed
A team ships Cache-Control: no-cache on a bank-balance endpoint, intending that nothing is ever stored. A kiosk later shows one customer the previous customer's balance on a back-button press. What went wrong?
Heads-up The browser behaved to spec: bfcache restores a stored page without a fresh request, and no-cache never forbade storage. The bug is choosing no-cache instead of no-store for data that must never be stored.
Heads-up max-age=0 means 'stale immediately, revalidate', not 'do not store'. The response is still written to cache and bfcache. Only no-store prevents storage.
Heads-up An ETag makes revalidation efficient but does not stop storage, and bfcache restores without any conditional request at all. Sensitive per-request data needs no-store, not better revalidation.
Quiz
Completed
You set Cache-Control: max-age=0 on your HTML to keep browsers always fresh. A CDN sits in front. With no s-maxage, what happens at the CDN?
Heads-up Compliant shared caches honor max-age unless s-maxage overrides it; they do not silently substitute a default when max-age is present.
Heads-up max-age=0 still permits storage; it just marks the copy immediately stale and forces revalidation. The CDN does store and does revalidate against the origin every time.
Heads-up It covers both, but with the SAME value. The point of s-maxage is to let the shared cache use a longer TTL than the browser while keeping browsers fresh.
Quiz
Completed
An authenticated /account route is served with Cache-Control: public, max-age=300 behind a CDN. Every visitor for the next five minutes sees the first user's account page. The root cause?
Heads-up A CDN keys on URL plus whatever Vary tells it; absent Vary: Cookie it treats all /account requests as one resource. And Vary is ignored by some CDNs — the real safety is private/no-store, not auto-keying.
Heads-up Any non-zero shared TTL on personalized content leaks it — shortening the window only shrinks the blast radius. The fix is private to keep it off shared caches, not a smaller number.
Heads-up Revalidation is irrelevant here: the content is fresh within max-age, so the CDN serves the cached copy without revalidating at all. The defect is a shared cache storing a per-user response — a public/private problem.
Quiz
Completed
Static bundles are served with Cache-Control: public, max-age=31536000, immutable. What single practice makes a one-year cache safe rather than a one-year bug?
Heads-up immutable tells caches to skip revalidation while fresh, which directly contradicts must-revalidate; mixing them does not help. Safety comes from changing the URL on change, via content hashing.
Heads-up Purging cannot reach a browser holding an immutable copy for a year, and racing a global purge against live traffic is fragile. A new hashed URL sidesteps the problem entirely — no purge needed.
Heads-up That throws away the win of immutable plus one-year caching and still re-fetches unchanged files. The correct pattern keeps the year and changes the URL only when the bytes change.
Quiz
Completed
A CDN-fronted JSON API ships Cache-Control: max-age=60, s-maxage=300, stale-while-revalidate=3600. What is the resulting behaviour?
Heads-up stale-while-revalidate does not extend freshness; the copy is fresh only for s-maxage=300. The 3600s is the window in which a STALE copy may be served while a background refresh runs.
Heads-up s-maxage applies only to shared caches. Browsers (private caches) ignore it and use max-age=60.
Heads-up That ignores both s-maxage (the CDN stays fresh for 300s) and stale-while-revalidate (the CDN serves stale instantly and refreshes asynchronously). The origin is not in the request path during the stale window.
Quiz
Completed
A response sets Vary: Cookie to keep a logged-in page off shared caches. Why is this an unreliable safety mechanism for per-user content?
Heads-up Vary changes how a cache keys variants, not whether a shared cache may store the response at all. And because some CDNs ignore Vary, relying on it for correctness can leak one user's page to another.
Heads-up Lifetime is unrelated to the keying/sharing problem. A higher max-age does nothing to keep a personalized response off shared caches.
Heads-up Vary applies to any header it names, including Cookie and Authorization. The real problem is that keying is not the same as exclusion, and inconsistent CDN support makes it unreliable for safety.
Recap
The unit’s through-line is one decision tree. First ask whether a cache may store the response at all: no-store is the only directive that forbids storage, and no-cache merely forces revalidation, which is why no-cache leaks sensitive data into the browser and bfcache. Then separate the tiers: max-age governs every cache, s-maxage overrides it for shared caches only, and private keeps per-user responses off the CDN — its absence on an authenticated route is the classic data-leak. For static assets, public, max-age=31536000, immutable is correct only with content-hashed filenames, because a changed file then changes the URL. stale-while-revalidate and stale-if-error trade staleness for latency and resilience, and Vary keys variants rather than excluding sharing — so the real safety always lives in private/no-store.