5.2.2 Response Cache-Control Directives
Dieser Abschnitt definiert Cache-Direktiven, die ein Ursprungsserver oder Vermittler in einer HTTP-Antwort verwenden kann.
5.2.2.1. must-revalidate
Die "must-revalidate"-Antwortdirektive gibt an, dass ein Cache, sobald die Antwort veraltet ist, die Antwort NICHT (MUST NOT) verwenden darf, um nachfolgende Anfragen ohne erfolgreiche Validierung auf dem Ursprungsserver zu erfüllen.
Die must-revalidate-Direktive ist notwendig, um den zuverlässigen Betrieb für bestimmte Protokollfunktionen zu unterstützen. Unter allen Umständen MUSS (MUST) ein Cache der must-revalidate-Direktive gehorchen; insbesondere, wenn ein Cache aus irgendeinem Grund den Ursprungsserver nicht erreichen kann, MUSS (MUST) er eine 504 (Gateway Timeout)-Antwort generieren.
Die must-revalidate-Direktive sollte (ought to) von Servern verwendet werden, wenn und nur wenn das Versagen der Validierung einer Anfrage zu einem inkorrekten Betrieb führen könnte, wie z. B. eine stillschweigend nicht ausgeführte Finanztransaktion.
5.2.2.2. no-cache
Argument: #field-name (optional)
Die "no-cache"-Antwortdirektive gibt an, dass die Antwort NICHT (MUST NOT) verwendet werden darf, um eine nachfolgende Anfrage ohne erfolgreiche Validierung auf dem Ursprungsserver zu erfüllen. Dies ermöglicht es einem Ursprungsserver, zu verhindern, dass ein Cache die Antwort verwendet, um eine Anfrage zu erfüllen, ohne ihn zu kontaktieren, selbst durch Caches, die so konfiguriert wurden, dass sie veraltete Antworten senden.
Wenn die no-cache-Antwortdirektive einen oder mehrere Feldnamen angibt, dann DARF (MAY) ein Cache die Antwort verwenden, um eine nachfolgende Anfrage zu erfüllen, vorbehaltlich anderer Einschränkungen beim Caching. Jedoch DÜRFEN (MUST NOT) alle angegebenen Feldnamen NICHT in der Antwort auf eine nachfolgende Anfrage gesendet werden, ohne erfolgreiche Revalidierung mit dem Ursprungsserver. Dies ermöglicht es einem Ursprungsserver, die Wiederverwendung bestimmter Header-Felder in einer Antwort zu verhindern, während das Caching des Rests der Antwort weiterhin erlaubt wird.
Hinweis: Die meisten HTTP/1.0-Caches werden diese Direktive nicht erkennen oder befolgen. Außerdem werden no-cache-Antwortdirektiven mit Feldnamen von Implementierungen oft so behandelt, als ob eine uneingeschränkte no-cache-Direktive empfangen wurde; d. h., die spezielle Behandlung für die qualifizierte Form ist nicht weit verbreitet implementiert.
5.2.2.3. no-store
Die "no-store"-Antwortdirektive gibt an, dass ein Cache KEINEN Teil (MUST NOT) der unmittelbaren Anfrage oder Antwort speichern darf. Diese Direktive gilt sowohl für private als auch für gemeinsam genutzte Caches. "DARF NICHT speichern" bedeutet in diesem Kontext, dass der Cache die Informationen NICHT absichtlich (MUST NOT) in nicht flüchtigem Speicher speichern darf und sich nach bestem Bemühen (MUST) darum bemühen muss, die Informationen so schnell wie möglich nach der Weiterleitung aus dem flüchtigen Speicher zu entfernen.
Diese Direktive ist KEIN zuverlässiger oder ausreichender Mechanismus zur Gewährleistung der Privatsphäre. Insbesondere können bösartige oder kompromittierte Caches diese Direktive möglicherweise nicht erkennen oder befolgen, und Kommunikationsnetzwerke können anfällig für Abhören sein.
5.2.2.4. no-transform
Die "no-transform"-Antwortdirektive gibt an, dass ein Vermittler (unabhängig davon, ob er einen Cache implementiert oder nicht) die Payload NICHT transformieren DARF (MUST NOT), wie in Abschnitt 5.7.2 von [RFC7230] definiert.
5.2.2.5. public
Die "public"-Antwortdirektive gibt an, dass jeder Cache die Antwort speichern DARF (MAY), selbst wenn die Antwort normalerweise nicht cachefähig oder nur innerhalb eines privaten Caches cachefähig wäre. (Siehe auch Abschnitt 3.2, der die Auswirkung des Authorization-Header-Felds auf die Cachefähigkeit diskutiert.)
5.2.2.6. private
Argument: #field-name (optional)
Die "private"-Antwortdirektive gibt an, dass die Antwort für einen einzelnen Benutzer bestimmt ist und NICHT (MUST NOT) von einem gemeinsam genutzten Cache gespeichert werden darf. Ein privater Cache DARF (MAY) die Antwort speichern und für spätere Anfragen wiederverwenden, selbst wenn die Antwort normalerweise nicht cachefähig wäre.
Wenn die private-Antwortdirektive einen oder mehrere Feldnamen angibt, ist diese Anforderung auf die Feldwerte beschränkt, die mit den aufgelisteten Antwort-Header-Feldern verbunden sind. Das heißt, ein gemeinsam genutzter Cache DARF NICHT (MUST NOT) die angegebenen Feldnamen speichern, während er den Rest der Antwortnachricht speichern DARF (MAY).
Hinweis: Diese Direktive ist kein zuverlässiger oder ausreichender Mechanismus zur Gewährleistung der Privatsphäre. Insbesondere können bösartige oder kompromittierte Caches diese Direktive möglicherweise nicht erkennen oder befolgen, und Kommunikationsnetzwerke können anfällig für Abhören sein.
5.2.2.7. proxy-revalidate
Die "proxy-revalidate"-Antwortdirektive hat dieselbe Bedeutung wie die must-revalidate-Antwortdirektive, außer dass sie nicht für private Caches gilt.
5.2.2.8. max-age
Argument: delta-seconds
Die "max-age"-Antwortdirektive gibt an, dass die Antwort als veraltet betrachtet werden soll, nachdem ihr Alter größer ist als die angegebene Anzahl von Sekunden.
Diese Direktive verwendet die Token-Form der Argumentsyntax: z. B. 'max-age=5' nicht 'max-age="5"'. Ein Absender SOLLTE NICHT (SHOULD NOT) die Form mit Anführungszeichen generieren.
5.2.2.9. s-maxage
Argument: delta-seconds
Die "s-maxage"-Antwortdirektive gibt an, dass in gemeinsam genutzten Caches das durch diese Direktive angegebene maximale Alter das durch die max-age-Direktive oder das Expires-Header-Feld angegebene maximale Alter überschreibt. Die s-maxage-Direktive impliziert auch die Semantik der proxy-revalidate-Antwortdirektive.
Diese Direktive verwendet die Token-Form der Argumentsyntax: z. B. 's-maxage=10' nicht 's-maxage="10"'. Ein Absender SOLLTE NICHT (SHOULD NOT) die Form mit Anführungszeichen generieren.