HTTP current age

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]

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.

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.