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’ header¹¹; 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.