Soweit ich die Spezifikationen verstehe, ist der ETag, der in RFC 2616 (HTTP/1.1) eingeführt wurde, eine Art Nachfolger für den Last-Modified-Header, der dem Software-Architekten mehr Kontrolle über den Cache-Revalidierungsprozess geben soll.
Wenn beide Cache-Validation-Header (If-None-Match und If-Modified-Since) vorhanden sind, sollte der Client (d.h. der Browser) gemäß RFC 2616 den ETag verwenden, um zu prüfen, ob sich eine Ressource geändert hat. Gemäß Abschnitt 14.26 von RFC 2616 MUSS der Server NICHT mit einem 304 Not Modified antworten, wenn sich der in einem If-None-Match-Header präsentierte ETag geändert hat, und der Server muss einen zusätzlichen If-Modified-Since-Header, falls vorhanden, ignorieren. Wenn der angegebene ETag übereinstimmt, MUSS er die Anfrage NICHT ausführen, es sei denn, das Datum im Last-Modified-Header sagt dies. (Stimmt der angegebene ETag überein, sollte der Server im Falle einer GET- oder HEAD-Anfrage mit 304 Not Modified antworten...)
Dieser Abschnitt lässt Raum für einige Spekulationen:
- Ein starker ETag soll sich "jedes Mal" ändern, wenn sich die Ressource ändert. Auf eine Anfrage mit unverändertem ETag und einem If-Modified-Since-Header, der nicht übereinstimmt, mit etwas anderem als 304 Not Modified antworten zu müssen, ist also ein ziemlicher Widerspruch, denn der starke ETag sagt aus, dass die Ressource nicht verändert wurde. (Dies ist jedoch nicht so fatal, da der Server die gleiche unveränderte Ressource erneut senden kann).
- ...
... o.k. Während ich dies schrieb, lief die Frage auf diese Antwort hinaus:
Der (kleine) Widerspruch, der oben angeführt wurde, wurde wegen der schwachen ETags gemacht. Eine Ressource, die mit einem Weak ETag gekennzeichnet ist, kann sich geändert haben, obwohl der ETag nicht geändert wurde. Im Falle eines Weak ETag wäre es also falsch, mit 304 Not Modified zu antworten, wenn sich der ETag nicht geändert hat, aber das im If-Modified-Since angegebene Datum nicht übereinstimmt, richtig?
