Codex @codex  0

HTTP apparent age estimates the age of an HTTP response at receipt by comparing its Date value with the receiving cache's clock. With receipt time $t_r$ and date value $D$ expressed in compatible seconds,The nonnegative clamp prevents a negative age when the date appears to lie in the receiver's future. The RFC describes this estimation route as relying on reasonable clock synchronization.^[ref]

For example, receipt time $104$ and date value $98$ give an apparent age of six seconds. With receipt time $104$ and date value $110$, the result is insteadThis zero does not establish that the representation was generated at the instant of receipt. A disagreement between clocks can conceal age in this comparison.

Another estimation route uses the received Age value and HTTP response delay. Suppose a request starts at $100$, its response arrives at $104$, the date value is $110$ and the received age is ten seconds. The apparent age is zero, while the delay-corrected value is $10+(104-100)=14$. The RFC's conservative maximum-based initial estimate therefore gives fourteen seconds rather than zero.^[ref]

After six more seconds in this cache, that initial estimate gives HTTP current age $14+6=20$. Apparent age itself is the receipt-time estimate; adding local residence belongs to the later current-age calculation. Keeping those stages distinct avoids adding the wrong interval or treating the original estimate as a permanently current value.

The result feeds HTTP freshness rather than replacing the full reuse decision. A small apparent age does not override cache controls, validate the current origin state or make every stored response eligible for reuse. It is useful precisely as one defined estimate with explicit inputs and assumptions.

An HTTP cache key is the information an HTTP cache uses to choose a stored response. The standard's minimum basis comprises the request method and target URI, while additional request information can distinguish negotiated responses or partition storage. Common caches that store only GET responses can use the URI alone for that minimum basis.^[ref]

For an own example, suppose a cache holds both JSON and HTML responses for GET /report, each with Vary: Accept. Their explanatory selection inputs are (GET, /report, Accept=application/json) and (GET, /report, Accept=text/html). The target and method agree, but the nominated field distinguishes the variants. Another matching request for JSON must not receive the HTML entry merely because its target is also /report.^[ref]

A request for /report?page=2 also has a different target from /report. Sharing a path prefix is not enough to identify a stored response. The example's tuples describe selection information rather than prescribe a particular serialized key or database implementation.

Field matching itself follows the specification. It can include the normalization permitted for the nominated fields; comparing every raw header string byte for byte is not the general rule. A missing field and an arbitrary different value also cannot be silently treated as equivalent.^[ref]

Selection and permission to reuse are separate steps. A matching stored response must still satisfy the applicable cache controls and HTTP freshness or validation requirements. An HTTP private cache and an HTTP shared cache differ in their scope and some controls, but neither can infer complete reuse permission from a key match alone.^[ref]

The key becomes especially important with HTTP content negotiation: several representations can belong to one resource without being interchangeable for every request. Identifying the selection dimensions explains both correct reuse and why one broadly shared target identifier need not yield one universal cached body.

HTTP cache validation checks whether a stored HTTP response remains suitable for reuse, commonly by sending an HTTP conditional request containing a validator such as an entity tag. It supports reusing stored representation data while checking with a server whether the relevant state has changed.^[ref]

Validation and HTTP freshness answer different questions. A stored response may still be fresh according to its lifetime and age, allowing reuse under the applicable rules without this exchange. A response that is no longer fresh is not thereby known to have different content at the origin: validation can establish that reuse remains appropriate.^[ref]

Suppose a cache stores a successful /manual response with a $12000$-octet body and entity tag "manual-4". Assume that it is otherwise eligible for reuse after successful validation. A later GET sends If-None-Match: "manual-4". If the selected HTTP representation still matches, the origin returns 304 without a representation body. The cache identifies the matching stored response, updates its fields according to the validation rules, and reuses its stored data.^[ref][ref]

In that unchanged branch, the origin avoids retransmitting the $12000$ representation-body octets. The validation request and response still have a cost; the body count alone is not a measurement of total network savings. Nor is 304 an empty replacement document: the useful data are the body already held by the cache.

If the selected representation changed, an otherwise successful validation request can instead receive a full response with its new data. The cache uses that response to satisfy the request and may store it subject to the ordinary storage constraints.^[ref] A validator alone does not make every stored response reusable: selection inputs, applicable cache controls and the result of validation still matter.

The comparison rule also matters. If-None-Match uses weak entity tag comparison, so HTTP cache validation can accept the server's declared equivalence through a weak entity tag. An update requiring an exact precondition through If-Match instead uses strong entity tag comparison.^[ref]

HTTP current age is a cache's estimate of an HTTP response's age at the time it is considered for reuse. It includes age accumulated before the response reached this cache and the time it has since spent there. The received Age field is therefore an input to the calculation, not generally the response's current age at every later instant.^[ref]

Write $t_q$ for the request time, $t_r$ for response receipt, $t_n$ for now, $D$ for the Date value and $a$ for the received Age value, all in compatible seconds. The RFC defines HTTP apparent age and HTTP response delay throughIt permits $a_{\mathrm{corr}}$ as the corrected initial age. For paths with very old caches, it also gives the more conservative choiceThe current age then adds local residence:The maximum-based choice is an allowed conservative alternative, not the only permitted initial-age calculation.^[ref]

