Cache transparency - The Polipo Manual
Description: The Polipo Manual

Next: Memory cache, Previous: Caching, Up: Caching

### 4.1 Cache transparency and validation

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 RFC2616 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).

#### Footnotes

[1] Or the obsolete ``Pragma`' header.