If-None-Match

Der HTTP If-None-Match Request-Header macht eine Anfrage konditional. Der Server gibt die angeforderte Ressource in GET- und HEAD-Methoden mit einem 200-Status zurück, nur wenn es keine ETag gibt, die mit denen im If-None-Match-Header übereinstimmen. Bei anderen Methoden wird die Anfrage nur verarbeitet, wenn das eventuell vorhandene Ressourcens ETag mit keinem der aufgeführten Werte übereinstimmt.

Wenn die Bedingung für die Methoden GET und HEAD fehlschlägt, muss der Server einen 304 Not Modified zurückgeben und eines der folgenden Header-Felder, die in einer 200-Antwort auf die gleiche Anfrage gesendet worden wären: Cache-Control, Content-Location, Date, ETag, Expires und Vary. Für Methoden, die serverseitige Änderungen anwendenden, wird der 412 Precondition Failed verwendet, wenn die Bedingung fehlschlägt.

Der Vergleich mit dem gespeicherten ETag verwendet den schwachen Vergleichsalgorithmus, was bedeutet, dass zwei Dateien als identisch betrachtet werden, wenn der Inhalt äquivalent ist – sie müssen nicht Byte für Byte identisch sein. Zum Beispiel würden zwei Seiten, die sich nur im Erstellungsdatum im Footer unterscheiden, immer noch als identisch betrachtet werden.

Wenn If-None-Match in Kombination mit If-Modified-Since verwendet wird, hat If-None-Match Vorrang, wenn der Server es unterstützt.

Es gibt zwei häufige Fälle zur Verwendung von If-None-Match in Anfragen:

• Für GET- und HEAD-Methoden, um eine zwischengespeicherte Entität zu aktualisieren, die mit einem ETag verknüpft ist.
• Für andere Methoden, insbesondere für PUT, kann If-None-Match mit dem Wert * verwendet werden, um eine Datei nur zu speichern, wenn sie noch nicht existiert, wobei sichergestellt wird, dass der Upload nicht versehentlich einen anderen Upload überschreibt und die Daten des vorherigen PUT verliert; dieses Problem ist eine Variante des Problemd der verlorenen Aktualisierung.