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?
