Die Rückfrage, die nichts spart: ETag, Last-Modified und das ausbleibende 304

Eine gespeicherte Antwort gilt als frisch, solange die Cache-Regeln eine Wiederverwendung ohne Rückfrage beim Server erlauben. Das kann einen Netzabruf sparen. Wird eine Prüfung nötig, kann ein Validator die erneute Übertragung des Inhalts vermeiden: Ein passender bedingter GET-Abruf erhält 304 Not Modified. Anfrage und Verarbeitung kosten weiterhin Zeit. Ein Cache ohne Validatoren bleibt deshalb nützlich, solange eine gespeicherte Antwort wiederverwendbar ist.

Ein historischer Lauf vom 5. September 2026 untersuchte zwanzig Ausgangsadressen. Elf aufgezeichnete Antworten enthielten weder ETag noch Last-Modified. Das beschreibt die damaligen Antworten, keine grundsätzliche Unfähigkeit von elf ganzen Websites zur bedingten Abfrage.

Zwei Validatoren mit unterschiedlichen Zusagen

Last-Modified beschreibt den letzten Änderungszeitpunkt mit sekundengenauer Auflösung. Das zugehörige Anfragefeld heißt If-Modified-Since. Mehrere Änderungen innerhalb einer Sekunde können diese Auflösung überschreiten.

ETag ist eine Versionskennung, deren Inhalt der Client nicht deuten muss. Die Kennung wird in If-None-Match zurückgesendet. Die Zuverlässigkeit hängt von der Erzeugung ab: Ein Inhalts-Hash oder ein anderes geeignetes Versionsverfahren kann Änderungen unterscheiden, die ein Zeitstempel nicht erfasst. Ein ETag ist nicht automatisch ein Inhalts-Hash.

Ein starker ETag kennzeichnet identische Darstellungsdaten. Ein schwacher ETag wie W/"abc" erlaubt gleichwertige Daten ohne Bytegleichheit. Dynamisch erzeugte Seiten benötigen nicht automatisch schwache Tags; maßgeblich ist die tatsächlich eingehaltene Vergleichszusage.

Was die gespeicherte Stichprobe enthält

Die archivierten Ergebnisse enthalten fünf ETags, darunter drei schwache, sowie fünf Last-Modified-Felder. Eine Antwort enthält beides, elf enthalten keines davon. Sechs Antworten nennen no-store; nur vier dieser sechs haben keine Validatoren. Sieben Antworten besitzen somit keine Validatoren, ohne zugleich no-store vorzugeben. Daraus folgt noch keine Speicherbarkeit: Status, weitere Direktiven und Cache-Art sind ebenfalls relevant.

Zwei Ergebnisse tragen einen HTTP-Fehlerhinweis, darunter eine der beiden Antworten ohne Cache-Control. Die gespeicherte Zusammenfassung enthält deren genaue Statuscodes nicht. Die Stichprobe umfasst deshalb nicht zwanzig nachgewiesen erfolgreiche Startseitenantworten und liefert keinen repräsentativen Marktanteil.

Der Analyzer vergab sechs Speicherverbote, vier unmittelbare Neuabrufe, drei ständige Revalidierungen, vier Fälle mit Frische und anschließender Revalidierung, einen mit Frische und Neuabruf sowie zwei heuristische Klassen. Das sind Einordnungen anhand von Headern, keine beobachteten Browserverläufe. Beispielsweise waren 54 Sekunden ein max-age-Wert, kein Nachweis einer exakt so langen Speicherung in jedem Browser.

Frische und Validierung sind verschiedene Fragen

no-store verbietet die Speicherung im HTTP-Cache; no-cache verlangt eine erfolgreiche Validierung vor Wiederverwendung. max-age=0 macht eine Antwort sofort veraltet. Private und gemeinsame Caches können unterschiedlichen Regeln folgen, insbesondere bei private oder s-maxage.

