ETag

Baseline Widely available

This feature is well established and works across many devices and browser versions. It’s been available across browsers since July 2015.

Der HTTP-ETag (entity tag) Antwort-Header ist ein Identifikator für eine spezifische Version einer Ressource. Es ermöglicht Caches effizienter zu sein und Bandbreite zu sparen, da ein Webserver keine vollständige Antwort erneut senden muss, wenn sich der Inhalt nicht geändert hat. Zusätzlich helfen ETags dabei, gleichzeitige Aktualisierungen einer Ressource zu verhindern, die sich gegenseitig überschreiben ("mid-air collisions").

Wenn sich die Ressource unter einer bestimmten URL ändert, muss ein neuer Etag-Wert generiert werden. Ein Vergleich der Werte kann bestimmen, ob zwei Darstellungen einer Ressource identisch sind.

Header-Typ Antwort-Header
Verbotener Header-Name Nein

Syntax

http
ETag: W/"<etag_value>"
ETag: "<etag_value>"

Direktiven

W/ Optional

W/ (groß-/kleinschreibungssensitiv) zeigt an, dass ein schwacher Validator verwendet wird. Schwache ETags sind einfach zu erzeugen, aber weit weniger nützlich für Vergleiche. Starke Validatoren sind ideal für Vergleiche, können jedoch sehr schwer effizient zu erzeugen sein. Schwache ETag-Werte von zwei Darstellungen derselben Ressourcen könnten semantisch gleichwertig, aber nicht byte-genau identisch sein. Dies bedeutet, dass schwache ETags das Caching verhindern, wenn Byte-Bereichs-Anfragen verwendet werden, während starke ETags bedeuten, dass Bereichs-Anfragen weiterhin zwischengespeichert werden können.

<etag_value>

Entity-Tag, das die angeforderte Ressource eindeutig repräsentiert. Es ist eine Zeichenfolge von ASCII-Zeichen, die in Anführungszeichen gesetzt ist, wie z. B. "675af34563dc-tr34". Die Methode, mit der ETag-Werte generiert werden, ist nicht festgelegt. Typischerweise ist der ETag-Wert ein Hash des Inhalts, ein Hash des letzten Änderungszeitpunkts oder einfach eine Revisionsnummer. Zum Beispiel kann ein Wiki-Engine einen hexadezimalen Hash des Inhalts des Dokumentationsartikels verwenden.

Beispiele

http
ETag: "33a64df551425fcc55e4d42a148795d9f25f89d4"
ETag: W/"0815"

Vermeidung von mid-air Kollisionen

Mit Hilfe der ETag- und der If-Match-Header können Sie mid-air Bearbeitungskonflikte (Kollisionen) erkennen.

Beim Bearbeiten eines Wikis kann beispielsweise der aktuelle Inhalt des Wikis gehasht und in einem Etag-Header in der Antwort eingefügt werden:

http
ETag: "33a64df551425fcc55e4d42a148795d9f25f89d4"

Beim Speichern von Änderungen an einer Wiki-Seite (Daten posten) enthält die POST-Anfrage den If-Match-Header, der die ETag Werte enthält, um die Aktualität zu überprüfen.

http
If-Match: "33a64df551425fcc55e4d42a148795d9f25f89d4"

Wenn die Hashes nicht übereinstimmen, bedeutet dies, dass das Dokument in der Zwischenzeit bearbeitet wurde und ein 412 Precondition Failed-Fehler geworfen wird.

Zwischenspeichern unveränderter Ressourcen

Eine weitere typische Verwendung des ETag-Headers ist das Zwischenspeichern von Ressourcen, die unverändert sind. Wenn ein Nutzer eine bestimmte URL erneut besucht (die einen ETag-Wert hat), und dieser abgelaufen ist (zu alt, um als verwendbar zu gelten), sendet der Client den Wert seines ETag-Headers im If-None-Match-Header-Feld mit:

http
If-None-Match: "33a64df551425fcc55e4d42a148795d9f25f89d4"

Der Server vergleicht das ETag des Clients (gesendet mit If-None-Match) mit dem ETag seiner aktuellen Version der Ressource, und wenn beide Werte übereinstimmen (d. h. die Ressource hat sich nicht geändert), sendet der Server einen 304 Not Modified-Status zurück, ohne einen Inhalt, was dem Client mitteilt, dass die zwischengespeicherte Version der Antwort weiterhin gut zu verwenden ist (frisch).

Spezifikationen

Specification
HTTP Semantics
# field.etag

Browser-Kompatibilität

BCD tables only load in the browser

Siehe auch