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. Er ermöglicht es Caches, effizienter zu arbeiten und Bandbreite zu sparen, da ein Webserver keine vollständige Antwort erneut senden muss, wenn sich der Inhalt nicht geändert hat. Darüber hinaus helfen ETags, gleichzeitige Aktualisierungen einer Ressource zu verhindern, die sich gegenseitig überschreiben ("mid-air collisions").

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

Header-Typ Antwort-Header, Repräsentations-Header
Verbotener Anfrage-Header Nein

Syntax

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

Direktiven

W/ Optional

W/ (Groß-/Kleinschreibung beachten) zeigt an, dass ein schwacher Validator verwendet wird. Schwache ETags sind einfach zu generieren, aber weit weniger nützlich für Vergleiche. Starke Validatoren sind ideal für Vergleiche, aber können sehr schwer effizient zu generieren sein. Schwache ETag-Werte von zwei Darstellungen derselben Ressourcen könnten semantisch identisch sein, aber nicht byteweise identisch. Das bedeutet, dass schwache ETags das Caching verhindern, wenn Bytebereichsanfragen verwendet werden, während starke ETags bedeuten, dass Bereichsanfragen weiterhin zwischengespeichert werden können.

<etag_value>

Entity-Tag, das die angeforderte Ressource eindeutig repräsentiert. Es ist eine Zeichenkette von ASCII-Zeichen, die in Anführungszeichen gesetzt ist, wie "675af34563dc-tr34". Die Methode, nach der ETag-Werte generiert werden, ist nicht spezifiziert. Typischerweise ist der ETag-Wert ein Hash des Inhalts, ein Hash des letzten Änderungszeitstempels oder lediglich eine Revisionsnummer. Beispielsweise kann ein Wiki-Engine einen hexadezimalen Hash des Inhalts des Dokumentationsartikels verwenden.

Beispiele

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

Vermeidung von mid-air collisions

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

Zum Beispiel, wenn ein Wiki bearbeitet wird, kann der aktuelle Wiki-Inhalt gehasht und in einen Etag-Header in der Antwort gesetzt 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 zur Überprüfung der Aktualität enthält.

http
If-Match: "33a64df551425fcc55e4d42a148795d9f25f89d4"

Wenn die Hashes nicht übereinstimmen, bedeutet das, dass das Dokument zwischendurch bearbeitet wurde und ein 412 Precondition Failed-Fehler ausgelöst wird.

Caching von unveränderten Ressourcen

Eine weitere typische Verwendung des ETag-Headers ist das Cachen von unveränderten Ressourcen. Wenn ein Benutzer eine gegebene URL erneut besucht (die ein ETag gesetzt hat), und sie stale (zu alt, um als nutzbar angesehen zu werden) ist, sendet der Client den Wert seines ETag im If-None-Match-Headerfeld mit:

http
If-None-Match: "33a64df551425fcc55e4d42a148795d9f25f89d4"

Der Server vergleicht das ETag des Clients (gesendet mit If-None-Match) mit dem ETag für seine aktuelle Version der Ressource, und wenn beide Werte übereinstimmen (das heißt, die Ressource hat sich nicht geändert), sendet der Server einen 304 Not Modified-Status zurück, ohne einen Inhalt, welcher dem Client sagt, dass die zwischengespeicherte Version der Antwort immer noch gut zu verwenden ist (fresh).

Spezifikationen

Specification
HTTP Semantics
# field.etag

Browser-Kompatibilität

BCD tables only load in the browser

Siehe auch