The HTTP specification provides a detailed, but slightly obscure and often confusing, algorithm for computing document aging and cache freshness. In this section, we’ll discuss the HTTP freshness computation algorithms in detail (the “Fresh enough?” diamond in Figure 7-12) and explain the motivation behind them.
This section will be most useful to readers working with cache internals. To help illustrate the wording in the HTTP specification, we will make use of Perl pseudocode. If you aren’t interested in the gory details of cache expiration formulas, feel free to skip this section.
To tell whether a cached document is fresh enough to serve, a cache needs to compute only two values: the cached copy’s age and the cached copy’s freshness lifetime . If the age of a cached copy is less than the freshness lifetime, the copy is fresh enough to serve. In Perl:
$is_fresh_enough = ($age < $freshness_lifetime);
The age of the document is the total time the document has “aged” since it was sent from the server (or was last revalidated by the server). Because a cache might not know if a document response is coming from an upstream cache or a server, it can’t assume that the document is brand new. It must determine the document’s age, either from an explicit Age header (preferred) or by processing the server-generated Date header.
The freshness lifetime of a document tells how old a cached copy can get before it is no longer fresh enough to ...