HTTP Caching

HTTP caching is the family of mechanisms that lets clients and intermediaries reuse a previously fetched response instead of re-fetching it from the origin. The current specification is RFC 9111, which superseded RFC 7234 in 2022 and refactors the older HTTP/1.1 caching rules into a protocol-version-agnostic document. Effective caching reduces latency for end users, lowers bandwidth on the network, and cuts load on origin servers. The Cache-Control response header is the primary control surface. `max-age=N` declares a response fresh for N seconds; `no-cache` permits storage but requires revalidation before every reuse; `no-store` forbids storage entirely; `public` allows shared caches to store responses that would otherwise be private (for example when an Authorization header is present); `private` restricts storage to the requesting user's browser; `s-maxage=N` overrides max-age for shared caches only; and `stale-while-revalidate=N` lets a cache serve a stale response immediately while it asynchronously fetches a fresh one. Other common directives include `must-revalidate`, `immutable`, and `no-transform`. When a stored response goes stale, the cache performs a Conditional GET using a validator. An ETag is an opaque server-generated token sent on the original response and echoed back by the client in the If-None-Match request header. Last-Modified is a coarser, timestamp-based validator paired with If-Modified-Since. If the resource is unchanged, the server returns 304 Not Modified with no body, and the cache reuses its stored representation while refreshing freshness metadata. If both validators are present, If-None-Match takes precedence. Caches arrange themselves in a hierarchy. The browser holds a per-user private cache. Beyond it sit shared caches: corporate or ISP proxies, reverse proxies in front of an application, and a Content Delivery Network (CDN) of geographically distributed edge servers. Requests that miss every layer reach the origin server. Each layer applies the same RFC 9111 rules, though CDNs and managed caches often honor extensions such as Surrogate-Control or CDN-Cache-Control. The Vary response header lists request headers that participate in the cache key, so a single URL can have multiple stored variants for content negotiation on Accept-Encoding, Accept-Language, or similar. Varying on User-Agent is usually a mistake because the header space is enormous and fragments the cache. Practical pitfalls include heuristic caching of responses that omit Cache-Control, cache poisoning when Vary is incomplete, and stale assets caused by aggressive max-age values without cache busting via versioned URLs. A common pattern is `max-age=31536000, immutable` for hashed static assets and `no-cache, private` for HTML entry points.