ETag: Was es ist, Caching-Mechanismus und Header-Konfiguration

Was ist ETag?

ETag (Entity Tag) ist ein HTTP-Antwort-Header, der eine eindeutige Kennung für eine bestimmte Version einer Ressource enthält. Der Server berechnet das ETag basierend auf dem Dateiinhalt, seinen Metadaten oder der Revisionsnummer und sendet es als Antwort auf eine GET-Anfrage an den Client. Der Client speichert diese Kennung und sendet sie bei nachfolgenden Anfragen an dieselbe Ressource im If-None-Match-Header. Wenn sich die Ressource nicht geändert hat, antwortet der Server mit 304 Not Modified, und der Client verwendet seine zwischengespeicherte Kopie.

Das ETag-Format ist in RFC 7232 als Zeichenfolge in Anführungszeichen definiert: "33a64df551425fcc55e4d42a148795d9f25f89d4". Der Wert kann ein SHA-1-Hash des Dateiinhalts, eine inkrementelle Versionsnummer, eine Kombination aus Inode-Nummer-Zeit für statische Dateien oder ein beliebiges vom Server generiertes Token sein. Die einzige Anforderung ist, dass sich der Wert ändern muss, wenn sich die Ressource ändert, und nicht ändern darf, wenn die Ressource gleich bleibt.

ETag gehört zu den Mechanismen bedingter Anfragen (conditional requests) — einer der grundlegenden Optimierungen des HTTP-Protokolls. Im Gegensatz zu unbedingten Anfragen, bei denen der Server immer eine vollständige Antwort zurückgibt, ermöglicht eine bedingte Anfrage dem Client, die Relevanz des Caches zu überprüfen, ohne Daten neu zu laden. Laut HTTP Archive (2025) sind etwa 40% aller HTTP-Antworten 304 Not Modified, dank korrekter ETag- und Last-Modified-Konfiguration.

Wo ETag verwendet wird

ETag wird in REST-APIs verwendet, um das Laden von Datensammlungen zu optimieren — wenn sich die Objektliste nicht geändert hat, erhält der Client 304, ohne das gesamte JSON zu übertragen. Bei statischen Dateien (CSS, JS, Bilder) ermöglicht ETag CDNs und Browsern, die Cache-Frische effizient zu überprüfen. In mobilen Anwendungen ist ETag entscheidend für die Hintergrundsynchronisation: Die App prüft, ob sich die Daten auf dem Server geändert haben, und lädt Updates nur bei Bedarf herunter. Dies spart Traffic und Akku des Geräts.

Wie funktioniert ETag?

Der vollständige ETag-Lebenszyklus besteht aus vier Schritten. Der Server generiert beim ersten Request ein ETag und gibt es im Response-Header zurück. Der Client speichert das ETag zusammen mit der gecachten Ressource. Bei einer wiederholten Anfrage sendet der Client den If-None-Match-Header mit dem gespeicherten ETag-Wert. Der Server vergleicht den empfangenen Wert mit dem aktuellen Ressourcen-ETag: Bei Übereinstimmung gibt er 304 Not Modified mit leerem Body zurück, bei Nichtübereinstimmung 200 OK mit der neuen Ressource und neuem ETag.

// Client-Anfrage mit If-None-Match
GET /api/users HTTP/1.1
Host: example.com
If-None-Match: "33a64df551425fcc55e4d42a148795d9f25f89d4"

// Server-Antwort — Ressource unverändert
HTTP/1.1 304 Not Modified
ETag: "33a64df551425fcc55e4d42a148795d9f25f89d4"

In einer mobilen Anwendung kann dieser Zyklus über einen HTTP-Client mit Caching-Unterstützung implementiert werden. OkHttp zum Beispiel verwaltet ETag automatisch über CacheInterceptor: Es speichert das Response-ETag und fügt bei wiederholten Anfragen If-None-Match hinzu. Beim Empfang von 304 gibt OkHttp die zwischengespeicherten Daten zurück. OkHttp unterstützt ETag ohne zusätzliche Konfiguration — einfach den Cache über OkHttpClient.Builder.cache() aktivieren.

Server-seitige ETag-Generierung

Der Server kann ETags auf verschiedene Weise berechnen: über MD5- oder SHA-Inhalts-Hash, über eine Revisionsnummer aus der Datenbank (z. B. updated_at aus MySQL), über eine Kombination aus Inode + mtime + Größe für statische Dateien (Nginx generiert ETags genau auf diese Weise). Für dynamische APIs ist der Inhalts-Hash am zuverlässigsten: Wenn sich in der JSON-Antwort auch nur ein Feld ändert, ändert sich das ETag. Allerdings belastet die Berechnung eines Hashs bei jeder Anfrage die CPU — für hochbelastete Systeme ist es besser, eine inkrementelle Versionsnummer zu verwenden.

Starke und schwache ETags

RFC 7232 definiert zwei Arten von ETags: starke (strong) und schwache (weak). Ein starkes ETag bedeutet, dass zwei Darstellungen der Ressource byteweise identisch sind — kein einziges Bit unterscheidet sich. Ein schwaches ETag (Präfix W/) garantiert nur semantische Äquivalenz: Der Inhalt kann auf Serialisierungsebene (Leerzeichen, JSON-Feldreihenfolge) abweichen, aber die Daten gelten für den Client als gleich. Schwache ETags werden mit dem Präfix W/ gekennzeichnet, z. B. W/"1a2b3c".