Ohne ausdrücklich festgelegte Frist darf ein Cache unter passenden Voraussetzungen selbst schätzen, wie lange die Antwort wiederverwendbar ist. Das heißt heuristisches Caching. Zehn Prozent des Abstands zu Last-Modified sind ein Beispielverfahren, keine vorgeschriebene Lebensdauer. Keine der beiden untersuchten Antworten ohne Cache-Control enthielt Last-Modified. Der Datensatz belegt diese Berechnung dort also nicht. Auch das Verhalten der Zurück-/Vorwärts-Funktion folgt nicht aus diesem HTTP-Test.

Kompression und die ETag-Falle

Apache dokumentiert, dass das standardmäßige AddSuffix-Verhalten der Kompressionsmodule 304-Antworten für komprimierte Inhalte verhindern kann. Eine bedingte Prüfung derselben Variante ist daher sinnvoll. Ein wiederholtes 200 genügt aber nicht als Fehlerbeweis: Die ausgewählte Darstellung kann tatsächlich verändert sein.

DeflateAlterETag NoChange und BrotliAlterETag NoChange erhalten den ursprünglichen Tag, doch Apache beschreibt ausdrücklich die daraus entstehende Einschränkung der Varianteneindeutigkeit. Ein gemeinsamer starker Tag für komprimierte und unkomprimierte Bytes wird durch Vary: Accept-Encoding nicht korrekt. Vary steuert die Cache-Auswahl; starke Validatoren betreffen die Identität der Darstellungsdaten.

Eine geeignete Lösung hängt von Server und Cache-Verarbeitung ab: korrekte getrennte starke Tags, richtig behandelte schwache Tags für gleichwertige Darstellungen oder das Entfernen eines ungeeigneten ETags mit entsprechendem Verlust dieser Prüfmöglichkeit. Range-Anfragen und bedingte Antworten benötigen Gegenproben. Ein einzelnes 200 rechtfertigt keine universelle Produktionsdirektive. Die frühere pauschale Unbedenklichkeitszusage für NoChange wurde deshalb entfernt.

Ein reproduzierbarer bedingter GET-Abruf

Das Bash-Beispiel benötigt curl ab Version 7.68.0. URL und Kodierungspräferenz bleiben gleich, der empfangene ETag wird unverändert gespeichert. Bei einer ersten Antwort ungleich 200 oder ohne Tag endet das Skript. Die URL ist ein Platzhalter; bei Weiterleitungen ist die gewünschte Zieladresse gesondert auszuwählen und zu prüfen.

#!/usr/bin/env bash
set -euo pipefail
url='https://example.com/style.css'
tag_file=$(mktemp)
trap 'rm -f "$tag_file"' EXIT
status=$(curl --silent --show-error --max-time 20 \
  -H 'Accept-Encoding: gzip' --etag-save "$tag_file" \
  --output /dev/null --write-out '%{http_code}' "$url")
[[ "$status" == 200 ]] || { printf 'Initial HTTP status: %s\n' "$status" >&2; exit 1; }
[[ -s "$tag_file" ]] || { printf 'No ETag received\n' >&2; exit 1; }
curl --silent --show-error --max-time 20 \
  -H 'Accept-Encoding: gzip' --etag-compare "$tag_file" \
  --output /dev/null --dump-header - --write-out '\nHTTP %{http_code}\n' "$url"

Die ausgegebenen Antwort-Header zeigen den zweiten ETag und die Kodierung. Eine 304-Antwort enthält keinen Antwortinhalt; bei 200 sind Variante, Änderung und Serververhalten zu untersuchen. Netzfehler und andere Statuscodes bleiben eigene Ergebnisse. Gleiches Accept-Encoding kontrolliert eine Eingabe, beweist aber weder gleiche gewählte Kompression noch gleichen Inhalt.

Der Cache-Control- und Revalidierungs-Analyzer sendet empfangenen ETag und Zeitpunkt in getrennten Tests. Ein kombinierter Vorrangtest oder vollständiger Browsercache ist damit nicht abgebildet. Der Bytezähler misst dekodierten Inhalt bis 256 KiB, keinen vollständigen komprimierten Netzverkehr. Auch ein geänderter ETag mit 200 erhält eine Warnung, obwohl dieses Verhalten korrekt sein kann. Heuristische Dauer und Klassen benötigen daher eine fachliche Einordnung.