HTTP Caching, ETag, Conditional Requests & RFC 9111 Architecture Studio

Published in June 2022 as part of the core HTTP specification revision, RFC 9111 obsoleted RFC 7234 (and RFC 2616 before that). RFC 9111 formalizes modern caching behavior including the formal integration of stale-while-revalidate (RFC 5861), stale-if-error, immutable (RFC 8246), and must-understand directives. It clarifies the exact mathematical algorithms for calculating response age across clocks with skew, removes deprecated warnings, tightens heuristic freshness calculations, and standardizes how intermediate shared caches (CDNs, forward proxies) must handle status codes and Range requests.

A cache calculates current age through four distinct variables: apparent_age = max(0, response_time - date_value); response_delay = response_time - request_time; corrected_age_value = age_value + response_delay; corrected_initial_age = max(apparent_age, corrected_age_value); resident_time = now - response_time; and current_age = corrected_initial_age + resident_time. If current_age < freshness_lifetime (derived from s-maxage in shared caches, or max-age, or Expires - Date), the response is fresh and served directly from cache without contacting the origin server.

A strong entity tag (e.g. "33a64df5") guarantees octet-for-octet byte equivalence. It changes whenever any byte of the representation changes, making it mandatory for sub-range requests (Range: bytes=0-1024 with If-Range) to prevent corruption from spliced content. A weak entity tag (prefixed with W/, e.g. W/"33a64df5") indicates semantic equivalence—the resource is functionally identical for caching purposes even if byte representation differs (e.g. Gzip vs Brotli compression, or reordered JSON keys). RFC 9110 and RFC 9111 explicitly permit weak ETags for If-None-Match conditional validation (resulting in 304 Not Modified), but forbid weak ETags for state-changing preconditions (If-Match on PUT or PATCH) to prevent lost updates.

RFC 9110 Section 13.2 defines strict precedence: (1) If If-Match is present and does not match the target ETag, return 412 Precondition Failed immediately. (2) Else if If-Unmodified-Since is present and the resource has been modified after that date, return 412. (3) Else if If-None-Match is present, evaluate it using weak or strong matching depending on the method: if any tag matches, return 304 Not Modified for GET/HEAD, or 412 for state-changing methods. When If-None-Match is present, If-Modified-Since MUST be ignored by compliant caches. (4) Else if If-Modified-Since is present (only for GET/HEAD without If-None-Match), if the resource has not been modified since that timestamp, return 304 Not Modified.

One of the most pervasive misconceptions in web engineering is confusing no-cache with no-store. Cache-Control: no-cache instructs the cache that it MAY store the response in memory or disk, but it MUST revalidate the cached copy with the origin server (using ETag or Last-Modified conditional headers) before serving it to any request. If the origin returns 304 Not Modified, the cache serves the stored copy without transferring the body. In contrast, Cache-Control: no-store strictly forbids the cache from persisting any portion of the request or response to volatile or non-volatile storage, which is required for highly sensitive personal data, PCI/HIPAA secrets, and single-use tokens.

Historically, browser HTTP caches used a single cache key: (HTTP method, URL). If site A loaded a shared library from cdn.example.com/lib.js, site B could load it from the browser cache with zero network latency. However, this enabled cross-site user tracking, XS-Leaks, and timing attacks. Modern browsers (Chrome, Firefox, Safari) enforce double-keyed or triple-keyed cache partitioning: the cache key is now (Top-Level Site, Frame Origin, URL). Consequently, an asset cached by site A cannot be shared by site B even if they request the exact same URL with identical Cache-Control headers.