Node: Cache transparency, Next: , Previous: Caching, Up: Caching



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


Footnotes

  1. Or the obsolete Pragma header.