Die Wahl des ETag-Typs hängt von den Anforderungen an die Vergleichsgenauigkeit ab. Für statische Dateien (CSS, JS, Bilder) sind starke ETags vorzuziehen — wenn sich die Datei geändert hat, muss der Client die neue Version erhalten. Für dynamische APIs, bei denen dasselbe JSON mit unterschiedlicher Feldreihenfolge oder Formatierung serialisiert werden kann, bieten schwache ETags mehr Flexibilität: Der Server generiert das ETag basierend auf Geschäftsdaten und nicht auf der Zeichenfolgendarstellung.

Eine Einschränkung schwacher ETags: Sie können nicht mit Bereichsanfragen (Range requests) verwendet werden. Wenn der Client einen Teil einer Datei anfordert, muss der Server ein starkes ETag zurückgeben, um zu garantieren, dass das Fragment der vollständigen Ressource entspricht. Schwache ETags bieten diese Garantie nicht. In anderen Szenarien sind schwache ETags sicher und für APIs empfohlen.

ETag vs Last-Modified

ETag und Last-Modified sind zwei HTTP-Header für bedingte Anfragen, die oft zusammen verwendet werden. Last-Modified gibt das Datum der letzten Änderung einer Ressource an und arbeitet mit dem If-Modified-Since-Header. ETag bietet eine eindeutige Versionskennung und arbeitet mit If-None-Match. Jeder hat seine Vor- und Nachteile, und die Kombination bietet maximale Cache-Effizienz.

Last-Modified ist einfacher zu implementieren — der Server erhält das Datum automatisch aus dem Dateisystem oder aktualisiert das Feld updated_at in der Datenbank. Allerdings hat das Datum eine Sekundengenauigkeit, die für Ressourcen, die sich mehrmals pro Sekunde ändern, unzureichend ist. Darüber hinaus unterscheidet Last-Modified nicht zwischen verschiedenen Zuständen: Wenn eine Datei mit derselben Version überschrieben wird, ändert sich das Datum, aber der Inhalt nicht, sodass der Client identische Daten neu laden würde.

ETag ist genauer: Es ändert sich nur, wenn sich der Inhalt tatsächlich ändert. Wenn der Server eine frühere Version aus einem Backup wiederherstellt, ändert sich das ETag. Wenn eine Datei mit denselben Daten überschrieben wird, bleibt das ETag gleich, und der Client lädt nicht neu. Die kombinierte Verwendung wird von der HTTP-Spezifikation empfohlen: Der Server gibt beide Header zurück, der Client sendet If-None-Match und If-Modified-Since gleichzeitig. Wenn mindestens ein Header eine Änderung anzeigt, gibt der Server eine neue Ressource zurück.

Header-Priorität

Gemäß der Spezifikation hat ETag Priorität vor Last-Modified. Wenn der Server If-None-Match erhält, sollte er nur das ETag überprüfen und If-Modified-Since ignorieren. Dies verhindert Wettlaufsituationen: Wenn sich die Ressource zwischen dem Senden von Last-Modified durch den Client und der Überprüfung auf dem Server geändert hat, ist ETag der aktuellere Indikator. In der Praxis überprüfen Server normalerweise beide Header, aber bei nicht übereinstimmenden Ergebnissen gewinnt ETag.

Server-seitige ETag-Implementierung

Die ETag-Konfiguration hängt vom Servertyp ab. Nginx generiert ETags für statische Dateien automatisch basierend auf Inode, mtime und Größe. Apache verwendet den FileETag-Mechanismus. Für dynamische Anwendungen auf Node.js, PHP, Python, Ruby müssen ETags programmatisch generiert werden — über Antwort-Hash, Datenversionsnummer oder eine Kombination von Anfrageparametern.

func etagMiddleware(next http.Handler) http.Handler {
    return http.HandlerFunc(func(w http.ResponseWriter,
        r *http.Request) {
        // ETag-Generierung basierend auf Daten
        etag := generateETag(r.URL.Path)
        w.Header().Set("ETag", etag)

        // If-None-Match-Prüfung
        if r.Header.Get("If-None-Match") == etag {
            w.WriteHeader(http.StatusNotModified)
            return
        }
        next.ServeHTTP(w, r)
    })
}

Middleware in Go fängt die Anfrage ab, generiert ein ETag für die angeforderte URL (z. B. berechnet es einen Daten-Hash aus Cache oder DB) und setzt den Antwort-Header. Wenn der Client If-None-Match gesendet hat und dieser mit dem aktuellen ETag übereinstimmt, gibt der Server sofort 304 Not Modified zurück, ohne den Haupt-Handler aufzurufen. In der Produktion sollte man das Caching berechneter ETags nach URL und Parametern hinzufügen, um die Serverlast zu reduzieren.

Probleme und Fallstricke

In einer Multi-Server-Konfiguration (Round-Robin oder Anycast) muss das ETag für dieselbe Ressource auf allen Knoten gleich sein. Wenn das ETag basierend auf dem Datei-Inode generiert wird und die Site auf mehreren Servern bereitgestellt ist, unterscheiden sich die Werte. Die Lösung ist die Verwendung eines Inhalts-Hashs oder eines zentralisierten Versionsspeichers (Redis, etcd). Das zweite Problem ist die Gzip-Komprimierung: Nginx ändert das ETag, wenn die Komprimierung aktiviert ist, was zu redundanten 304-Antworten führen kann. Es ist notwendig, gzip_vary on zu konfigurieren, um das ETag mit dem komprimierten Inhalt zu synchronisieren.