 HTTP apparent age

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.