if-modified-since vs if-none-match

Question

Hi,

What could be the difference between if-modified-since and if-none-match? I have a feeling that if-none-match is used for files whereas if-modified-since is used for pages?

Answer 1

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.

Answer 2

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.

Answer 3

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

Answer 4

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.