ETag und bedingte Anfragen: Cache prüfen und Änderungen schützen
If-None-Match zur Cache-Validierung und If-Match zum Schutz vor dem Überschreiben einer neueren Darstellung verwenden.
Auf dieser Seite
Die kurze Antwort
Ein ETag identifiziert eine bestimmte Darstellung einer Ressource. Der Client sendet den erhaltenen Wert bei einer Leseanfrage in If-None-Match oder bei einer Änderung in If-Match zurück. Bei GET oder HEAD kann ein passender If-None-Match zu 304 Not Modified führen, sodass der gespeicherte Inhalt wiederverwendet wird. Eine nicht erfüllte If-Match-Bedingung führt zu 412 Precondition Failed. Dann muss die aktuelle Darstellung geladen und mit der Änderung abgeglichen werden. Diese Verfahren lösen unterschiedliche Aufgaben. Ein ETag erteilt keine Zugriffsberechtigung und erlaubt keine gemeinsame Nutzung persönlicher Inhalte.
Die ausgewählte Darstellung identifizieren
Ein ETag gehört zur ausgewählten Darstellung und nicht nur zur URL. Der Server bestimmt seinen Wert; der Client behandelt ihn als undurchsichtigen Bezeichner. Er muss weder ein Dateihash noch ein Zeitstempel oder eine Versionsnummer sein. Wenn Sprache oder andere Anfrageheader die Antwort verändern, ist auch diese Auswahl relevant. Klären Sie, welcher Inhalt gespeichert wurde, welche Anfrage ihn ausgewählt hat und welcher Validator genau mit dieser Antwort geliefert wurde.
Den erhaltenen Wert unverändert speichern
Bewahren Sie den empfangenen Wert vollständig auf, einschließlich Anführungszeichen und eines möglichen Präfixes W/. Das Beispiel verwendet ETag: "version-a". Entfernen Sie die Anführungszeichen nicht und erzeugen Sie keinen Ersatz aus der lokalen Uhrzeit. Auch eine Reihenfolge der Versionen lässt sich nicht zuverlässig aus dem Namen ableiten. Speichern Sie den Validator mit seiner Darstellung, statt einen globalen Wert für sämtliche Ressourcen oder verschiedene Sprachfassungen zu verwenden.
HTTP/1.1 200 OK
ETag: "version-a"
Cache-Control: private, no-cache
Content-Type: application/json
{"title": "Example"}Mit If-None-Match erneut validieren
Muss eine gespeicherte Antwort validiert werden, senden Sie ihr ETag in If-None-Match mit einer GET-Anfrage. Passt die ausgewählte Darstellung weiterhin, kann der Server 304 zurückgeben. Andernfalls liefert er die Darstellung normalerweise erneut, häufig mit 200 und einem neuen Validator. Das spart die wiederholte Übertragung des Inhalts, benötigt aber weiterhin eine Serveranfrage. Eine frische, wiederverwendbare Cache-Antwort darf je nach Richtlinie auch ohne diese erneute Prüfung verwendet werden.
GET /documents/42 HTTP/1.1
Host: example.com
If-None-Match: "version-a"304 ohne Verlust des Inhalts behandeln
Eine 304-Antwort enthält keinen neuen Darstellungsinhalt. Behalten Sie den bereits gespeicherten Inhalt und aktualisieren Sie die betreffenden Cache-Metadaten anhand der erhaltenen Header. Ersetzen Sie das Dokument nicht durch eine leere Zeichenfolge, nur weil die Netzwerkantwort keinen Körper besitzt. Fehlt der passende gespeicherte Inhalt, kann die Anwendung die Ressource aus 304 allein nicht rekonstruieren. Sie muss den Inhalt erneut abrufen und eine konsistente Cache-Zuordnung zwischen Ressource, Darstellung und Validator herstellen.
HTTP/1.1 304 Not Modified
ETag: "version-a"
Cache-Control: private, no-cacheÄnderungen mit If-Match absichern
Senden Sie bei einer Änderung den Validator der tatsächlich bearbeiteten Darstellung in If-Match. Hat eine andere Person die Ressource inzwischen geändert, kann die Bedingung mit 412 scheitern. Laden Sie die aktuelle Fassung und gleichen Sie die Änderungen ab, statt denselben Schreibvorgang blind zu wiederholen. Der Server muss die Vorbedingung zusammen mit seiner Änderung korrekt durchsetzen. Die bloße Anzeige des ETag in einer Benutzeroberfläche verhindert noch keinen Verlust paralleler Änderungen.
PUT /documents/42 HTTP/1.1
Host: example.com
If-Match: "version-a"
Content-Type: application/json
Content-Length: 21
{"title": "Updated!"}Starke und schwache Validatoren unterscheiden
Ein starker Validator beschreibt eine Gleichwertigkeit auf Byte-Ebene. Ein schwacher Wert mit W/ erlaubt eine schwächere Gleichwertigkeit. If-None-Match verwendet einen schwachen Vergleich, der für Cache-Prüfungen geeignet ist. If-Match verwendet dagegen einen starken Vergleich; ein schwacher ETag ist hierfür kein passender starker Validator. Das manuelle Entfernen von W/ erzeugt keine zusätzliche Garantie. Liefert der Dienst nur schwache Werte, muss ein von ihm unterstütztes Änderungsverfahren gewählt werden, statt sämtliche ETags gleich zu behandeln.
Die Cache-Richtlinie berücksichtigen
ETag ersetzt weder Cache-Control noch Vary. Cache-Control steuert die Zwischenspeicherung; Vary nennt Anfrageheader, die die Auswahl der Darstellung beeinflussen. no-cache erlaubt das Speichern, verlangt aber vor der Wiederverwendung eine Validierung. no-store verbietet das Speichern der Antwort. Persönliche Inhalte brauchen zusätzlich eine passende Richtlinie für private oder gemeinsam genutzte Caches. Bestimmen Sie daher zuerst, wer die Antwort speichern darf und wann sie wiederverwendet werden kann, bevor Sie Validatoren ergänzen.
Bedingte Anfragen schrittweise untersuchen
Prüfen Sie zunächst Status, ETag, Cache-Control und Vary der ersten Antwort. Vergleichen Sie anschließend bedingte Leseanfragen für eine unveränderte und eine geänderte Darstellung. Untersuchen Sie bei Schreibkonflikten den gesendeten If-Match-Wert und den empfangenen Status. Protokollieren Sie Bezeichner und Statuswerte statt vertraulicher Inhalte. Die HTTP-Blöcke zeigen illustrative Abläufe und keinen ausgeführten Netzwerktest. So lassen sich fehlende gespeicherte Inhalte, falsche Validatoren und nicht durchgesetzte Serverbedingungen getrennt erkennen.
Was Sie prüfen sollten
- Jeden ETag mit der tatsächlich zugehörigen Darstellung speichern.
- Bei 304 den gespeicherten Inhalt behalten, statt einen leeren Körper einzusetzen.
- 412 als Änderungskonflikt behandeln und vor einem erneuten Versuch neu lesen.
- Cache-Control, Vary und den starken oder schwachen Validator gemeinsam prüfen.
Geltungsbereich
Bedingte Anfragen benötigen korrekte Speicherung beim Client und Durchsetzung beim Server. Sie liefern keine Berechtigungen, Vertraulichkeit oder vollständige Konfliktlösung. Die Beispiele erklären HTTP; eine Ersparnis beim Datenverkehr wurde nicht gemessen.