If-None-Match

Was bedeutet If-None-Match?

Der If-None-Match HTTP Request Header macht aus der Anforderung einen bedingten Request. Bei GET- und HEAD-Methoden sendet der Server die angeforderte Ressource mit dem Status 200 nur dann zurück, wenn kein ETag vorhanden ist, das den angegebenen Werten entspricht. Bei anderen Methoden wird die Anforderung nur verarbeitet, wenn das ETag der eventuell vorhandenen Ressource keinem der aufgelisteten Werte entspricht.

Wenn die Bedingung für die Methoden GET und HEAD fehlschlägt, muss der Server den HTTP-Statuscode 304 Not Modified (nicht modifiziert) zurückgeben. Für Methoden, die serverseitige Änderungen anwenden, wird der Statuscode 412 Precondition Failed (Vorbedingung fehlgeschlagen) verwendet. Dabei gilt es zu beachten, dass der Server, der eine 304-Antwort erzeugt, eines der folgenden Header-Felder generieren muss, die in einer 200 (OK) -Antwort an die gleiche Anfrage gesendet wurden: Cache-Control, Content-Location, Date, ETag, Expires und Vary.

Der Vergleich mit dem gespeicherten ETag verwendet den schwachen Vergleichsalgorithmus, was bedeutet, dass zwei Dateien nicht nur wenn sie Byte für Byte identisch sind als identisch angesehen werden, sondern dann, wenn der Inhalt äquivalent ist. Beispielsweise würden zwei Seiten, die sich nur durch das Erzeugungsdatum im Footer unterscheiden, als identisch betrachtet. Wenn If-None-Match in Kombination mit If-Modified-Since verwendet wird, hat letzteres Vorrang (sofern der Server dies unterstützt). Es gibt im Wesentlichen zwei häufige Anwendungsfälle für die Verwendung von If-None-Match:

• Bei GET- und HEAD-Methoden, um eine zwischengespeicherte Entität zu aktualisieren, der ein ETag zugeordnet ist.
• Für andere Methoden, und insbesondere für PUT, kann If-None-Match mit dem Wert * verwendet werden, um eine Datei zu speichern, die nicht bekannt ist. Dies kann sinnvoll sein, um garantieren zu können, dass vorher kein anderer Upload stattgefunden hat und die Daten des vorherigen Put verloren gehen. Dieses Problem ist eine Variation des Lost Update Problems.

Direktiven zur Verwendung mit If-None-Match

tag_value enthält Entity-Tags, die die angeforderten Ressourcen eindeutig bezeichnen. Sie sind eine Zeichenfolge aus ASCII-Zeichen zwischen doppelten Anführungszeichen (wie “675af34563dc-tr34”). Der Zeichenfolge des Etag Values kann ein W / vorangestellt werden, um anzugeben, dass der schwache Vergleichsalgorithmus verwendet werden soll. Dies ist im Falle von If-None-Match allerdings sinnfrei, da ohnehin nur dieser Algorithmus Verwendung findet.

*(Asterisk)
Der Stern ist ein spezieller Wert, auch Wildcard genannt, der eine beliebige Ressource bezeichnet. Er ist nur nützlich beim Hochladen einer Ressource, normalerweise mit PUT, um zu prüfen, ob bereits eine andere Ressource mit der Identität hochgeladen wurde.

HTTP Statuscode 304 sollte nur als Antwort auf GET- und HEAD-Anforderungen zurückgegeben werden, und alle cache-bezogenen Antwort-Header müssen dabei vorhanden sein. Für alle anderen Arten von Anfragen muss ein Server 412 Precondition Failed antworten. Der RFC füe If-None-Match besagt, dass Server anstelle der Bearbeitung der Anfrage mit 304 Not Modified für GET und HEAD Requests antworten sollten, und dass sie für alle anderen Anfragetypen mit 412 Precondition Failed (Vorbedingung fehlgeschlagen) antworten sollten. Dies gilt allerdings nur dann, wenn der Server tatsächlich eine Version der angeforderten Ressource hat. Wenn keine Entitäten vorhanden sind, sollten er die Anfrage bearbeiten (wahrscheinlich mit einem 404, da eben nichts vorhanden ist).