Overview of Cache Operation
Proper cache operation preserves the semantics of HTTP transfers while reducing the transmission of information already held in the cache. See Section 3 for details of how a cache can determine what responses are cacheable and Section 4 for details of constructing responses from cache entries. This section provides an overview of how caches select and update stored responses.
Although caching is an entirely OPTIONAL feature of HTTP, it can be assumed that reusing a cached response is desirable and that such reuse is the default behavior when no requirement or local configuration prevents it. Therefore, HTTP cache requirements are focused on preventing a cache from either storing a non-reusable response or reusing a stored response inappropriately, rather than mandating that caches always store and reuse particular responses.
The query component of a request target (Section 5.3 of [RFC7230]) can contain information about the request that is specific to one user, a cohort of users, or the user's current state. In general, it is not safe for a cache to reuse a response to a request with a query component to satisfy that same request from another user, since the users might have different query values in their requests even if the path portions are the same. A cache recipient receiving a successful response with a query component in the request target SHOULD NOT reuse that response for a request with a different query component, unless the response explicitly allows it with Cache-Control directives (Section 5.2).
A cache can store and reuse a response to a request with a query component if the response is explicitly allowed by Cache-Control directives or the response contains a validator (Section 2.3 of [RFC7232]) and the cache follows the validation requirements. When this happens, a cache MAY use that response to satisfy a different request, subject to the constraint that the cache key matches (Section 4.1), all applicable freshness requirements are met (Section 4.2), and any applicable cache requirements imposed by the request and the stored response are met.
Various mechanisms exist by which a cache can learn about a cached response's current validity. A cached response is "fresh" if its age has not yet exceeded its freshness lifetime. Conversely, a cached response is "stale" if it has been in cache long enough to meet or pass its freshness lifetime.
A fresh response can be used to satisfy subsequent requests without contacting the origin server, thereby improving efficiency. The protocol includes mechanisms for an origin server to assign an explicit freshness lifetime, the calculation of a heuristic freshness lifetime when an explicit one is not set, and a mechanism for validating a cached response to extend its freshness lifetime after it has become stale.
The primary mechanism for assigning freshness is for an origin server to send an explicit expiration time via either the Expires header field (Section 5.3) or the max-age response directive (Section 5.2.2.8). Generally, origin servers will assign an explicit expiration time that is sufficient to satisfy all expected uses of the response. A liberal lifetime can be given to allow for frequent reuse by caches; a conservative lifetime can be given if content is known to vary on a regular basis.
When an explicit expiration time is not present, a cache MAY calculate a heuristic expiration time. A cache MUST NOT use heuristic expiration times for responses with status codes whose cacheability is not defined by this specification, such as redirects other than 300, 301, or 308 (see Section 6 of [RFC7231]), or when the status code indicates an error (i.e., the status code is greater than or equal to 400).
When a stored response is stale, a cache typically uses validation (conditional requests as defined in [RFC7232]) to update the stored response and avoid transferring the representation data unnecessarily. A stale response can still be used, without validation, if the disconnected operation is permitted by the cache's configuration or the request directives in Cache-Control allow it (Section 5.2).