HTTP caching

If web caching is the idea of keeping nearby copies, HTTP caching is the actual rulebook the web uses to do it safely. Think of it like an expiry sticker the bakery puts on bread: the store (the server) tells each customer (the browser or proxy) how long the item stays good and how to check, when it expires, whether a fresh batch is even needed. HTTP caching is a set of response headers — fields the server attaches to its reply — that tell caches whether a response may be stored, for how long it may be reused without asking again, and how to revalidate it cheaply when in doubt.

It works on two complementary ideas. Freshness: the server can stamp a response with an expiry, using the Cache-Control header (for example, Cache-Control: max-age=3600 means usable for one hour) or the older Expires header (an absolute date). While a stored copy is still fresh, a cache may serve it with no network request at all. Validation: once a copy goes stale, the cache doesn't blindly discard it — it sends a conditional request asking the server has this changed? using a validator the server gave earlier (an ETag or a Last-Modified date). If nothing changed, the server replies 304 Not Modified with an empty body, and the cache reuses its stored copy. That 304 is tiny, so even a stale copy is cheap to confirm.

Why it matters: these headers are what make browser caches, proxies, and CDNs cooperate without a central coordinator — the server declares the policy, and every cache along the path obeys it. Getting them right is a real skill: too aggressive and users see stale pages (a common bug, often fixed by changing the URL when content changes, a trick called cache busting); too timid and you waste round trips revalidating things that rarely change. Note that Cache-Control also carries safety directives like no-store (never keep this) and private (only the user's own browser may cache it, not a shared proxy), which protect sensitive responses.