Other meanings of HTTP caching
Web protocols
HTTP caching is a mechanism for storing HTTP responses to reduce latency and bandwidth. A cache may reuse a stored response for a later request when the response's rules permit it, avoiding a trip to the origin server while preserving the semantics of the HTTP protocol.1
HTTP caching works by associating a stored response with a request and testing whether that response can be reused. A cache considers the request method, target URI, response status, headers, freshness information, and applicable directives before serving stored bytes.1 The most common case is a successful GET response, although cacheability is governed by protocol rules rather than by the method name alone.
A response is fresh when its current age is within its freshness lifetime. Freshness can be supplied by Cache-Control: max-age, an Expires date, or heuristic rules where permitted. When a response is stale, the cache normally revalidates it instead of immediately discarding it; a successful check may return the stored representation again.
Private browser caches, shared proxy caches, and content delivery networks all implement this model, but their storage scope and policy controls differ.
HTTP response headers determine how long a representation may be reused and how its identity should be compared. Cache-Control supplies directives such as public, private, no-cache, no-store, must-revalidate, and s-maxage; these directives have distinct meanings and are not interchangeable.1
Validation usually uses an ETag or Last-Modified value. The client or cache sends If-None-Match or If-Modified-Since; if the representation has not changed, the origin can answer 304 Not Modified, allowing the cache to retain the body while refreshing metadata.2 An ETag may be strong or weak, and weak validators are unsuitable for some byte-for-byte comparison requirements.
The Vary header expands a cache key according to selected request headers, such as Accept-Encoding or Accept-Language. Poorly chosen variation can reduce hit rates or, in unsafe configurations, deliver the wrong representation.
Effective HTTP caching depends on matching policy to the resource's change pattern. Versioned static assets can receive long freshness lifetimes because changing the filename, often by including a content hash, creates a new cache key; HTML documents and personalized API responses usually need shorter lifetimes or private storage.
A shared cache must not reuse a response containing user-specific data unless the response explicitly permits that behavior. Authentication, cookies, authorization decisions, and content negotiation can therefore affect cacheability and cache keys.1 private restricts storage to a private cache, while no-store requests that caches not store the response.
Invalidation is difficult because copies may exist in browsers, intermediary proxies, and a content delivery network. Deployments commonly combine conservative HTML caching with asset versioning, explicit purge mechanisms, and revalidation. The Age header and the standardized Cache-Status field can help expose how an intermediary handled a request.4
HTTP caching has edge cases that make a cache hit more than a simple lookup. A cache can satisfy a request with a stored response while forwarding a conditional request in parallel, a pattern described by stale-while-revalidate; stale-if-error permits controlled reuse when an origin is unavailable.3 These extensions can improve resilience but require deliberate limits on staleness.
Requests and responses can carry separate cache directives, and a cache may combine metadata from a 304 response with a stored body. A response's apparent age also reflects time spent in other caches, not merely the time since it was stored locally.1
Cache poisoning and cache deception are security concerns: ambiguous parsing, incomplete cache keys, or unkeyed request inputs can cause one request's response to be served to another. The HTTP specifications consequently treat cache correctness as a protocol and security property, not merely as a performance optimization.
HTTP caching concerns protocol-defined storage and reuse of HTTP responses; it does not refer to application-level memoization or database caching.
Help improve the encyclopedia. Reports go straight to the site manager.