ETag

Ein ETag (Entity Tag) ist ein HTTP-Antwort-Header – typischerweise ein Hash oder Versionsstempel des Antwort-Bodys –, der es einem Client erlaubt, eine zwischengespeicherte Ressource zu revalidieren, ohne sie erneut herunterzuladen.

Ablauf:

1. Erste Anfrage: Der Server liefert die Ressource mit ETag: "abc123".
2. Der Client speichert die Antwort mit dem ETag zwischen.
3. Nächste Anfrage: Der Client sendet If-None-Match: "abc123".
4. Der Server vergleicht das aktuelle ETag mit dem des Clients. Bei Gleichheit: 304 Not Modified mit leerem Body, der Client nutzt seine zwischengespeicherte Kopie. Bei Unterschied: 200 OK mit neuem Body und neuem ETag.

Zwei ETag-Varianten:

• Starke ETags – ändern sich, wenn sich die Bytes ändern. Standard.
• Schwache ETags – mit W/ präfixiert, können über „semantisch gleichwertige“ Antworten hinweg übereinstimmen (z. B. komprimiert vs. unkomprimiert desselben Inhalts).

ETag ist einer von drei HTTP-Cache-Validierungsmechanismen (neben Last-Modified + If-Modified-Since und Cache-Control max-age). Für moderne statische Websites mit inhalts-gehashten Asset-URLs ist ETag selten nötig – aber es bleibt das Arbeitspferd für dynamische APIs, die clientseitiges Caching wollen.

Durchgerechnetes Beispiel

Ein Browser ruft /api/profile zum ersten Mal ab. Der Server antwortet: HTTP/1.1 200 OK, ETag: "v42-7a8b9c", Body = 4,2 KB JSON. Der Browser speichert beides zwischen. Beim nächsten Seitenaufruf sendet der Browser GET /api/profile mit If-None-Match: "v42-7a8b9c". Der Server berechnet das aktuelle ETag – weiterhin "v42-7a8b9c", weil sich nichts geändert hat – und antwortet mit HTTP/1.1 304 Not Modified und null Byte Body. Der Browser liefert seine zwischengespeicherte Kopie. Eingesparte Bandbreite: 4,2 KB; die Roundtrip-Latenz fällt dennoch an. Vergleichen Sie das mit Cache-Control: max-age=300, das den Roundtrip 5 Minuten lang komplett überspringt – und Sie sehen, warum ETag die zweitbeste Caching-Strategie ist: Es bestätigt die Aktualität, wenn Veralterung vermieden werden muss, spart aber den Netzwerk-Roundtrip nicht ein. Moderne statische Websites bevorzugen fingerabdruck-versehene URLs + ferne max-age in der Zukunft und überspringen ETag ganz.

Wann und warum es zählt

ETag zählt für zwei verschiedene Abläufe: Cache-Revalidierung (Bandbreite sparen, wenn Antworten groß und unveränderlich sind) und optimistische Nebenläufigkeitskontrolle (Verhindern von Lost-Update-Fehlern in REST-APIs). Der beim Caching zu vermeidende Fehler ist, ein schwaches ETag aus einem Zeitstempel mit Sub-Sekunden-Präzision zu erzeugen – jeder Server in einem lastverteilten Cluster berechnet für dieselbe Ressource einen anderen Wert, und Clients invalidieren ständig. Nutzen Sie einen stabilen Inhalts-Hash (SHA-256 des Bodys, oft auf 16 Zeichen gekürzt), damit alle Replikate dasselbe ETag erzeugen. Der bei der Nebenläufigkeit zu vermeidende Fehler ist, If-Match serverseitig nicht zu validieren – viele Entwickler fügen den Header bei Schreibvorgängen hinzu, aber der Server ignoriert ihn und lässt die Race Condition ungelöst. AWS S3, Google Cloud Storage und Stripes API setzen ETag-basierte Nebenläufigkeit alle strikt durch; ihrem Muster zu folgen ist das sicherste Referenzdesign. Quelle: MDN — ETag HTTP header.

Optimistische Nebenläufigkeitskontrolle – ETags zweite Aufgabe: ETag ist auch der Standardmechanismus für „überschreibe meine Daten nicht, wenn sie jemand anderes geändert hat“. Der Client ruft die Ressource per GET ab, erfasst das ETag, nimmt Änderungen vor und sendet sie dann per PUT mit If-Match: "abc123" zurück. Hat sich die serverseitige Ressource seitdem geändert (anderes ETag), gibt der Server 412 Precondition Failed zurück, und der Client weiß, dass er neu laden und erneut zusammenführen muss. AWS S3, Google Cloud Storage und die meisten REST-APIs, die gleichzeitige Bearbeitungen unterstützen, nutzen genau dieses Muster. Der Mechanismus ist älter als das pessimistische Locking von Web-Apps und besser skalierbar, weil kein serverseitiger Sperrzustand nötig ist.

Das Datenschutzproblem mit ETags: Server können eindeutige ETag-Werte pro Nutzer verwenden (im Grunde ein vom Server ausgestelltes, in Cache-Metadaten eingebettetes Cookie), um wiederkehrende Nutzer zu verfolgen, ohne ein echtes Cookie zu setzen – das sogenannte „ETag-Cookie“ oder „Supercookie“. Selbst nachdem ein Nutzer Cookies gelöscht hat, sendet der Browser das ETag bei der nächsten Anfrage weiterhin zurück und identifiziert ihn. Browser partitionieren HTTP-Caches inzwischen pro Top-Level-Site (Chrome 86, Firefox 85), um diesen Angriff zu neutralisieren, doch die Technik bleibt eine bekannte Datenschutz-Fußnote im Design des HTTP-Cachings. Quelle: RFC 9110 §8.8.3 — ETag.