(Weak) ETags and Last-Modified

Question

As far as I understand the specs, the ETag, which was introduced in RFC 2616 (HTTP/1.1) is a successor (of sorts) for the Last-Modified-Header, which is proposet to give the software-architect more controll over the cache-revalidating process.

If both Cache-Validation-Headers (If-None-Match and If-Modified-Since) are present, according to RFC 2616, the client (i.e. the browser) should use the ETag when checking, if a resource has changed. According to section 14.26 of RFC 2616, the server MUST NOT respond with a 304 Not Modified, if the ETag presented in a If-None-Match-Header has changed, and the server has to ignore an additional If-Modified-Since-Header, if present. If the presented ETag matches, he MUST NOT perform the request, unless the Date in the Last-Modified-Header says so. (If the presented ETag matches, the server should respond with a 304 Not Modified in case of a GET- or HEAD-request...)

This section leaves room for some speculations:

• A strong ETag is supposed to change ''everytime'', the resource changes. So, having to responde with something else as 304 Not Modified to a request with an unchanged ETag and an If-Modified-Since-Header, which does not match is a bit of a contradiction, because the strong ETag says, that the resource was not modified. (Though, this is not that fatal, because the server can send the same unchanged resource again.)
• ...

... o.k. While I was writing this, the question was boiling down to this answer:

The (small) contradiction stated above, was made because of Weak ETags. A resource marked with a Weak ETag may have changed, although the ETag has not. So, in case of a Weak ETag it would be wrong, to answer with 304 Not Modified, when the ETag has not changed, but the date presented in the If-Modified-Since does not match, right?

Marola

ETags were introduced in the first version of HTTP/1.1, RFC 2068. And they are not a "predecessor" to Last-Modified. – Trioecious

Answer 1

The difference between a regular (strong) ETag and a weak ETag is that a matching strong ETag guarantees the file is byte-for-byte identical, whereas a matching weak ETag indicates that the content is semantically the same. So if the content of the file changes, the weak ETag should change as well.

In the scenario you present, the file on the server may be newer than the cached copy in the client -- but since the ETag matches, it is semantically equivalent to the cached copy so it would be acceptable to return a 304 response.

Persephone

It may occure acceptable. But section 14.26 of RFC 2616 explicitly states, that the server must not ;) That was my point aka question. And I think the answer is, that the ETag might have been a weak one. And in that case, it might have changed (newer Last-Modified date), though the ETag has not. – Marola

True. I guess if you have to err it would be best to err on the side of serving the file again. It doesn't hurt anything other than requiring more bytes over the wire, and you can be sure that the client has the latest version. – Persephone