HTTP-Caching

Veröffentlicht am:

Die wichtigsten Befehle zum Merken

  • curl --etag-save DATEI — einen Antwortvalidator speichern.
  • curl --etag-compare DATEI — damit eine bedingte Anfrage senden.

Befehle und Optionen

Befehl oder Option Bedeutung
mktemp / rm "$etag_file" Eine eindeutige temporäre Datei erstellen / nur diese entfernen.
-i / --max-time 10 Antwortheader zeigen / einen Transfer auf zehn Sekunden begrenzen.
--etag-save / --etag-compare ETag speichern / soweit vorhanden als If-None-Match senden.

etag_file=$(…) speichert die Befehlsausgabe. Anführungszeichen übergeben den Pfad als ein Argument. Curl verwaltet hier keinen vollständigen Antwortcache.

Die entscheidenden Konzepte

1. Ein Cache verwendet frühere Antworten erneut

Ein HTTP-Cache speichert Antworten, damit spätere Anfragen dieselbe Repräsentation nicht erneut herunterladen müssen. Ein Browsercache gehört einem Benutzer; ein geteilter Cache kann mehrere bedienen.

Wiederverwendung spart Übertragung und Ursprungsarbeit, muss aber Regeln und Anfragekontext erhalten. Wird eine personalisierte Antwort als öffentlich gespeichert, können Daten eines Benutzers bei einem anderen landen.

2. Frische erlaubt Wiederverwendung ohne Validierung

Cache-Control: max-age beschreibt eine Frischelebensdauer in Sekunden. Alter und Zeitwerte bestimmen die verbleibende Frische. Weiterleitung durch einen anderen Cache beginnt nicht automatisch eine neue volle Lebensdauer.

no-cache erlaubt Speichern, verlangt aber Validierung vor Wiederverwendung. no-store untersagt Speichern. private beschränkt Speicherung in geteilten Caches. Die Direktiven lösen unterschiedliche Aufgaben.

3. Validatoren fragen nach Änderungen

Ein ETag kennzeichnet nach Serverregeln eine Repräsentationsversion. Ein Client kann ihn in If-None-Match senden. Passt die Repräsentation bei GET weiterhin, kann der Server 304 Not Modified ohne Repräsentationsbody antworten.

Der Client verwendet dann seinen gespeicherten Body und aktualisiert passende Metadaten. 304 ist kein leeres Ersatzdokument. Ein ETag ist auch nicht zwingend ein kryptografischer Hash oder Echtheitsnachweis.

4. Der Cache-Schlüssel muss Varianten unterscheiden

Eine URL allein liefert nicht zwingend für jede Anfrage dieselbe Repräsentation. Vary nennt Anfrageheader, die Varianten unterscheiden, etwa Felder der Inhaltsaushandlung.

Autorisierung, Cookies, Methoden und Richtlinien beeinflussen ebenfalls sichere Wiederverwendung. Eine Cache-Antwort beweist nicht, dass jeder Benutzer dieselbe Antwort erhält. Korrektes Caching braucht passende Lebensdauern und getrennte Varianten.

Ein kleines Beispiel

Optional: Führe die Befehle in einem Bash-Terminal aus und fahre nur nach erfolgreichem mktemp fort. Die Domain muss keinen ETag liefern.

etag_file=$(mktemp)
curl -i --max-time 10 --etag-save "$etag_file" https://example.com/
curl -i --max-time 10 --etag-compare "$etag_file" https://example.com/
rm "$etag_file"

Lies vorhandene Cache-Control-, ETag-, Age- und Vary-Header. Der erste Transfer speichert nur den Validator, keinen wiederverwendbaren Body. Der zweite sendet eine bedingte Anfrage, falls ein Validator gespeichert wurde.

304 bedeutet, dass der Server die Bedingung bestätigt hat. 200 kann Änderungen, fehlenden ETag oder eine normale Inhaltsantwort bedeuten. Erwarte keinen erfundenen Messwert. Curl zeigt nach 304 keinen alten Body, weil das Beispiel keinen dafür gespeichert hat.

Die letzte Zeile entfernt den Validator. Website-Caches und Serverkonfiguration bleiben unverändert.

Merke dir: Frische erlaubt Wiederverwendung, Validierung prüft ältere Repräsentationen, der Schlüssel trennt Varianten.