ETag

Verwendung

Der ETag-Header weist jeder Version einer Ressource eine eindeutige Markierung zu. Ändert sich die Ressource, ändert sich auch der ETag-Wert. Clients speichern den ETag aus einer zwischengespeicherten Antwort und senden den ETag bei nachfolgenden Anfragen im Request-Header If-None-Match zurück. Stimmt der ETag weiterhin überein, liefert der Server 304 Not Modified ohne Body zurück, und der Client verwendet seine zwischengespeicherte Kopie erneut. Stimmt der ETag nicht mehr überein, sendet der Server die vollständige aktualisierte Antwort.

Die ETag-basierte Validierung ist zuverlässiger als die datumsbasierte Validierung mit Last-Modified. Starke Entity-Tags sind undurchsichtige Zeichenketten, die an den exakten Inhalt einer Repräsentation gebunden sind, während Änderungszeitstempel nur eine Granularität von einer Sekunde besitzen und von Uhrenabweichungen betroffen sind. Sind sowohl ETag als auch Last-Modified vorhanden, hat der ETag bei der Neuvalidierung Vorrang, wie es der HTTP-Standard vorschreibt.

ETags ermöglichen außerdem eine Nebenläufigkeitskontrolle bei unsicheren Methoden. Eine PUT-Anfrage mit If-Match stellt sicher, dass die Aktualisierung nur auf die erwartete Version angewendet wird. Hat sich die Ressource seit dem letzten Abruf des ETags durch den Client geändert, liefert der Server 412 Precondition Failed zurück und verhindert so das Problem verlorener Aktualisierungen.

Der ETag-Wert wird vom Server erzeugt. Übliche Strategien sind Inhalts-Hashes, Versionszähler sowie die Kombination aus Dateiänderungszeit und Größe. Der Wert wird in doppelte Anführungszeichen eingeschlossen und optional mit W/ für den schwachen Vergleich vorangestellt.

Hinweis

Google empfiehlt, ETag gegenüber Last-Modified zu verwenden, um die Caching-Präferenz anzugeben, da ETag Probleme mit der Datumsformatierung vermeidet. Sind sowohl ETag als auch Last-Modified vorhanden, verwenden die Crawler von Google den ETag-Wert, wie es der HTTP-Standard vorschreibt. Es wird dennoch empfohlen, beide Header zu setzen, da auch andere Anwendungen wie CMS-Systeme auf diese Header angewiesen sind. Die einzelnen Crawler und Fetcher von Google nutzen Caching je nach den Anforderungen des zugehörigen Produkts. Googlebot unterstützt Caching beim erneuten Crawlen von URLs für Google Search.

Starker ETag

Ein starker ETag garantiert Byte-für-Byte-Identität zwischen zwei Repräsentationen einer Ressource. Zwei Ressourcen mit demselben starken ETag sind auf Byte-Ebene austauschbar. Starke ETags eignen sich für Range-Anfragen und für alle Vergleichsverfahren.

ETag: "abc123"

Schwacher ETag

Ein schwacher ETag, dem W/ vorangestellt ist, zeigt semantische Gleichwertigkeit statt Identität auf Byte-Ebene an. Zwei Ressourcen mit demselben schwachen ETag gelten in ihrer Bedeutung als gleichwertig, sind inhaltlich aber nicht zwingend identisch. Schwache ETags lassen sich leichter erzeugen, da sie geringfügige Unterschiede wie Änderungen an Leerraum oder aktualisierte Zeitstempel im Body tolerieren. Schwache ETags sind für Byte-Range-Anfragen nicht gültig.

ETag: W/"v2.6"

Beispiel

Ein Server liefert einen ETag mit der Antwort zurück. Der Client speichert die Markierung für die spätere Neuvalidierung.

HTTP/1.1 200 OK
ETag: "33a64df5"
Content-Type: text/html
Cache-Control: max-age=3600

Der Client validiert mit If-None-Match neu. Der Server prüft die Markierung gegen die aktuelle Version der Ressource.

GET /page HTTP/1.1
If-None-Match: "33a64df5"

Die Ressource hat sich nicht geändert. Der Server liefert 304 ohne Body zurück, und der Client verwendet seinen Cache erneut.

HTTP/1.1 304 Not Modified
ETag: "33a64df5"
Cache-Control: max-age=3600

Eine PUT-Anfrage, die If-Match für optimistische Nebenläufigkeitskontrolle verwendet. Die Aktualisierung wird nur ausgeführt, wenn die Ressource weiterhin mit dem ETag übereinstimmt, den der Client hält.

PUT /api/document/42 HTTP/1.1
If-Match: "33a64df5"
Content-Type: application/json

Ein schwacher ETag auf einer Ressource, bei der geringfügige Abweichungen im Body (etwa eingebettete Zeitstempel) akzeptabel sind. Das Präfix W/ signalisiert die Semantik des schwachen Vergleichs.

ETag: W/"2024-11-22-v3"

Fehlersuche

ETag-bezogene Probleme zeigen sich als fehlgeschlagene Neuvalidierung, unerwartete vollständige Downloads oder Nebenläufigkeitskonflikte in verteilter Infrastruktur.

