(Schwach) ETags und Last-Modified

Question

Soweit ich die Spezifikationen verstehe, ist der ETag, der in RFC 2616 (HTTP/1.1) eingeführt wurde, ein Nachfolger (für Arten) für den Last-Modified-Header, der ist Vorschlag, dem Softwarearchitekten mehr Kontrolle über den Cache-Revalidierungsprozess zu geben.

Wenn beide Cache-Validierungs-Header (If-None-Match und If-Modified-Since) gemäß RFC 2616 vorhanden sind, sollte der Client (dh der Browser) das ETag beim Überprüfen verwenden, wenn eine Ressource vorhanden ist geändert. Gemäß Abschnitt 14.26 von RFC 2616 darf der Server NICHT mit einer 304 Not Modified antworten, wenn sich das in einem If-None-Match-Header präsentierte ETag geändert hat und der Server einen zusätzlichen If-Modified-Since-Header ignorieren muss , Falls vorhanden. Wenn der vorgestellte ETag übereinstimmt, darf er die Anfrage NICHT ausführen, es sei denn, das Datum im Last-Modified-Header sagt dies. (Wenn die präsentierten ETag passt, sollte der Server mit einem Nicht im Falle einer GET- oder HEAD-Anfrage Geändert 304 reagieren ...)

Dieser Abschnitt lässt Raum für einige Spekulationen:

• Eine starke ETag soll "immer" ändern, die Ressource ändert sich. Also, etwas mit einer anderen Antwort als einem Request mit einem unveränderten ETag und einem If-Modified-Since-Header antworten zu müssen, ist ein bisschen ein Widerspruch, weil der starke ETag sagt, dass die Ressource war Nicht modifiziert. (Obwohl, das ist nicht so fatal, weil der Server wieder die gleiche unverändert Ressource senden kann.)
• ...

... o.k. Während ich dies schrieb, war die Frage auf diese Antwort zusammenkochen:

Der (kleine) Widerspruch, der oben angegeben wurde, wurde wegen der schwachen ETags gemacht. Eine Ressource, die mit einem schwachen ETag markiert ist, hat sich möglicherweise geändert, obwohl ETag dies nicht getan hat. Also, im Falle eines schwachen ETag wäre es falsch, mit 304 Not Modified zu antworten, wenn sich der ETag nicht geändert hat, aber das im If-Modified-Since angezeigte Datum stimmt nicht überein, oder?

Answer 1

Der Unterschied zwischen einem regulären (starken) ETag und einem schwachen ETag besteht darin, dass ein übereinstimmender starker ETag garantiert, dass die Datei byteweise identisch ist, während ein passender schwacher ETag anzeigt, dass der Inhalt semantisch gleich ist. Wenn sich der Inhalt der Datei ändert, sollte sich auch der schwache ETag ändern. In dem von Ihnen dargestellten Szenario kann die Datei auf dem Server neuer als die zwischengespeicherte Kopie im Client sein - aber da ETag übereinstimmt, ist sie semantisch äquivalent zu der zwischengespeicherten Kopie, so dass es akzeptabel wäre, eine 304 zurückzugeben Antwort.