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