The Runtime Theory

HTTP Cache Check Flow: Fresh Hits, Conditional Revalidation, and 304s

See how a browser HTTP cache decides between a fresh hit, a conditional GET with ETag and If-Modified-Since, and a full refetch — including no-store and no-cache.

The Runtime Theory Team08 stages

trace / request.md

CACHE LOOKUPFRESH: SERVEFROM CACHESTALE:REVALIDATION NEEDEDCONDITIONAL GET304 NOT MODIFIED200 WITH NEW BODYNO-STORE BYPASSESNO-CACHEREVALIDATES ALWAYS

readyThe browser looks the URL up in its HTTP cache. No entry at all — the request goes straight to the network with nothing cached to revalidate.

A cache exists to trade a network round trip for a conditional one. On the first request, the server's response carries its own expiration policy: max-age says how long the body is authoritative, ETag and Last-Modified give it a fingerprint. Every later request is a decision at the cache: is the stored copy still fresh? Then serve it and touch nothing. Stale? Then revalidate with a conditional GET.

The clever part is what a 304 means: the body was never retransmitted — only headers. Stale metadata gets refreshed, the cached body stays, and the next request is a hit again. That is why ordering matters: validators are compared first, and only a mismatch triggers a full download. When freshness is ambiguous or absent, the browser falls back to heuristics, and when the server says no-store, the cache surrenders entirely — correctness beats bandwidth every time.