HTTP 304 Not Modified, Request für Request simuliert

HTTP 304 Not Modified

HTTP 304 Not Modified: ETag und If-None-Match erklärt | We.Inc

Simuliere einen bedingten Request: Setze ETag und Last-Modified des Servers sowie If-None-Match und If-Modified-Since des Browsers und sieh 304 oder 200 mit der Begründung.

Eine Antwort 304 Not Modified sagt dem Browser, dass seine gecachte Kopie noch aktuell ist, daher sendet der Server den Body nicht erneut. Sie beantwortet ein bedingtes GET oder HEAD mit If-None-Match oder If-Modified-Since. Ein 304 ist eine gute Nachricht, kein Fehler: Er spart Bandbreite, während die gecachte Datei weiter genutzt wird.

Die Validator-Paare hinter einem 304

Server sendet
Browser sendet zurück
Server antwortet mit 304, wenn

ETag: "v2"
If-None-Match: "v2"
Ein aufgeführter Tag dem aktuellen ETag entspricht (schwacher Vergleich)

Last-Modified: <date>
If-Modified-Since: <date>
Die Ressource sich seit diesem Datum nicht geändert hat

Beide
Beide
If-None-Match entscheidet; If-Modified-Since wird ignoriert

Trag ein, was der Server aktuell hat und was der Browser sendet, und der Simulator wendet die Vorrangregeln aus der HTTP-Spezifikation an. Er zeigt den Status, den der Server zurückgeben sollte, und welcher Header ihn bestimmt hat. Leere ein Feld, um diesen Header wegzulassen.

Setze den ETag und den Last-Modified-Wert, den der Server gerade für die Datei hat.
Setze die Header If-None-Match und If-Modified-Since, die der Browser aus seinem Cache sendet.
Lies Status und Begründung: welcher Header ausgewertet wurde und warum er gepasst hat oder nicht.
Ändere den ETag des Servers, um zu sehen, wie ein Deploy den nächsten Request in einen 200 verwandelt.

Ein 304 muss Header wie Cache-Control, ETag, Vary und Date wiederholen, die ein 200 tragen würde, damit der Cache seine gespeicherten Metadaten aktualisieren kann.
Asset-Namen mit Fingerprint wie app.3f9a1c.js plus ein langes max-age vermeiden die Revalidierung komplett. Nutze die ETag-Revalidierung für HTML- und API-Antworten.
Schwache ETags beginnen mit W/ und versprechen inhaltliche Gleichheit, keine Byte-Gleichheit. Für If-None-Match funktionieren sie trotzdem, weil dieser Header schwach vergleicht.
In den DevTools bedeutet eine 304-Zeile mit kleiner Übertragungsgröße, dass der Browser erfolgreich revalidiert. Deaktiviere beim Debuggen den Cache im Network-Panel, um vollständige 200-Antworten zu erzwingen.

Häufige Fragen

Ist eine 304-Antwort ein Fehler?

Nein. Es ist ein Status aus der Klasse der Umleitungen und bedeutet, dass die gecachte Kopie verwendet werden darf. Der Browser zeigt die Seite aus seinem Cache, und nur Header gingen über das Netz.

Kann eine 304-Antwort einen Body haben?

Nein. Laut Spezifikation endet eine 304-Antwort mit dem Ende des Header-Abschnitts und darf keinen Inhalt enthalten.

Was gewinnt, If-None-Match oder If-Modified-Since?

If-None-Match. Trägt ein Request beide, wertet ein Server mit Unterstützung für Entity Tags If-None-Match aus und ignoriert If-Modified-Since, weil Tags Änderungen erkennen, die ein sekundengenaues Datum nicht erfasst.

Warum bekomme ich nach jedem Deploy 200 statt 304?

Der Deploy hat die Datei oder ihren ETag geändert, daher passt der Tag im Browser nicht mehr. Das ist korrektes Verhalten. Wenn auch unveränderte Dateien ihren 304 verlieren, prüfe, ob deine Server für denselben Inhalt unterschiedliche ETags erzeugen.

Gibt POST jemals 304 zurück?

Nein. If-None-Match und If-Modified-Since erzeugen nur bei GET und HEAD einen 304. Bei anderen Methoden ergibt eine nicht erfüllte Bedingung 412 Precondition Failed.

Wie Revalidierung funktioniert

Wenn eine gecachte Antwort veraltet ist, wirft der Browser sie nicht weg. Er fragt den Server, ob seine Kopie noch gültig ist, indem er die gespeicherten Validatoren sendet: den ETag als If-None-Match, das Last-Modified-Datum als If-Modified-Since.
Hat sich nichts geändert, antwortet der Server mit 304, frischen Headern und ohne Body, und der Browser nutzt weiter seine Kopie. Hat sich etwas geändert, sendet der Server einen normalen 200 mit dem neuen Inhalt.

Starke und schwache Tags

Ein starker Tag wie "v2" verspricht identische Bytes. Ein schwacher Tag wie W/"v2" verspricht nur gleichwertigen Inhalt. If-None-Match vergleicht schwach, daher gelten W/"v2" und "v2" dort als Treffer; If-Match vergleicht stark und würde das nicht tun.

Der Austausch auf der Leitung

Erster Besuch: 200 mit Validatoren

Der Server gibt zusammen mit dem Inhalt einen ETag und ein Last-Modified-Datum heraus.

Nächster Besuch: 304 ohne Body

Der Browser sendet den gespeicherten Tag zurück und bekommt nur Header.

Bedingte Requests selbst beantworten

Node-HTTP-Server mit ETag aus einem Content-Hash

Hasht den Body, vergleicht ihn mit If-None-Match und sendet bei einem Treffer 304 ohne Body.

Simulator für bedingte Requests

Was der Server gerade hat

Was der Browser sendet

ETag

Last-Modified

If-None-Match

If-Modified-Since

Antwort des Servers

If-None-Match enthält einen Tag, der beim schwachen Vergleich dem aktuellen ETag entspricht, daher ist die gecachte Kopie aktuell.

If-None-Match ist *, und die Ressource existiert, daher ist die Bedingung falsch.

Kein Tag in If-None-Match entspricht dem aktuellen ETag, daher sendet der Server den neuen Inhalt. If-Modified-Since wird nicht geprüft.

Es gibt kein If-None-Match, und Last-Modified ist nicht später als If-Modified-Since.

Es gibt kein If-None-Match, und Last-Modified ist später als If-Modified-Since.

If-Modified-Since ist vorhanden, aber eines der beiden Daten ist nicht lesbar, daher wird der Header ignoriert.

HTTP 304 Not Modified, Request für Request simuliert