Für zwei nachfolgende Anfragen, welche der folgenden zwei Überschriften wird von Browsern mehr Gewicht gegeben sollte einer von ihnen ändern: ETag oder Last-Modified?Was hat Vorrang: der HTTP-Header ETag oder Last-Modified?
Ist es nicht mehr wie ein "OR" Ausdruck. In Pseudo-Code:
if ETagFromServer != ETagOnClient || LastModifiedFromServer != LastModifiedOnClient
GetFromServer
else
GetFromCache
Nach RFC 2616 Abschnitt 13.3.4, muss ein HTTP 1.1-Client den ETag in allen Cache-bedingten Anforderungen verwenden, und wenn sowohl ein ETag und Last Modified vorhanden sind, sollten sie beide verwenden. Der ETag-Header wird als starker Validator betrachtet (siehe Abschnitt 13.3.3), sofern er nicht vom Server als schwach deklariert wird, während der Header Last Modified als schwach angesehen wird, es sei denn, es besteht mindestens eine winzige Differenz zwischen ihm und dem Date-Header. Beachten Sie jedoch, dass der Server nicht gesendet werden muss (aber SOLLTE, wenn es möglich ist).
Beachten Sie, dass der Client die Header nicht überprüft, um festzustellen, ob sie sich geändert haben. es benutzt sie nur blind in der nächsten bedingten Anfrage; Der Server muss entscheiden, ob er den angeforderten Inhalt oder eine 304 Not Modified-Antwort sendet. Wenn der Server nur einen Server sendet, verwendet der Client nur diesen Server (obwohl nur starke Validierer für eine Range-Anforderung nützlich sind). Natürlich liegt es auch im Ermessen von Zwischen-Caches (außer sie wurden daran gehindert, über Cache-Control-Direktiven zwischenzuspeichern) und des Servers, wie sie auf die Header reagieren werden; Der RFC gibt an, dass sie KEINE 304 NICHT MODIFIZIERT zurückgeben dürfen, wenn die Validatoren inkonsistent sind, aber da die Headerwerte vom Server generiert werden, hat sie ziemlich viel Spielraum.
In der Praxis habe ich festgestellt, dass Chrome, FireFox und IE 7+ beide Header senden, sofern verfügbar. Ich habe auch das Verhalten beim Senden von modifizierten Kopfzeilen getestet, was ich bereits aus den Informationen im RFC vermutet hatte. Die vier Clients, die ich getestet habe, haben nur bedingte Anforderungen gesendet, wenn die Seite (n) aktualisiert wurden oder wenn die Seite zum ersten Mal vom aktuellen Prozess angefordert wurde.
Große Antwort, Thomas. Vielen Dank für die Bereitstellung der offiziellen Spezifikationen und die Diskussion aktueller Browser-Implementierungen. – dthrasher
Zitat aus Abschnitt 14.26, ** der Server darf die angeforderte Methode NICHT durchführen, es sei denn, dies ist erforderlich, da das Änderungsdatum der Ressource nicht mit dem in einem If-Modified-Since-Headerfeld in der Anfrage angegebenen übereinstimmt. ** Looks wie If-Modified-Since hat Vorrang. – Vicary
=! ist der richtige Vergleichsoperator. Der Client muss die Literalzeichenfolge vom Server erhalten, da Konvertierungen kleine Unterschiede erzeugen können. Sie können nicht davon ausgehen, dass "neuere ist besser".
Warum? Betrachten Sie den Fall, in dem der Server-Operator eine fehlerhafte Version einer Ressource zurücksetzt. Die umgekehrte Version ist ÄLTER - aber korrekt.
Der Client muss die aktuell vom Server angebotene Version verwenden; Es kann nur eine zwischengespeicherte Version verwenden, wenn es identisch ist. Daher muss der Server die Gleichheit überprüfen, nicht "neuer".
Ich denke, der letzte modifizierte Zeitstempel sollte anders verglichen werden, wie in: wenn ETagFromServer! = ETagOnClient || LastModifiedFromServer> LastModifiedOnClient – RoyM
Es ist eine AND-Anweisung, da das ETag möglicherweise schwach ist. In diesem Fall könnten Sie eine semantisch äquivalente Entität haben und dann auf die zuletzt geänderte Überschrift zurückgreifen. Betrachten Sie eine Situation, in der ein Bild neu codiert werden könnte und wir sagen möchten, dass das Original und die Neucodierung identisch sind, obwohl sie nicht Byte-identisch sind. In diesem Fall wollen wir das zuletzt modifizierte als Fallback verwenden und deshalb müssen beide BEIDE konsistent sein. – ParoX