HTTP Cache Control and the ETag
Download this capture file: ” IfModifieldSince_and_ETag ”
OR: view it now via Cloudshark
With caching enabled, a web server does not need to send a full response if content has not changed.
- If-Modified-Since is an HTTP request header that the client sends to your browser along with a request for content.
- Last-Modified is an HTTP response header that the server returns along with the requested content.
If-Modified-Since Allows a 304 Not Modified to be returned if content is unchanged
If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT
If-None-Match Allows a 304 Not Modified to be returned if content is unchanged,
If-None-Match: "737060cd8c082f209582d"
The HTTP ETag
An ETag or The Entity Tag (Etag) assists web cache validation, allowing a client to make conditional requests. ETags are similar to fingerprints, and they can be quickly compared to determine if two versions of a resource are the same or not.
ETags can use both strong and weak validation, distinguished by the presence of an initial “W/” in the ETag identifier:
“123456789” — A strong ETag validator
W/”123456789″ — A weak ETag validator
Strongly validated ETags ensure content is byte-for-byte identical, as well as all other entity fields (such as Content-Language) remain unchanged. (Strong ETags permit the caching and reassembly of partial responses, as with byte-range requests).
Weakly validatind ETags claim that the resources at the URL are semantically equivalent; meaning that for practical purposes they are interchangeable and that cached copies can be used. However the resources are not necessarily byte-for-byte identical.
THUS:
- Weak ETags are not suitable for byte-range requests.
- Weak ETags may be useful for cases in which strong ETags are impractical for a web server to generate, such as with dynamically-generated content.