HTTP ETag
ETag (für entity tag, etwa ‚Entitäts-Kennzeichen‘) ist ein im HTTP 1.1 eingeführtes Header-Feld. Es dient zur Bestimmung von Änderungen an der angeforderten Ressource und wird hauptsächlich zum Caching, also der Vermeidung redundanter Datenübertragungen, verwendet.
Spezifikation
[Bearbeiten | Quelltext bearbeiten]![](http://178.128.105.246/cars-http-upload.wikimedia.org/wikipedia/commons/6/66/Etag_header_beispiele.png)
Der ETag-Wert ist eine beliebige von Anführungszeichen umschlossene Zeichenkette, die zusätzlich durch das Präfix „W/
“ als schwaches ETag gekennzeichnet werden kann. Die spezifizierende BNF dazu:
ETag = "ETag" ":" entity-tag entity-tag = [ weak ] opaque-tag weak = "W/" opaque-tag = quoted-string
- Starker ETag
- Ein starker ETag darf nur dann von mehreren Entitäten einer Ressource geführt werden, falls diese absolut identisch (Bit für Bit) sind.
- Schwacher ETag
- Ein schwacher ETag (durch „
W/
“-Präfix gekennzeichnet) darf von mehreren Entitäten einer Ressource geführt werden, falls diese zueinander äquivalent sind, sich also semantisch nicht signifikant unterscheiden.
Häufig basiert die Generierung des ETag-Werts auf dem Hash des Inhalts der Ressource oder dem Zeitpunkt der letzten Änderung.
Ablauf
[Bearbeiten | Quelltext bearbeiten]Bei der ersten Anfrage einer Ressource sendet der Server einen für diese Ressource spezifischen ETag-Wert im ETag
-Header-Feld, der vom Client zusammen mit der Ressource lokal gespeichert wird. (Abb. 1)
Bei einer erneuten Anfrage derselben Ressource sendet der Client in dem Header-Feld If-None-Match
den zuvor gespeicherten ETag-Wert mit. (Abb. 2)
Auf der Server-Seite wird nun der gesendete ETag-Wert mit dem aktuellen verglichen und bei Übereinstimmung mit dem Statuscode 304 beantwortet. (Abb. 3) Die Daten der Ressource werden in diesem Fall nicht mitgeschickt und der Client verwendet die lokal gespeicherten Daten.
Probleme
[Bearbeiten | Quelltext bearbeiten]Bei ungeschickter Implementierung kann sich der ETag negativ auswirken: Wenn der ETag zum Beispiel aus der Inode des auszuliefernden Dokuments generiert wird, ist dieser Wert nur auf diesem System gültig. Wird das Dokument nun von mehreren Servern ausgeliefert (z. B. zwecks Server-Lastverteilung), so kann eine erneute Anfrage des Clients von einem anderen Server mit einem anderen ETag-Wert verarbeitet werden, was wiederum die Übertragung derselben Datei trotz ETags zur Folge hat. Aus diesem Grund wird empfohlen, die Inode bei der Generierung des ETag-Werts nicht zu verwenden.
Zur Generierung des ETags sollte beispielsweise ein Hashwert über den Inhalt der Datei oder eine eindeutige Versionsnummer der Datei verwendet werden.
Zudem können Anwender mittels ETag identifiziert werden, wenn ein Webserver client-individuelle ETags generiert.[1][2]
Weblinks
[Bearbeiten | Quelltext bearbeiten]- RFC – Hypertext Transfer Protocol – HTTP/1.1. Juni 1999, Abschnitt 14.19: ETag. (englisch).
- FileETag-Direktive. Apache-HTTP-Server-Dokumentation.
- etag.use-inode. lighttpd-Server-Dokumentation.
- ETag-Checker - Ein kostenloser Checker der die korrekte Konfiguration des ETags kontrollieren kann.
Einzelnachweise
[Bearbeiten | Quelltext bearbeiten]- ↑ Nicht löschbarer Cookie erlaubt Browser-Identifikation. teltarif.de; abgerufen am 26. November 2013
- ↑ User-Tracking im Web: Forscher warnt vor heimtückischer Tracking-Technik. heise.de; abgerufen am 29. November 2013