Cache-Control header

Cache-Control governs how responses are cached by browsers, CDNs, and reverse proxies. Misconfigured = users get stale data, OR cache hit rate drops to 0.

advanced RFC 7234 §5.2 (Cache-Control)

What the RFC says

The 'Cache-Control' header field is used to specify directives for caches along the request/response chain. Such cache directives are unidirectional in that the presence of a directive in a request does not imply that the same directive is to be given in the response. (RFC 7234 §5.2) — RFC 7234 §5.2 (Cache-Control)

Example

Cache-Control: public, max-age=31536000, immutable
# 1 year, browser+CDN, content guaranteed unchanged

Cache-Control: private, max-age=0, must-revalidate
# user-specific, always revalidate before serving

Cache-Control: no-store
# never cache (sensitive data)

Cache-Control: s-maxage=3600, max-age=60
# CDN: 1h, browser: 1min

Real-world implementations

Vercel/Netlify: `public, max-age=0, must-revalidate` for HTML; `public, max-age=31536000, immutable` for hashed assets.
GitHub Pages: defaults to ~10min `max-age` (configurable via `_headers`).
Stripe API: `Cache-Control: no-cache, no-store` on all responses.

Common misuses (don't do this)

`no-cache` does NOT mean 'don't cache' — it means 'cache, but revalidate before serving'. `no-store` is the 'don't cache' you want.
Mixing `private` with CDN — CDN ignores private caching. If you want CDN cache, use `public`.
`max-age=0` and `must-revalidate` together are common, but `max-age=0` alone means stale-OK with revalidation. Be explicit.

Use cases

CDN configuration tuning
Static asset cache strategy
API response caching
GDPR-compliant cache controls (no-store on personal data)

Get the RFC reference for any HTTP response

httpwut takes a curl response and explains the status code + headers + the RFC sections you should actually read. Built for HTTP debugging that goes deeper than 'lol 500'.

Open httpwut