3. Storing Responses in Caches (Speichern von Antworten in Caches)

Ein Cache darf nicht (MUST NOT) eine Antwort auf eine Anfrage speichern, es sei denn, alle folgenden Bedingungen sind erfüllt:

• Die Anfragemethode wird vom Cache verstanden;

• Der Antwortstatuscode ist endgültig (Final) (siehe Abschnitt 15 von [HTTP]);

• Wenn der Antwortstatuscode 206 oder 304 ist oder eine must-understand Cache-Direktive vorhanden ist (siehe Abschnitt 5.2.2.3): der Cache den Antwortstatuscode versteht;

• Die no-store Cache-Direktive ist nicht in der Antwort vorhanden (siehe Abschnitt 5.2.2.5);

• Wenn der Cache geteilt ist: die private Antwort-Direktive ist nicht vorhanden oder erlaubt gemeinsamen Caches, eine modifizierte Antwort zu speichern (siehe Abschnitt 5.2.2.7);

• Wenn der Cache geteilt ist: das Authorization-Header-Feld (siehe Abschnitt 11.6.2 von [HTTP]) ist nicht in der Anfrage vorhanden oder eine Antwort-Direktive erlaubt gemeinsame Caches explizit (siehe Abschnitt 3.5); und

• Die Antwort enthält mindestens eines der folgenden:

  • Eine public Antwort-Direktive (siehe Abschnitt 5.2.2.9);

  • Eine private Antwort-Direktive, wenn der Cache nicht geteilt ist (siehe Abschnitt 5.2.2.7);

  • Ein Expires-Header-Feld (siehe Abschnitt 5.3);

  • Eine max-age Antwort-Direktive (siehe Abschnitt 5.2.2.1);

  • Wenn der Cache geteilt ist: eine s-maxage Antwort-Direktive (siehe Abschnitt 5.2.2.10);

  • Eine Cache-Erweiterung, die Caching erlaubt (siehe Abschnitt 5.2.3); oder

  • Ein Statuscode, der als heuristisch cachebar (Heuristically Cacheable) definiert ist (siehe Abschnitt 4.2.2).

Beachten Sie, dass Cache-Erweiterungen jede der oben aufgeführten Anforderungen überschreiben können; siehe Abschnitt 5.2.3.

In diesem Kontext "versteht (Understood)" ein Cache eine Anfragemethode oder einen Antwortstatuscode, wenn der Cache ihn erkennt und das gesamte spezifizierte cachebezogene Verhalten implementiert.

Beachten Sie, dass im normalen Betrieb einige Caches keine Antworten speichern, die weder einen Cache-Validator (Cache Validator) noch eine explizite Ablaufzeit haben, da solche Antworten oft nicht wert sind, gespeichert zu werden. Caches sind jedoch nicht daran gehindert, solche Antworten zu speichern.

3.1 Storing Header and Trailer Fields (Speichern von Header- und Trailer-Feldern)

Ein Cache muss (MUST) alle empfangenen Antwort-Header-Felder beim Speichern einer Antwort einschließen -- einschließlich nicht erkannter Felder; dies stellt sicher, dass neue HTTP-Header-Felder erfolgreich bereitgestellt werden können. Es gibt jedoch folgende Ausnahmen:

• Das Connection-Header-Feld und Felder, deren Namen darin aufgeführt sind, müssen (MUST) gemäß Abschnitt 7.6.1 von [HTTP] vor dem Weiterleiten von Nachrichten entfernt werden. Dies kann (MAY) durch Entfernen vor dem Speichern erreicht werden.

• Ebenso erfordern die Semantiken einiger Felder, sie vor dem Weiterleiten von Nachrichten zu entfernen, was (MAY) durch Entfernen vor dem Speichern erreicht werden kann; siehe Abschnitt 7.6.1 von [HTTP] für einige Beispiele.

• Die no-cache (Abschnitt 5.2.2.4) und private (Abschnitt 5.2.2.7) Cache-Direktiven können Parameter haben, die alle Caches bzw. gemeinsame Caches daran hindern, Header-Felder zu speichern.

• Proxy-spezifische Header-Felder, die von einem Cache beim Weiterleiten von Anfragen verwendet werden, dürfen nicht (MUST NOT) gespeichert werden, es sei denn, der Cache bezieht die Identität des Proxys in den Cache-Schlüssel ein. In der Praxis beschränkt sich dies auf Proxy-Authenticate (Abschnitt 11.7.1 von [HTTP]), Proxy-Authentication-Info (Abschnitt 11.7.3 von [HTTP]) und Proxy-Authorization (Abschnitt 11.7.2 von [HTTP]).

Ein Cache kann (MAY) Trailer-Felder (Trailer Fields) getrennt von Header-Feldern speichern oder verwerfen. Caches dürfen nicht (MUST NOT) Trailer-Felder mit Header-Feldern kombinieren.

3.2 Updating Stored Header Fields (Aktualisierung gespeicherter Header-Felder)

In verschiedenen Fällen muss ein Cache die Header-Felder einer gespeicherten Antwort aus einer anderen (typischerweise neueren) Antwort aktualisieren; siehe beispielsweise Abschnitte 3.4, 4.3.4 und 4.3.5.

Dabei muss (MUST) ein Cache jedes Header-Feld aus der bereitstellenden Antwort zur gespeicherten Antwort hinzufügen und dabei vorhandene Feldwerte ersetzen, mit folgenden Ausnahmen:

• Header-Felder, die gemäß Abschnitt 3.1 vom Speichern ausgeschlossen sind,

• Header-Felder, von denen die gespeicherte Antwort des Caches abhängt, wie unten beschrieben,

• Header-Felder, die vom Empfänger automatisch verarbeitet und entfernt werden, wie unten beschrieben, und

