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
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. SchwacheETag
-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 derETag
-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
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:
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.
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:
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