If resources on a server change, it is possible for a cached instance to become out-of date. Ideally, a cache would be perfectly transparent, meaning that it never serves an out-of-date instance; in a universe with a finite speed of signal propagation, however, this ideal is impossible to achieve.
If a caching proxy decides that a cached instance is new enough to likely still be valid, it will directly serve the instance to the client; we then say that the cache decided that the instance is fresh. When an instance is stale (not fresh), the cache will check with the upstream server whether the resource has changed; we say that the cached instance is being revalidated.
In HTTP/1.1, responsibility for revalidation is shared between the
client, the server and the proxy itself. The client can override
revalidation policy by using the Cache-Control
header1; for example,
some user-agents will request end-to-end revalidation in this way when
the user shift-clicks on reload. The server may choose to
specify revalidation policy by using the Expires
and
Cache-Control
headers. As to the proxy, it needs to choose a
revalidation policy for instances with neither server- nor client-side
cache control information. Of course, nothing (except the HTTP/1.1
spec, but that is easily ignored) prevents a proxy from overriding the
client's and server's cache control directives.
Polipo's revalidation behaviour is controlled by a number of variables. In the following, an resource's age is the time since it was last validated, either because it was fetched from the server or because it was revalidated.
If cacheIsShared
is false (the default), Polipo will ignore the
server-side Cache-Control
directives s-maxage
and
proxy-must-revalidate
. This is highly desirable behaviour, but
happens to violate RFC 2616 if the cache is shared among multiple
users.
If mindlesslyCacheVary
is true, the presence of a Vary header
(which indicates that content-negotiation occurred, see Censor Accept-Language) is ignored, and cached negotiated instances are
mindlessly returned to the client. If it is false (the default),
negotiated instances are revalidated on every client request.
The policy defining when cached instances become stale in the absence
of server-provided information is controlled by the variables
maxAge
, maxAgeFraction
, maxExpiresAge
and
maxNoModifiedAge
. If an instance has an Expires
header,
it becomes stale at the date given by that header, or when its age
becomes larger than maxExpiresAge
, whichever happens first. If
an instance has no Expires
header but has a LastModified
header, it becomes stale when its age reaches either
maxAgeFraction
of the time since it was last modified or else
the absolute value maxAge
, whichever happens first. Finally,
if an instance has neither Expires
nor Last-Modified
, it
will become stale when its age reaches maxNoModifiedAge
.
Cache transparency can be further relaxed by using the variables that control offline browsing (see Offline browsing).