Home > Protocol Analysis > HTTP Cache Control and the ETag

HTTP Cache Control and the ETag

August 16th, 2012

HTTP and 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"


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.


  • 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.
Categories: Protocol Analysis Tags: ,
Comments are closed.