Freshness and validation answer different cache questions

HTTP freshness compares a response's freshness lifetime with its current age. Explicit directives such as max-age establish a lifetime, while shared-cache directives can change the applicable choice. Current age includes corrected age when the cache received the response plus subsequent residence time; it is not simply time since this particular process inserted the entry. Date, Age, response timing, and transit contribute under the specification's age calculation. A response can already be old when a downstream cache sees it, so resetting its age to zero at every hop would improperly extend freshness.

A simplified exercise can supply corrected initial age directly, then add local residence to avoid pretending to implement all clock corrections. Freshness lifetime must be strictly greater than current age for ordinary fresh reuse; equality is not fresh. Request directives and response restrictions can still require validation, and stale-serving rules have explicit conditions. A cache must not turn 'stale' into 'always unusable' or 'always acceptable.' Record the policy under which reuse occurs, especially when availability behavior deliberately permits stale responses during a failure or a bounded background revalidation interval.

An entity tag identifies a representation version under the origin's validator rules. A cache can send If-None-Match for the selected stored response; an applicable 304 response lets it reuse the stored content with metadata updates rather than receiving a new body. A 304 is not a redirect and does not supply a replacement body. Strong and weak validators support different comparisons: a weak tag can support ordinary cache validation without promising byte-for-byte identity for uses that require a strong validator. Last-Modified offers another validator with its own precision and semantics.

Validation has to correspond to the correct representation variant. A tag associated with one language or encoding must not be blindly attached to unrelated stored content. On a changed representation, the origin can return new content and a new validator. On a failed revalidation, whether stale content may be served depends on applicable directives and conditions; a network error does not rewrite the representation as fresh. Keep the stored body, validator, selection metadata, and age state coherent when replacing or updating entries so a successful conditional exchange cannot accidentally authorize the wrong bytes.

Cache-Control: no-cache permits storage but requires successful validation before reuse under its rules; no-store instructs the cache not to store the affected response information. Private controls shared-cache storage rather than encrypting content or replacing authorization. Authorization and other shared-cache conditions need their own checks. Separately, a cache can evict an otherwise fresh response because it lacks capacity. Freshness answers whether eligible stored content is reusable; eviction answers whether the cache still has it. A hit-rate dashboard that ignores validation and origin traffic can overstate how much work the cache actually avoids.

The cache lab isolates capacity and recency without HTTP semantics. Reset, explicitly set BOTH capacity C=4 and stride s=4, predict twelve hits among the sixteen requests already processed at t=0, then Play or Step. Reset and re-set BOTH C=3 and s=4; predict zero hits at t=0 because the four-address cycle exceeds capacity. The displayed request count is N=min(4096,16+floor(2t)); parameter changes retain t and recompute from an empty cache. There are no TTLs, validators, variants, or authorization checks. Explain why a toy LRU hit is not evidence that an HTTP response is fresh or permitted for reuse.