views:

43

answers:

2

As far as I understand the specs, the ETag, which was introduced in RFC 2616 (HTTP/1.1) is a predecessor of 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 dose 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?

A: 

A weak etag is a wrong etag. The etag should change every time the resource does.

Sjoerd
That ist simply wrong.A weak ETag comes in handy, if the ressource changes, but stays the same from a semantically point of view. Think of a visit-counter in a webpage. The ressource changes, it is not byte-to-byte identical to the old version, but it can still be considered unchanged.
Kai Moritz
+1  A: 

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.

Marc Novakowski
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.
Kai Moritz
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.
Marc Novakowski