Caching
Cache-Control: design and verify a caching policy
Reading the directives is not the same as shipping a policy that holds under a CDN. Build a small app with the four canonical route shapes — personalized HTML, hashed static assets, a cacheable public API, a sensitive endpoint — give each the right Cache-Control, then prove it on the wire, including by triggering the private leak and watching it disappear once you fix it.
Turn the unit’s decision tree into a verified, per-route caching policy: pick directives by sharing and freshness needs, observe what browser and CDN actually do via cache-status and Age headers, and demonstrate both the failure mode and the fix with captured evidence.
Build (or take) a small app served through a real CDN or a local shared-cache proxy, design a per-route Cache-Control policy for four route shapes, and prove with observed headers that personalized data never leaks into a shared cache, static assets cache for a year correctly, and the public API serves stale-but-fast under stale-while-revalidate.
- A policy table mapping each of the four routes to its Cache-Control header and the store/reuse justification, matching what the live responses actually send.
- Captured response headers (or cache-status lines) proving: the dashboard is never in the shared cache, the bundle is served immutable and not revalidated on reload, and the public API returns a stale HIT under stale-while-revalidate with Age past s-maxage.
- A before/after capture of the private leak: user B receiving user A's dashboard under public, then a clean re-fetch per user once private, no-store is restored.
- A one-paragraph write-up explaining why each route's directive was chosen and which specific incident it prevents (bfcache leak, CDN poisoning, origin hammering, year-long stale asset).
- Add a Vary experiment: set Vary: Cookie on a near-personalized route, measure the hit-rate collapse from cache fragmentation, and confirm whether your CDN actually honors Vary — then argue why private/no-store, not Vary, must carry the safety.
- Add stale-if-error to the public API, take the origin down, and show the CDN serving stale instead of an error for the configured window.
- Add a CI check that fails the build if any authenticated route ships a header lacking private or no-store, scanning the route table or a captured header snapshot.
- Repeat the public-API measurement on a second CDN/proxy and compare how each interprets s-maxage, stale-while-revalidate, and Vary — documenting any vendor-specific deviations.
This is the loop you will run for every route in a real system: ask the two questions first — may a cache store this, and may it reuse a stored copy without revalidating — then pick directives by sharing and freshness, assuming a CDN sits in front whether you see it or not. no-store for sensitive data, private for per-user, public + immutable + a year for content-hashed assets, and max-age/s-maxage/stale-while-revalidate tuned per tier for the public API. Then prove it on the wire: observe the cache-status and Age headers, deliberately trigger the private leak, and watch it vanish once the directive is right. Doing this once on a toy app makes the production policy review muscle memory.