If-Amendment-since vs if-none-match

If-Modified-Since uses a date, while If-None-Match uses an ETag. They can both be used for "pages" (i.e. HTML) and other files.

If-Modified-Since is compared to the Last-Modified whereas If-None-Match is compared to ETag. Both Modified-Since and ETag can be used to identify a specific variant of a resource.

But the comparison of If-Modified-Since to Last-Modified gives you the information whether the cached variant is older or newer whereas the comparison of If-None-Match to ETag just gives you the information whether both are identical or not. Furthermore do most of the ETag generators include the information of the system specific inode so moving a file to a different drive may change the ETag as well.

Regarding the differences between Last-Modified/If-Modified-Since and ETag/If-None-Match:

Both can be used interchangeably. However depending on the type of resource, and how it is generated on the server, one or the other question ("has this been modified since ...?" / "does this still match this ETag?") may be easier to answer.

Examples:

• If you're serving files, using the file's mtime as the Last-Modified date is the simplest solution.
• If you're serving a dynamic web page built from a number of SQL queries, checking whether the data returned by any of those queries has changed may be impractical (unless all of them have some sort of "last modified" column). In this case, using e.g. an md5 hash of the page content as the ETag will be a lot easier.
  OTOH, this means that you still have to generate the whole page on the server, even for a conditional GET. Figuring out what exactly has to go into the ETag (primary keys, revision numbers, ... etc.) can save you a lot of time here.

See these links for more details on the topic:

• http://www.tbray.org/ongoing/When/200x/2008/08/14/Rails-ETags
• http://bitworking.org/news/150/REST-Tip-Deep-etags-give-you-more-benefits

Unless stated as weak by the server, an ETag is considered a strong validator, and can thus be used to satify a conditional ranged request. However, most automatically generated ETags exhibit difficulties in server farm situations, since they often use inode information and / or a unique persistent counter. In practice, I have found the Last Modified header to be sufficient for fairly static content, e.g. serving up protected static content, since the write time of the file makes a reasonably good validator.

The ETag is by far the most flexible. Conforming clients are required to send the ETag in a conditional request, whereas they SHOULD send both if available.

Timestamp value used in Last-Modified/If-Modified-Since has limited precision - one second and that is simply not enough for fast changing content like, for instance, Web-chat application where more than one message could be posted at any given second. ETag/If-None-Match can help to solve that problem.

As it is stated in google's best practices :

It is important to specify one of Expires or Cache-Control max-age, and one of Last-Modified or ETag, for all cacheable resources. It is redundant to specify both Expires and Cache-Control: max-age, or to specify both Last-Modified and ETag.

https://developers.google.com/speed/docs/best-practices/caching

The If-Modified-Since header is used to specify the time at which the browser last received the requested resource. The If-None-Match header is used to specify the entity tag that the server issued with the requested resource when it was last received.

In the two ways described, these headers are used to support caching of content within the browser, and they enable the server to instruct the browser to use a cached copy of a resource, rather than responding with the full contents of the resource if this is not necessary.