• Das Content-Length-Header-Feld.

In einigen Fällen speichern Caches (insbesondere in User-Agents) das Ergebnis der Verarbeitung empfangener Antworten anstelle der Antworten selbst, und das Aktualisieren von Header-Feldern, die diese Verarbeitung beeinflussen, könnte zu inkonsistentem Verhalten und Sicherheitsproblemen führen. In solchen Fällen können (MAY) Caches diese Header-Felder von der Aktualisierung gespeicherter Antworten in Ausnahmen auslassen, sollten (SHOULD) solche Auslassungen jedoch auf Felder beschränken, die zur Gewährleistung der Integrität der gespeicherten Antwort erforderlich sind.

Beispielsweise könnte ein Browser das Content-Encoding (Content Coding) einer Antwort beim Empfang dekodieren, wodurch eine Diskrepanz zwischen seinen gespeicherten Daten und den ursprünglichen Metadaten der Antwort entsteht. Das Aktualisieren dieser gespeicherten Metadaten mit einem anderen Content-Encoding-Header-Feld wäre problematisch. Ebenso könnte ein Browser einen analysierten HTML-Baum anstelle des in der Antwort empfangenen Inhalts speichern; das Aktualisieren des Content-Type-Header-Feldes in dieser Situation wäre nicht machbar, da alle während der Analyse über das Format gemachten Annahmen nun fest eingebaut sind.

Außerdem werden einige Felder von HTTP-Implementierungen automatisch verarbeitet und entfernt, wie das Content-Range-Header-Feld. Selbst wenn tatsächlich keine Verarbeitung stattfindet, können (MAY) Implementierungen diese Header-Felder automatisch von Aktualisierungen auslassen.

Beachten Sie, dass das Content-*-Präfix nicht bedeutet, dass ein Header-Feld von Aktualisierungen ausgelassen wird; es ist eine Konvention für MIME-Header-Felder, nicht für HTTP.

3.3 Storing Incomplete Responses (Speichern unvollständiger Antworten)

Ein Cache kann (MAY) eine unvollständige Antwort (siehe Abschnitt 6.1 von [HTTP]) speichern, wenn die Anfragemethode GET ist, der Antwortstatuscode 200 (OK) ist und der gesamte Antwort-Header-Abschnitt empfangen wurde, vorausgesetzt, die gespeicherte Antwort wird als unvollständig aufgezeichnet. Ebenso kann (MAY) eine 206 (Partial Content) Antwort als unvollständige 200 (OK) Antwort gespeichert werden. Ein Cache darf jedoch nicht (MUST NOT) unvollständige oder partielle Inhaltsantworten speichern, wenn der Cache die Range- und Content-Range-Header-Felder nicht unterstützt oder die in diesen Feldern verwendeten Bereichseinheiten (Range Units) nicht versteht.

Ein Cache kann (MAY) eine gespeicherte unvollständige Antwort vervollständigen, indem er nachfolgende Bereichsanfragen stellt (siehe Abschnitt 14.2 von [HTTP]) und erfolgreiche Antworten mit der gespeicherten Antwort kombiniert, wie in Abschnitt 3.4 definiert. Ein Cache darf nicht (MUST NOT) eine unvollständige Antwort verwenden, um eine Anfrage zu beantworten, es sei denn, die Antwort wurde vervollständigt oder die Anfrage ist partiell und gibt einen Bereich an, der vollständig innerhalb der unvollständigen Antwort liegt. Ein Cache darf nicht (MUST NOT) eine partielle Antwort an einen Client senden, es sei denn, sie ist explizit mit dem 206 (Partial Content) Statuscode gekennzeichnet.

3.4 Combining Partial Content (Kombination partieller Inhalte)

Eine Antwort kann nur eine partielle Darstellung übertragen, wenn die Verbindung vorzeitig geschlossen wird oder wenn die Anfrage einen oder mehrere Range-Spezifizierer verwendet (siehe Abschnitt 14.2 von [HTTP]). Nach mehreren solchen Übertragungen kann ein Cache mehrere Bereiche derselben Darstellung empfangen haben. Ein Cache kann (MAY) diese Bereiche zu einer einzelnen gespeicherten Antwort kombinieren, wenn sie alle denselben starken Validator (Strong Validator) teilen und der Cache den Client-Anforderungen in Abschnitt 15.3.7.3 von [HTTP] entspricht, und diese Antwort wiederverwenden, um nachfolgende Anfragen zu erfüllen.

Beim Kombinieren einer neuen Antwort mit einer oder mehreren gespeicherten Antworten muss (MUST) ein Cache die Header-Felder der gespeicherten Antwort unter Verwendung der in der neuen Antwort bereitgestellten Header-Felder aktualisieren, gemäß Abschnitt 3.2.

3.5 Storing Responses to Authenticated Requests (Speichern von Antworten auf authentifizierte Anfragen)

Ein gemeinsamer Cache darf nicht (MUST NOT) eine gecachte Antwort auf eine Anfrage mit einem Authorization-Header-Feld (siehe Abschnitt 11.6.2 von [HTTP]) verwenden, um eine nachfolgende Anfrage zu erfüllen, es sei denn, die Antwort enthält ein Cache-Control-Feld mit einer Antwort-Direktive (Abschnitt 5.2.2), die es erlaubt, von einem gemeinsamen Cache gespeichert zu werden, und der Cache entspricht den Anforderungen dieser Direktive für diese Antwort.

In dieser Spezifikation haben die folgenden Antwort-Direktiven diese Wirkung: must-revalidate (Abschnitt 5.2.2.2), public (Abschnitt 5.2.2.9) und s-maxage (Abschnitt 5.2.2.10).