5.2.3. Cache-Control-Erweiterungen (Cache Control Extensions)

Das Cache-Control-Header-Feld kann durch die Verwendung eines oder mehrerer Cache-Erweiterungs-Tokens erweitert werden, jedes mit einem optionalen Wert. Ein Cache MUSS nicht erkannte Cache-Direktiven ignorieren.

Informationserweiterungen (solche, die keine Änderung des Cache-Verhaltens erfordern) können hinzugefügt werden, ohne die Semantik anderer Direktiven zu ändern.

Verhaltenserweiterungen sind so konzipiert, dass sie funktionieren, indem sie als Modifikatoren zur bestehenden Basis von Cache-Direktiven fungieren. Sowohl die neue Direktive als auch die Standarddirektive werden bereitgestellt, sodass Anwendungen, die die neue Direktive nicht verstehen, standardmäßig auf das durch die Standarddirektive angegebene Verhalten zurückgreifen, und diejenigen, die die neue Direktive verstehen, sie als Modifikation der mit der Standarddirektive verbundenen Anforderungen erkennen. Auf diese Weise können Erweiterungen der Cache-Control-Direktiven vorgenommen werden, ohne bereitgestellte Caches zu zerstören.

Betrachten Sie beispielsweise eine hypothetische neue Antwortdirektive namens "community", die als Modifikator der private-Direktive fungiert: Zusätzlich zu privaten Caches darf jeder Cache, der nur von Mitgliedern der benannten Community gemeinsam genutzt wird, die Antwort zwischenspeichern. Ein Ursprungsserver, der der UCI-Community erlauben möchte, eine ansonsten private Antwort in ihren gemeinsam genutzten Caches zu verwenden, könnte dies tun, indem er Folgendes einschließt:

Cache-Control: private, community="UCI"

Ein Cache, der eine solche community-Cache-Erweiterung erkennt, könnte sein Verhalten gemäß dieser Erweiterung erweitern. Ein Cache, der die community-Cache-Erweiterung nicht erkennt, würde sie ignorieren und sich an die private-Direktive halten.

5.3. Ablaufzeit (Expires)

Das "Expires"-Header-Feld gibt das Datum/die Uhrzeit an, nach der die Antwort als veraltet gilt. Siehe Abschnitt 4.2 für weitere Diskussionen zum Frische-Modell.

Das Vorhandensein eines Expires-Felds impliziert nicht, dass die ursprüngliche Ressource zu, vor oder nach dieser Zeit geändert wird oder aufhört zu existieren.

Der Expires-Feldwert ist ein HTTP-Datums-Zeitstempel, wie in Abschnitt 7.1.1.1 von [RFC7231] definiert.

Expires = HTTP-date

Zum Beispiel:

Expires: Thu, 01 Dec 1994 16:00:00 GMT

Ein Cache-Empfänger MUSS ungültige Datumsformate, insbesondere den Wert "0", als Zeitpunkt in der Vergangenheit (d. h. "bereits abgelaufen") interpretieren.

Wenn eine Antwort ein Cache-Control-Feld mit der max-age-Direktive enthält (Abschnitt 5.2.2.8), MUSS ein Empfänger das Expires-Feld ignorieren. Ebenso, wenn eine Antwort die s-maxage-Direktive enthält (Abschnitt 5.2.2.9), MUSS ein gemeinsam genutzter Cache-Empfänger das Expires-Feld ignorieren. In beiden Fällen ist der Wert in Expires nur für Empfänger gedacht, die das Cache-Control-Feld noch nicht implementiert haben.

Ein Ursprungsserver ohne Uhr DARF NICHT ein Expires-Feld generieren, es sei denn, sein Wert stellt eine feste Zeit in der Vergangenheit dar (immer abgelaufen) oder sein Wert wurde von einem anderen System oder einer Person mit einer zuverlässigen Uhr mit der Ressource verknüpft.

Historisch gesehen verlangte HTTP, dass der Expires-Feldwert nicht mehr als ein Jahr in der Zukunft liegt. Während längere Frischelebensdauern nicht mehr verboten sind, werden extrem große Werte (z. B. ein zukünftiges Datum jenseits des Jahres 9999) nicht empfohlen, da sie Probleme mit Zeitstempel-Parsing und arithmetischem Überlauf verursachen können.

5.4. Pragma (Pragma)

Das "Pragma"-Header-Feld ermöglicht Rückwärtskompatibilität mit HTTP/1.0-Caches, sodass Clients eine "no-cache"-Anfrage angeben können, die sie verstehen (da Cache-Control erst ab HTTP/1.1 definiert wurde). Wenn das Cache-Control-Header-Feld auch in einer Anfrage vorhanden und verstanden wird, wird Pragma ignoriert.

In HTTP/1.0 wurde Pragma als erweiterbares Feld für implementierungsspezifische Direktiven für Empfänger definiert. Diese Spezifikation missbilligt Pragma für alles andere als Rückwärtskompatibilität mit HTTP/1.0-Bereitstellungen.

Pragma = 1#pragma-directive
pragma-directive = "no-cache" / extension-pragma
extension-pragma = token [ "=" ( token / quoted-string ) ]

Wenn das Cache-Control-Header-Feld in einer Anfrage nicht vorhanden ist, MÜSSEN Caches das Pragma-Header-Feld der Anfrage berücksichtigen, um festzustellen, ob eine "no-cache"-Direktive vorhanden ist.

Hinweis: Da die Bedeutung von "Pragma: no-cache" in Antworten nicht spezifiziert ist, bietet es keinen zuverlässigen Ersatz für "Cache-Control: no-cache" in diesen. Absender SOLLTEN NICHT Pragma in einer HTTP/1.1-Nachricht generieren, die Cache-Control enthält.