Script Valley
HTTP & The Web: How It Actually Works
Caching and PerformanceLesson 4.5

Why Cache-Control no-cache doesn't mean what you think

no-cache revalidation, 304 Not Modified flow, must-revalidate, proxy-revalidate, pragma header legacy, cache directive combinations

Cache-Control Misconceptions Fixed

no-store vs no-cache behavior comparison diagram

The single most common HTTP caching mistake: developers add Cache-Control: no-cache thinking it prevents caching. It does not. Here is what it actually does and how to use these directives correctly.

What no-cache actually means

no-cache does NOT mean 'do not cache'. It means: cache the response but do not serve it from cache without first checking with the origin server. The browser stores the response and sends a conditional request (with If-None-Match or If-Modified-Since) on the next visit. If the server says it has not changed, a 304 is returned and the cached copy is used.

# What to use for truly uncacheable responses
Cache-Control: no-store

# Cache but always revalidate (most common 'fresh always' use case)
Cache-Control: no-cache

# Stale responses must be revalidated — no serving expired cache
Cache-Control: must-revalidate, max-age=3600

# Legacy — no longer needed but you'll see it in old apps
Pragma: no-cache  # HTTP/1.0 equivalent, ignored by HTTP/1.1 caches

must-revalidate

Normally a cache may serve a stale response if it cannot reach the origin (offline mode, network error). must-revalidate prohibits this — if the cache cannot revalidate, it must return a 504 Gateway Timeout. Use it when stale data is genuinely unacceptable (financial data, live availability).