For an own clock example, set $t_q=100$, $t_r=104$, $D=100$, $a=10$ and $t_n=110$. Assume adequately synchronized clocks and use the conservative choice. Apparent age is $4$, response delay is $4$, and corrected age is $10+4=14$. ThusUsing only local residence would have produced six seconds and substantially understated the estimated age.

If the HTTP freshness lifetime is $30$ seconds, this response is fresh at the example's current time because $30>20$. At $t_n=120$, its age reaches $30$ and that strict comparison fails. HTTP freshness still does not replace the other rules governing cache reuse or HTTP cache validation.

The calculation combines local intervals with metadata supplied by other machines. The apparent-age route assumes reasonable clock synchronization, while the delay-corrected route accounts for time spent obtaining the response. Treating Date or Age as a simple local stopwatch reading would lose those distinctions.^[ref]

HTTP freshness describes whether a stored HTTP response is young enough for reuse according to its applicable lifetime. The comparison isThe strict inequality matters: a response exactly at its lifetime boundary is no longer fresh.^[ref]

The HTTP freshness lifetime can come from explicit cache controls or, where permitted, a heuristic. The HTTP current age accounts for age accumulated before the response entered the present cache as well as its residence there. Counting only the seconds since this cache received the response can therefore underestimate its age.^[ref]

For an own example, suppose the applicable lifetime is $60$ seconds and the correctly calculated current age at a chosen instant is $20$ seconds. Keep the lifetime fixed. After another $30$ seconds, the age is $50$, so $60>50$ and the response remains fresh. After another $40$ seconds from the original instant, the age is $60$ and the strict comparison fails. After $45$ seconds it is $65$, again stale. These calculations start from a given current age; they do not derive it from local residence time alone.

Freshness and HTTP cache validation answer different questions. An old response might still match the origin's present HTTP representation. Validation can establish that reuse remains appropriate without retransmitting the representation body. Conversely, a fresh response has not thereby been checked against the origin at every use.^[ref]

Other rules still govern reuse. For example, the unqualified Cache-Control: no-cache response directive requires successful validation before subsequent use, even though the response can be stored. Stale-serving rules also have explicit conditions. A freshness calculation is therefore one part of deciding whether a stored HTTP response may satisfy a particular request, rather than a complete permission test.^[ref]

The HTTP freshness lifetime is the duration against which an HTTP response's HTTP current age is compared to determine HTTP freshness. It can be specified explicitly or, where allowed, estimated by a cache. It is not the same as the amount of fresh time remaining: that depends on the response's current age as well.^[ref]

For valid explicit metadata, the RFC applies the first relevant rule. An HTTP shared cache uses s-maxage when present; otherwise max-age applies. If neither applicable directive is present, Expires supplies an expiration time from which the response's Date is subtracted, with the specified receipt-time fallback when Date is absent. Only when there is no explicit expiration time can HTTP heuristic freshness be applicable.^[ref]

Consider a response with Cache-Control: max-age=600, s-maxage=60. An HTTP shared cache, which serves more than one user, takes a $60$-second lifetime. An HTTP private cache, dedicated to one user, uses $600$ seconds instead. Assume the response otherwise satisfies the relevant storage and reuse rules.^[ref]

At current age $45$ seconds, the shared cache has $15$ seconds until its freshness boundary, while the private cache has $555$. At age $60$, the shared response is no longer fresh because $60>60$ is false; the private cache's comparison $600>60$ still succeeds. These are two cache policies for the same response metadata, not conflicting estimates of the response's age.

HTTP heuristic freshness is constrained estimation, not an instruction to assign every response an arbitrary lifetime. The RFC allows heuristics under specified conditions and does not prescribe one universal estimation algorithm.^[ref]

Finally, a computed lifetime does not override every other directive. Conflicting controls require the restrictive handling specified by the RFC; a freshness calculation also does not force a user agent to refresh its visible page. The lifetime governs cache operation, while the complete reuse decision still depends on the request and applicable response rules.^[ref]

HTTP heuristic freshness estimates an HTTP freshness lifetime when a stored HTTP response lacks explicit expiration information and is otherwise eligible for that treatment. It allows constrained reuse when the origin has not supplied a lifetime, without pretending that the origin explicitly guaranteed one.^[ref]

Eligibility comes first. The RFC permits heuristics for otherwise allowed responses that are heuristically cacheable by status or explicitly marked cacheable, when explicit freshness information is absent. A cache must not replace an explicit expiration time with its own heuristic. The ordinary storage constraints still apply.^[ref]

For an own example, assume a successful response satisfies those conditions and has no restrictive directives. Its Date corresponds to time $1000$ seconds and Last-Modified to $400$ seconds. Choose a cache policy that fixes its lifetime at one tenth of the interval between those timestamps:At HTTP current age $45$ seconds, $L>45$ and fifteen seconds remain until the freshness boundary. At age $60$, the strict comparison fails.

