[joosters]

I've not seen a very convincing use-case for ETags vs Last-Modified date caching.

In the example request, the server still has to do all of the work generating the page, in order to calculate the ETag and then determine whether or not the page has changed. In most situations, it's simpler to have timestamps to compare against, because that gives the server a faster way to spot unmodified data.

e.g. you get a HTTP request for some data that you know is sourced from a particular file, or a DB table. If the client sends a If-Modified-Since (or whatever the header name is), you have a good chance to be able to check the modified time of the data source before doing any complicated data processing, and are able to send back a not modified response sooner.

[jmull]

They are essentially the same thing. Sometimes you have a last modified timestamp handy and sometimes you have a revision number handy.

I would agree that you shouldn't be doing signifiant calculations -- like checksumming the contents of a file -- to determine the current etag value.

Also, the excessive semantics of timestamps is a negative. It adds complication which sometimes trips developers up but doesn't improve the caching.

[johneth]

When I use ETags, I'll generate the ETag value once (on startup), then cache and serve that value. When the resource changes, regenerate the ETag value.

Obviously doesn't work if you're using ETags on dynamic resources, but works well for non-dynamic, but unpredictably frequently changing resources.

[derkades]

And couldn't you do the same thing with a timestamp instead of a hash?