= HTTP response delay
{c}
{title2=$\delta=t_r-t_q$}
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>:
$$
\delta=t_r-t_q.
$$
The interval corrects the age information carried in the response for time spent obtaining it. It is one input to cache-age estimation.<HTTP Caching>[§4.2.3, request_time, response_time and response_delay]{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 is
$$
a_{\mathrm{corr}}=12+3.5=15.5\ \text{seconds}.
$$
After another four seconds of local residence, using that corrected initial age would give $19.5$ seconds of current age.<HTTP Caching>[§4.2.3, corrected_age_value and residence-time equations]{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.<HTTP Caching>[§4.2.3, corrected_initial_age alternatives]{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.
Back to article page