ETag-Abweichungen zwischen Servern hinter einem Load-Balancer. Verschiedene Server hinter einem Load-Balancer erzeugen unterschiedliche ETags für dieselbe Ressource, wenn der Erzeugungsalgorithmus Inode-Nummern, Zeitstempel oder serverspezifische Daten einbezieht. Ein Client hat die Antwort von Server A zwischengespeichert, validiert aber gegen Server B neu, der einen abweichenden ETag zurückgibt und damit einen vollständigen Download erzwingt. In Apache enthält der Standard-ETag Inode, Size und Mtime. Entfernen Sie die Inode-Komponente:

FileETag MTime Size

In nginx werden ETags aus der letzten Änderungszeit und der Inhaltslänge abgeleitet, was über Server hinweg, die denselben Dateiinhalt bereitstellen, konsistente Werte erzeugt. Stellen Sie sicher, dass die Zeitstempel der Dateibereitstellung auf allen Knoten übereinstimmen.

IIS gibt ETags im Format “filetime:changenumber” aus, zum Beispiel “04c2528da58dc1:0”. Die erste Hälfte kodiert die zuletzt geänderte Windows-FILETIME der Datei in Hexadezimalform. Das Suffix ChangeNumber verfolgt den Konfigurationszustand von IIS. IIS 7 und neuer geben stets :0 aus: Die Metabase-Eigenschaft, die den Zähler steuerte, wurde mit IIS 6 eingestellt, und keine Einstellung in applicationHost.config oder web.config legt einen Wert ungleich null offen. Knoten hinter einem Load-Balancer geben daher für dieselbe Datei übereinstimmende ETags aus. IIS 6 und früher erhöhen die ChangeNumber bei Änderungen an der Metabase und bei Dienstneustarts, sodass Knoten auseinanderdriften und die knotenübergreifende Neuvalidierung 200 statt 304 zurückliefert. Setzen Sie den Wert auf jedem IIS-6-Knoten mit cscript adsutil.vbs set w3svc/etag_changenumber 0 zurück, oder entfernen Sie das Suffix, sodass der ETag nur noch die FILETIME widerspiegelt. Jedes in der Praxis beobachtete Suffix ungleich null deutet auf einen IIS-6-Ursprungsserver hin.

Schwacher ETag führt zu einer unerwarteten vollständigen Antwort statt 304. Schwache ETags (W/”…”) signalisieren semantische Gleichwertigkeit, unterstützen aber keine Byte-Range-Anfragen. Eine If-None-Match-Anfrage mit einem schwachen ETag funktioniert für die Cache-Neuvalidierung weiterhin. Liefert der Server eine vollständige 200-Antwort statt 304, ist die Vergleichslogik auf Serverseite möglicherweise fehlerhaft. Prüfen Sie, ob der Server schwache ETags mit der schwachen Vergleichsfunktion vergleicht, die das Präfix W/ beim Abgleich ignoriert.

If-None-Match wird vom Client nicht gesendet. Der Browser sendet If-None-Match nur dann, wenn eine zwischengespeicherte Antwort einen ETag-Header enthält. Fehlende ETags in der ursprünglichen Antwort verhindern jede nachfolgende Neuvalidierung. Prüfen Sie die Antwort des Ursprungsservers mit curl -I https://example.re/resource und bestätigen Sie, dass der ETag-Header vorhanden ist. Statische Dateiserver wie nginx und Apache erzeugen ETags automatisch. Anwendungsserver und API-Frameworks erfordern häufig eine explizite ETag-Erzeugung im Code.

CDN entfernt oder verändert ETags. Manche CDNs verändern ETag-Werte während der Verarbeitung. Cloudflare wandelt starke ETags in schwache ETags um, wenn Transformationen wie Brotli-Komprimierung oder Bildoptimierung angewendet werden. AWS CloudFront reicht ETags unverändert vom Ursprungsserver durch. Prüfen Sie den ETag am Ursprungsserver (curl -I https://origin.example.re) und vergleichen Sie ihn mit dem am CDN-Edge (curl -I https://cdn.example.re). Verändert das CDN die ETags, funktioniert die Neuvalidierung über das CDN dennoch, da das CDN die Zuordnung speichert. Eine direkte Neuvalidierung gegen den Ursprungsserver mit einem vom CDN veränderten ETag schlägt fehl.

Apache und nginx erzeugen ETags unterschiedlich. Apache verwendet standardmäßig Inode-Mtime-Size und erzeugt ETags wie “1a2b3c-4d5e-6f7a8b9c”. Nginx verwendet Mtime-Content-Length in Hexadezimalform und erzeugt ETags wie “5f4dcc3b-d8”. Eine Migration zwischen Servern macht alle zwischengespeicherten ETags ungültig und löst für jeden Client vollständige Downloads aus. Planen Sie nach Servermigrationen eine Phase zum Aufwärmen des Caches ein. Erzeugen Sie ETags für API-Antworten aus Inhalts-Hashes (MD5 oder SHA-256), um serverunabhängige Werte zu erhalten.

Hinweis

Die standardmäßige ETag-Erzeugung von Apache bezieht die Inode-Nummer der Datei ein (FileETag INode MTime Size). Inode-Nummern geben Informationen über das Dateisystem des Servers preis und ermöglichen Fingerprinting sowie serverübergreifende Korrelation. OWASP stuft Inode-basierte ETags als Risiko der Informationspreisgabe ein. Entfernen Sie den Inode mit FileETag MTime Size in der Apache-Konfiguration aus der Berechnung.

Hinweis

Für Unterstützung bei SEO und Caching wenden Sie sich an die ehemaligen Google-SEO-Berater Search Brothers.