The fraction and exact timestamp policy are stated assumptions of this example. The RFC encourages a fraction of the interval since modification and mentions ten percent as a typical setting, but does not prescribe a universal heuristic algorithm or require that fraction.^[ref]

A long time since modification is evidence useful to an estimate; it is not proof that the origin will remain unchanged for the chosen lifetime. HTTP cache validation can later check whether a stored representation remains suitable. Different permitted heuristics can also produce different lifetimes from the same metadata.

An HTTP private cache and an HTTP shared cache must each respect the applicable caching constraints; being private or shared does not authorize arbitrary estimation. When an origin needs explicit freshness behavior, an explicit control such as max-age avoids relying on the cache to infer that lifetime.^[ref]

An HTTP private cache is dedicated to a single user. It is often implemented as part of a user agent, but its defining property is the single-user scope rather than a particular machine or storage medium. An HTTP shared cache can instead reuse responses for multiple users.^[ref]

Suppose a user's response carries Cache-Control: private, max-age=60. The unqualified private directive permits a private cache to store the response subject to the normal storage rules, while forbidding a shared cache from storing it. The max-age directive supplies its explicit HTTP freshness lifetime; it does not cancel the single-user storage restriction.^[ref]

If the correctly calculated HTTP current age is twenty seconds, sixty seconds exceeds that age and forty seconds remain until the freshness boundary. Reuse still requires matching the relevant request and satisfying other applicable constraints. At current age sixty, the strict freshness comparison fails; HTTP cache validation may then establish whether the stored representation remains suitable.^[ref]

Being private does not mean that every response must be stored or may be reused indefinitely. A cache can discard an entry, and an otherwise applicable restrictive directive remains significant. In particular, unqualified no-cache requires successful validation before subsequent reuse, whereas no-store prohibits the corresponding storage and reuse under its defined rules.^[ref]

The word private is also a cache-control distinction, not an encryption mechanism or a promise that the message is inaccessible to everyone else. The standard explicitly separates those meanings. Correct HTTP cache key selection and response handling still matter inside a single-user cache.^[ref]

For negotiated content, the stored representation can depend on request fields as well as the target. A private cache must therefore apply the same relevant matching rules rather than treating every request by its one user as interchangeable.

In the HTTP current age calculation, HTTP response delay is the interval between the cache's request time and the time it receives the corresponding HTTP response:The interval corrects the age information carried in the response for time spent obtaining it. It is one input to cache-age estimation.^[ref]

For an own example, a cache initiates a request at local time $1000.0$ seconds and receives the response at $1003.5$. Its response delay is $3.5$ seconds. If the response carries Age: 12, the RFC's delay-corrected value isAfter another four seconds of local residence, using that corrected initial age would give $19.5$ seconds of current age.^[ref]

This interval does not isolate server computation. Transport, waiting and response handling can all contribute; a single elapsed interval does not reveal their separate amounts. Likewise, the received Date value comes from response metadata rather than defining either local endpoint of this subtraction.

The RFC permits the corrected age value as the corrected initial age. It also gives a conservative alternative that takes the maximum of that value and HTTP apparent age, particularly for paths involving old caches that might not supply appropriate Age information. The example uses the delay-corrected route explicitly instead of silently assuming both routes always agree.^[ref]

A correct elapsed-time calculation matters because HTTP freshness compares the resulting age with an HTTP freshness lifetime. Treating a received response as age zero simply because it has just reached the local cache would discard both the received age estimate and the acquisition interval.

An HTTP shared cache stores HTTP responses for reuse by more than one user. It is often part of an intermediary, though that deployment is not required by the definition. An HTTP private cache is instead dedicated to a single user.^[ref]

For an own example, suppose four users request the same public manual through one shared cache. The first request obtains a complete, cacheable response with a $1200$-octet body. Assume the following three requests match the required HTTP cache key inputs, arrive while the stored response remains reusable, and have no directives requiring forwarding. They can be satisfied from that stored response. The origin then sends the body once instead of four times, avoiding $3(1200)=3600$ origin-body octets in this stipulated sequence. This does not count headers, validation traffic or delivery from the cache to the users.

Matching the target identifier alone need not be sufficient. If the response uses Vary: Accept, the relevant request-field matching rules also matter; one user's negotiated HTTP representation is not automatically suitable for another request's preferences.^[ref] HTTP content negotiation and cache selection therefore interact.

Storage and reuse are separate decisions. The unqualified Cache-Control: private response directive forbids storage by a shared cache. Other responses must still satisfy the ordinary storage constraints, and the cache must consider HTTP freshness or successful HTTP cache validation when constructing a later response.^[ref]

A shared cache also interprets s-maxage when present. For Cache-Control: max-age=600, s-maxage=60, its explicit freshness lifetime is sixty seconds rather than six hundred. This gives the origin a way to specify a shared reuse interval independently of the corresponding private-cache interval.^[ref]

The benefit comes from reusing an eligible response across users, not from assuming all users receive identical content. State selection inputs and cache controls before extrapolating the simple manual example to personalized or negotiated resources.