Conditional Request Caching
Conditional request caching sends a validator — ETag or Last-Modified — so the server can return 304 Not Modified when the representation is unchanged, transferring zero body bytes.
Definition
Conditional request caching is the HTTP mechanism where the client sends a validator (If-None-Match with an ETag, If-Modified-Since with a date) and the server returns 304 Not Modified with no body when the representation has not changed, so that an unmodified resource costs only the header round-trip, not the body transfer.
Context and scope
Applied in browser caching, API clients, and any HTTP interaction where the resource changes infrequently and the body is large relative to the headers.
Common misconceptions
- A 304 is just a cache hit — it is a server-validated cache hit; a local cache hit returns no request at all, which is cheaper still
- ETags are just hashes — they are version identifiers; a weak ETag allows semantically-equal responses, a strong ETag requires byte-equality
Anti-patterns
- Generating ETags with a weak hash that collides across different representations, returning 304 for content that changed
- Sending If-None-Match without storing the response body, so the 304 cannot be used to reassemble the cached representation
Related concepts
Authoritative source
What it is
Conditional request caching is the HTTP mechanism where the client sends a validator (If-None-Match with an ETag, If-Modified-Since with a date) and the server returns 304 Not Modified with no body when the representation has not changed, so that an unmodified resource costs only the header round-trip, not the body transfer. Applied in browser caching, API clients, and any HTTP interaction where the resource changes infrequently and the body is large relative to the headers. The protocol’s semantics — safe versus unsafe, idempotent versus non-idempotent, cacheable versus non-cacheable — are contracts the client and intermediary rely on, and violating them breaks the web.
How it works
Headers carry the negotiation: content type, encoding, caching directives, and conditional request validators together let a client and server reach the cheapest correct response. Connection reuse eliminates handshake overhead; multiplexing removes head-of-line blocking; streaming avoids buffering the entire body. Each feature has a failure mode — keep-alive on a broken proxy, multiplexing with a misbehaving server — that must be detected and handled.
When to apply and pitfalls
Apply whenever a client and server communicate across a trust boundary the protocol already spans. The pitfall is treating HTTP as a transport and ignoring its semantics — POSTing a retrieval, marking a mutating request cacheable, or omitting the validator that would enable a 304. Intermediaries — CDNs, proxies — implement the standard literally, so semantic violations produce surprising behavior far from the origin.