2. Das Cache-Status HTTP-Antwort-Header-Feld
Das Cache-Status HTTP-Antwort-Header-Feld gibt an, wie Caches diese Antwort und ihre entsprechende Anfrage behandelt haben. Die Syntax dieses Header-Felds entspricht [STRUCTURED-FIELDS].
Sein Wert ist eine List. Jedes Mitglied der List repräsentiert einen Cache, der die Anfrage behandelt hat. Das erste Mitglied repräsentiert den dem Origin-Server am nächsten gelegenen Cache, und das letzte Mitglied repräsentiert den dem Benutzer am nächsten gelegenen Cache (möglicherweise einschließlich des Caches des User-Agents selbst, wenn dieser einen Wert anhängt).
Caches bestimmen, wann es angemessen ist, das Cache-Status-Header-Feld zu einer Antwort hinzuzufügen. Einige fügen es möglicherweise zu allen Antworten hinzu, während andere dies nur tun, wenn sie speziell dafür konfiguriert sind, oder wenn die Anfrage ein Header-Feld enthält, das einen Debugging-Modus aktiviert. Siehe Abschnitt 6 für entsprechende Sicherheitsüberlegungen.
Ein Intermediär SOLLTE NICHT (SHOULD NOT) ein Cache-Status-Mitglied zu Antworten hinzufügen, die er lokal generiert, selbst wenn dieser Intermediär einen Cache enthält, es sei denn, die generierte Antwort basiert auf einer gespeicherten Antwort (z. B. 304 (Not Modified) und 206 (Partial Content) basieren beide auf einer gespeicherten Antwort). Zum Beispiel wird ein Proxy, der eine 400-Antwort aufgrund einer fehlerhaften Anfrage generiert, keinen Cache-Status-Wert hinzufügen, da diese Antwort vom Proxy generiert wurde, nicht vom Origin-Server.
Beim Hinzufügen eines Werts zum Cache-Status-Header-Feld SOLLTEN (SHOULD) Caches den vorhandenen Feldwert erhalten, um das Debugging der gesamten Kette von Caches zu ermöglichen, die die Anfrage verarbeiten.
Jedes List-Mitglied identifiziert den Cache, der es eingefügt hat, und dieser Identifikator MUSS (MUST) ein String oder Token sein. Abhängig vom Deployment kann dies ein Produkt- oder Dienstname sein (z. B. "ExampleCache" oder "Example CDN"), ein Hostname ("cache-3.example.com"), eine IP-Adresse oder eine generierte Zeichenkette.
Jedes Mitglied der Liste kann Parameter haben, die die Behandlung der Anfrage durch diesen Cache beschreiben. Obwohl diese Parameter OPTIONAL sind, werden Caches ermutigt, so viele Informationen wie möglich bereitzustellen.
Diese Spezifikation definiert die folgenden Parameter.
2.1. Der hit-Parameter
Der Wert von "hit" ist ein Boolean, der, wenn wahr, angibt, dass die Anfrage vom Cache erfüllt wurde; das heißt, sie wurde nicht weitergeleitet, und die Antwort wurde aus dem Cache bezogen.
Eine Antwort, die ursprünglich vom Origin erstellt, aber vom Cache modifiziert wurde (z. B. ein 304- oder 206-Statuscode), wird immer noch als Hit betrachtet, solange sie nicht weitergeleitet wurde (z. B. zur Validierung).
Eine Antwort, die im Cache war, aber nicht ohne Weiterleitung verwendet werden konnte (z. B. weil sie veraltet oder partiell war), wird nicht als Hit betrachtet. Beachten Sie, dass eine veraltete Antwort, die ohne Weiterleitung verwendet wird (z. B. weil der Origin-Server nicht verfügbar ist), als Hit betrachtet werden kann.
"hit" und "fwd" schließen sich gegenseitig aus; nur eines von ihnen sollte bei jedem Listenmitglied erscheinen.
2.2. Der fwd-Parameter
"fwd", wenn vorhanden, gibt an, dass die Anfrage in Richtung Origin weitergeleitet wurde; sein Wert ist ein Token, das angibt, warum.
Die folgenden Parameterwerte sind definiert, um zu erklären, warum die Anfrage weitergeleitet wurde, vom spezifischsten zum allgemeinsten:
bypass: Der Cache wurde konfiguriert, diese Anfrage nicht zu verarbeiten.
method: Die Semantik der Anfragemethode erfordert, dass die Anfrage weitergeleitet wird.
uri-miss: Der Cache enthielt keine Antworten, die mit dem Anfrage-URI übereinstimmten.
vary-miss: Der Cache enthielt eine Antwort, die mit dem Anfrage-URI übereinstimmte, konnte aber basierend auf den Header-Feldern dieser Anfrage und gespeicherten Vary-Header-Feldern keine Antwort auswählen.
miss: Der Cache enthielt keine Antworten, die zur Erfüllung dieser Anfrage verwendet werden konnten (zu verwenden, wenn eine Implementierung nicht zwischen uri-miss und vary-miss unterscheiden kann).
request: Der Cache konnte eine frische Antwort für die Anfrage auswählen, aber die Semantik der Anfrage (z. B. Cache-Control-Anfragedirektiven) erlaubte ihre Verwendung nicht.
stale: Der Cache konnte eine Antwort für die Anfrage auswählen, aber sie war veraltet.
partial: Der Cache konnte eine partielle Antwort für die Anfrage auswählen, aber sie enthielt nicht alle angeforderten Bereiche (oder die Anfrage war für die vollständige Antwort).
Der dem Cache am spezifischsten bekannte Grund SOLLTE (SHOULD) verwendet werden, soweit es möglich ist, dies zu implementieren. Siehe auch [HTTP-CACHING], Abschnitt 4.
2.3. Der fwd-status-Parameter
Der Wert von "fwd-status" ist ein Integer, der angibt, welchen Statuscode (siehe [HTTP], Abschnitt 15) der Next-Hop-Server als Antwort auf die weitergeleitete Anfrage zurückgegeben hat. Der fwd-status-Parameter ist nur sinnvoll, wenn fwd vorhanden ist. Wenn fwd-status nicht vorhanden ist, aber der fwd-Parameter vorhanden ist, wird standardmäßig der in der Antwort gesendete Statuscode verwendet.
Dieser Parameter ist nützlich, um Fälle zu unterscheiden, in denen der Next-Hop-Server eine 304 (Not Modified)-Antwort auf eine bedingte Anfrage oder eine 206 (Partial Content)-Antwort aufgrund einer Range-Anfrage sendet.
2.4. Der ttl-Parameter
Der Wert von "ttl" ist ein Integer, der die verbleibende Freshness-Lifetime der Antwort (siehe [HTTP-CACHING], Abschnitt 4.2.1) angibt, wie vom Cache berechnet, als ganzzahlige Anzahl von Sekunden, gemessen so nah wie möglich an dem Zeitpunkt, zu dem der Antwort-Header-Abschnitt vom Cache gesendet wird. Dies beinhaltet Freshness, die vom Cache zum Beispiel durch Heuristiken (siehe [HTTP-CACHING], Abschnitt 4.2.2), lokale Konfiguration oder andere Faktoren zugewiesen wurde. Er kann negativ sein, um Staleness anzuzeigen.
2.5. Der stored-Parameter
Der Wert von "stored" ist ein Boolean, der angibt, ob der Cache die Antwort gespeichert hat (siehe [HTTP-CACHING], Abschnitt 3); ein wahrer Wert gibt an, dass er dies getan hat. Der stored-Parameter ist nur sinnvoll, wenn fwd vorhanden ist.
2.6. Der collapsed-Parameter
Der Wert von "collapsed" ist ein Boolean, der angibt, ob diese Anfrage mit einer oder mehreren anderen Forward-Anfragen zusammengefasst wurde (siehe [HTTP-CACHING], Abschnitt 4). Wenn wahr, wurde die Antwort erfolgreich wiederverwendet; wenn nicht, musste eine neue Anfrage gestellt werden. Wenn nicht vorhanden, wurde die Anfrage nicht mit anderen zusammengefasst. Der collapsed-Parameter ist nur sinnvoll, wenn fwd vorhanden ist.
2.7. Der key-Parameter
Der Wert von "key" ist ein String, der eine Darstellung des für die Antwort verwendeten Cache-Schlüssels übermittelt (siehe [HTTP-CACHING], Abschnitt 2). Beachten Sie, dass dies implementierungsspezifisch sein kann.
2.8. Der detail-Parameter
Der Wert von "detail" ist entweder ein String oder ein Token, der es Implementierungen ermöglicht, zusätzliche Informationen zu übermitteln, die nicht in anderen Parametern erfasst werden, wie implementierungsspezifische Zustände oder andere Caching-bezogene Metriken.
Zum Beispiel:
Cache-Status: ExampleCache; hit; detail=MEMORY
Die Semantik eines detail-Parameters ist immer spezifisch für den Cache, der ihn gesendet hat; selbst wenn ein details-Parameter von einem anderen Cache denselben Wert teilt, bedeutet er möglicherweise nicht dasselbe.
Dieser Parameter ist absichtlich begrenzt. Wenn der Entwickler oder Betreiber einer Implementierung zusätzliche Informationen auf interoperable Weise übermitteln muss, wird er ermutigt, Erweiterungsparameter zu registrieren (siehe Abschnitt 4) oder ein anderes Header-Feld zu definieren.