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 Bezeichner für eine bestimmte Version einer Ressource. Er ermöglicht es Caches effizienter zu arbeiten und Bandbreite zu sparen, da ein Webserver nicht die gesamte 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 könnten ("mid-air collisions").

Wenn sich die Ressource an einer bestimmten 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 Header-Name 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, können jedoch sehr schwer effizient zu generieren sein. Schwache ETag-Werte von zwei Darstellungen derselben Ressourcen können semantisch gleichwertig sein, aber nicht byte-genau identisch. Das bedeutet, schwache ETags verhindern das Caching bei Byte-Range-Anfragen, aber starke ETags ermöglichen, dass Range-Anfragen dennoch zwischengespeichert werden können.

<etag_value>

Entity-Tag, das die angeforderte Ressource eindeutig repräsentiert. Es ist eine Zeichenkette von ASCII-Zeichen zwischen Anführungszeichen, wie "675af34563dc-tr34". Die Methode, mit der ETag-Werte generiert werden, ist nicht spezifiziert. Typischerweise ist der ETag-Wert ein Hash des Inhalts, ein Hash des letzten Änderungszeitstempels oder einfach eine Revisionsnummer. Beispielsweise kann eine Wiki-Engine einen hexadezimalen Hash des Inhalts eines 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 collisions" (Konflikte) erkennen.

Wenn beispielsweise ein Wiki bearbeitet wird, kann der aktuelle Wiki-Inhalt gehasht und in einem Etag-Header in der Antwort platziert werden:

http
ETag: "33a64df551425fcc55e4d42a148795d9f25f89d4"

Beim Speichern von Änderungen an einer Wiki-Seite (Posten von Daten) enthält der POST-Antrag den If-Match-Header, der die ETag-Werte zur Frischeüberprüfung enthält.

http
If-Match: "33a64df551425fcc55e4d42a148795d9f25f89d4"

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

Caching unveränderter Ressourcen

Ein weiteres typisches Anwendungsbeispiel des ETag-Headers ist das Caching von Ressourcen, die unverändert sind. Wenn ein Benutzer eine gegebene URL erneut besucht (die ein ETag gesetzt hat) und diese veraltet ist (zu alt, um verwendbar zu sein), sendet der Client den Wert seines ETag im If-None-Match-Headerfeld mit:

http
If-None-Match: "33a64df551425fcc55e4d42a148795d9f25f89d4"

Der Server vergleicht den ETag des Clients (gesendet mit If-None-Match) mit dem ETag seiner aktuellen Version der Ressource, und wenn beide Werte übereinstimmen (das bedeutet, die Ressource hat sich nicht geändert), sendet der Server einen 304 Not Modified-Status zurück, ohne einen Body, was dem Client mitteilt, dass die zwischengespeicherte Version der Antwort nach wie vor verwendbar (frisch) ist.

Spezifikationen

Specification
HTTP Semantics
# field.etag

Browser-Kompatibilität

BCD tables only load in the browser

Siehe auch