An HTTP cache can hold a response that is no longer fresh yet still avoid downloading the representation again. When the stored response carries a usable validator, the cache can send a conditional request and let the origin confirm whether the selected representation has changed.
This separates two operations that are often treated as one: checking whether cached state remains valid and transferring a new representation. A successful revalidation can perform the first without performing the second.
Freshness and validation answer different questions
Freshness determines whether a cache may reuse a stored response without contacting the origin under the applicable cache rules. A response with remaining freshness lifetime can often be served directly. Once it becomes stale, reuse commonly requires validation unless another directive or permitted stale-use condition applies.
A validator gives the server a token or timestamp against which a conditional request can be evaluated. An entity tag is the more general validator because it is an opaque value selected by the origin for a representation. Last-Modified supplies a date-based validator with coarser semantics and clock-related limits.
A stale response is therefore not equivalent to an unusable response. Its body may still be exactly current. Staleness means the cache can no longer rely on freshness alone for reuse under the normal path.
If-None-Match moves comparison to the server
Suppose a cached GET response contains:
ETag: "rev-42"
Cache-Control: max-age=60After the freshness lifetime expires, a cache can issue a conditional request containing:
If-None-Match: "rev-42"For a GET or HEAD, if the server determines that the selected representation matches one of the supplied entity tags according to the required comparison semantics, it can respond with 304 Not Modified. The response carries no message content representing the resource.
The cache then combines the revalidation response with its stored response according to HTTP caching rules and can reuse the stored representation. Network communication still occurred, but representation transfer did not.
If the condition does not match, the server processes the request normally and can return the current representation, commonly with a 200 response and a new validator.
A 304 response is not a cached body
304 Not Modified has meaning only in relation to a conditional request and an existing stored representation. It is not a compact substitute for a 200 response that an arbitrary client can render independently.
The cache already possesses the content. The 304 response supplies protocol metadata needed to confirm reuse and to update stored header fields where the caching specification requires it.
This boundary matters in intermediated systems. A proxy that loses the stored representation cannot reconstruct it from a later 304. Likewise, application code that sends a conditional request but discards its local cached body has removed the state that makes the response useful.
Strong and weak entity tags carry different comparison semantics
Entity tags can be strong or weak. A weak tag is prefixed with W/, while a strong tag has no weak marker. The distinction describes the kind of equivalence asserted by the validator.
Strong comparison requires both tags to be non-weak and their opaque tag values to match. Weak comparison permits matching tags whose opaque values are equal even when one or both are weak.
If-None-Match uses weak comparison. That makes it suitable for cache validation where semantically equivalent representations can be treated as unchanged for reuse even if byte-for-byte identity is not asserted by the validator.
Other HTTP preconditions can require strong comparison because their correctness depends on a tighter representation identity. Treating every entity tag as an interchangeable version number erases this protocol distinction.
Validator scope follows the selected representation
An entity tag validates a selected representation, not an abstract resource independent of content negotiation. A server can produce different representations for the same target based on request fields such as Accept-Encoding or Accept-Language.
When a response varies based on request fields, Vary informs caches which request fields participate in cache-key matching. Revalidation must operate on the stored response selected for the current request, including those variation rules.
A validator that is safe for one representation variant is not automatically safe for every variant. Origin implementations that generate entity tags must account for the representation data and transformations covered by the tag’s intended semantics.
This becomes visible when compression is applied at different layers. If two encodings receive the same strong entity tag even though their representation data differs, the tag asserts an equivalence stronger than the bytes support. A weak validator or variant-specific strong tags can represent different semantics, depending on the server design.
Revalidation reduces bytes, not round trips
A 304 path still requires a request to reach a validating server and a response to return. Its main transfer advantage is that the representation body need not cross the network again.
For a large representation, that can make the response much smaller. For a tiny representation on a high-latency path, the saved bytes may matter less than the validation round trip. HTTP caching semantics do not promise a performance gain for every request shape.
Freshness and revalidation therefore optimize different resources. A fresh cache hit can avoid both origin contact and body transfer. A successful stale revalidation retains origin contact while avoiding body transfer. A changed representation requires both contact and new content transfer.
Intermediaries create multiple validation boundaries
A browser cache, shared proxy, reverse proxy, and origin can each participate in caching subject to their directives and implementation roles. A conditional request from one layer does not imply that every upstream layer contacts the final application.
An intermediary with a stored response may satisfy a downstream request from fresh state, or it may revalidate upstream when its own stored response requires validation. The observable Age, cache directives, validators, and response status describe parts of this chain, but they do not imply a single universal cache topology.
This layering also means that changing application data does not directly erase every cached representation. Cache behavior follows freshness, invalidation, validation, and directive semantics at each participating cache.
Validators are protocol state, not decorative metadata
An entity tag has operational value only when its generation and comparison semantics track the representation changes relevant to the server. A tag that remains constant across materially changed representations can cause successful validation of obsolete content. A tag that changes on every request prevents successful revalidation even when the representation is stable.
The useful contract is neither maximum tag churn nor permanent stability. The validator must change according to the equivalence relation it claims, and caches must apply it through the conditional-request rules defined by HTTP.
That contract makes stale cached content recoverable as reusable state. The cache keeps the representation, the server evaluates the validator, and the protocol transfers new content only when the condition indicates that the stored representation no longer matches.