Web Caching

Validation

I’ve already discussed cache validation in the context of cache hits versus misses. Upon receiving a request for a cached object, the cache may want to validate the object with the origin server. If the cached object is still valid, the server replies with a short HTTP 304 (Not Modified) message. Otherwise, the entire new object is sent. HTTP/1.1 provides two validation mechanisms: last-modified timestamps and entity tags.

Last-modified Timestamps

Under HTTP/1.0, timestamps are the only type of validator. Even though HTTP/1.1 provides a new technique, last-modified timestamps remain in widespread use. Most HTTP responses include a Last-modified header that specifies the time when the resource was last changed on the origin server. The Last-modified timestamp is given in Greenwich Mean Time (GMT) with one-second resolution, for example:

HTTP/1.1 200 OK
Date: Sun, 04 Mar 2001 03:57:45 GMT
Last-Modified: Fri, 02 Mar 2001 04:09:20 GMT

For objects that correspond to regular files on the origin server, this timestamp is the filesystem modification time.

When a cache validates an object, this same timestamp is sent in the If-modified-since header of a conditional GET request.

GET http://www.ircache.net/ HTTP/1.1
If-Modified-Since: Wed, 14 Feb 2001 15:35:26 GMT

If the server’s response is 304 (Not Modified), the cache’s object is still valid. In this case, the cache must update the object to reflect any new HTTP response header values, such as Date and Expires. If the server’s ...