3.4 HTTP ETags

ETags identify a particular instance of an entity. An entity is the information transferred as the payload of a request or response. It's useful for the client to be able to ask a Web server if an entity that the client previously cached is still up to date. This is done by having the server provide ETags for all GET response bodies that can be cached, and the client sends the ETag back in requests for the same resource.

HTTP defines both strong and weak ETags. Two entities from the same URL with the same weak ETag should be mostly the same, whereas two entities from the same URL with the same strong ETag must be exactly the same. Clients can detect a weak ETag because it must begin with "W/ ". We'll ignore weak ETags for the rest of this book because WebDAV servers should and do generally implement strong ETags.

ETags are generated by the server and are opaque to the client. Whenever a cachable entity is downloaded, the server can provide an ETag in the ETag header (the format of the ETag header is simple it contains one entity tag). Any Web resource cache should store ETags in order to do cache invalidation. When the ETag changes, the entity in the cache becomes obsolete and should be discarded or updated.

The primary use of ETags is to avoid downloading a file that hasn't changed since the last time it was downloaded. The alternative is generally to use the last-modified date of a resource to see if it has changed, but this approach is less reliable, and ETags should be used whenever they are available. The mechanism is simple:

1. The server provides the ETag to the client with the ETag header on every successful GET response. The ETag header simply includes the ETag value for the current instance of the resource.

2. The client returns the ETag to the server when it checks whether it needs to download the resource again. The client puts all possible matching ETags (if multiple instances for the same URL are cached) in the If-None-Match header. If any of these ETags match the server's instance, the server responds with 412 Precondition Failed. If none of those ETags match the server's instance, the server responds with its instance body (see Listing 3-15).

Listing 3-15 Request for cached resource.

Request:

 GET /index.html HTTP/1.1 Host: nondav.example.com If-None-Match: "870be-8f0-39ee6a4d"  

Response

 HTTP/1.1 304 Not Modified Server: Apache/1.3.14 (Unix) Date: Tue, 15 Nov 1994 08:12:31 GMT ETag: "870be-8f0-39ee6a4d"  

The other header that uses ETags is If-Match, which has the opposite syntax: If the If-Match header is on a request, the server must only apply the operation if all the clauses in the header are "true" in that they match the resource being addressed.

Both the If-Match and If-None-Match headers can take multiple values separated with commas. Both headers can also have the special value *, which matches any token. Thus, If-Match: * means that the request can succeed only if the addressed resource matches any token (that means it exists). If-None-Match: * is the opposite, meaning the server should apply the operation only if the addressed resource cannot match any token (that means it does not exist).

Unless there's a very strong reason not to (I can't think of any), WebDAV servers should support ETags and return the ETag header in response to every GET request. Not only are ETags useful for saving bandwidth, they are quite necessary to prevent all lost update cases. The WebDAV Working Group has repeatedly discussed making ETags required functionality for all WebDAV-compliant servers. The cases in which WebDAV uses ETags are discussed later.

If the server provides ETags, then clients must use ETags rather than dates to do cache validation and lost-update protection.