5. Field Definitions (Felddefinitionen)

Dieser Abschnitt definiert die Syntax und Semantik von HTTP-Feldern im Zusammenhang mit Caching.

5.1 Age

Das "Age"-Antwort-Header-Feld übermittelt die Schätzung des Absenders über die Zeit, die seit der Generierung oder erfolgreichen Validierung der Antwort beim Ursprungsserver vergangen ist. Der Age-Wert wird wie in Abschnitt 4.2.3 angegeben berechnet.

Age = delta-seconds

Der Age-Feldwert ist eine nicht-negative Ganzzahl, die die Zeit in Sekunden darstellt (siehe Abschnitt 1.2.2).

Obwohl es als Singleton-Header-Feld definiert ist, sollte (SHOULD) ein Cache, der auf eine Nachricht mit einem listenbasierten Age-Feldwert stößt, das erste Mitglied des Feldwertes verwenden und nachfolgende Mitglieder verwerfen.

Wenn der Feldwert (nach dem Verwerfen anderer Mitglieder wie oben) ungültig ist (z.B. enthält er etwas anderes als eine nicht-negative Ganzzahl), sollte (SHOULD) ein Cache das Feld ignorieren.

Das Vorhandensein eines Age-Header-Feldes impliziert, dass die Antwort nicht vom Ursprungsserver für diese Anfrage generiert oder validiert wurde. Das Fehlen eines Age-Header-Feldes impliziert jedoch nicht, dass der Ursprungsserver kontaktiert wurde.

5.2 Cache-Control

Das "Cache-Control"-Header-Feld wird verwendet, um Direktiven für Caches entlang der Anfrage-/Antwortkette aufzulisten. Cache-Direktiven sind unidirektional, da das Vorhandensein einer Direktive in einer Anfrage nicht impliziert, dass dieselbe Direktive in der Antwort vorhanden ist oder kopiert wird.

Siehe Abschnitt 5.2.3 für Informationen darüber, wie anderswo definierte Cache-Control-Direktiven behandelt werden.

Ein Proxy muss (MUST), unabhängig davon, ob er einen Cache implementiert oder nicht, Cache-Direktiven in weitergeleiteten Nachrichten weitergeben, unabhängig von ihrer Bedeutung für diese Anwendung, da die Direktiven für alle Empfänger entlang der Anfrage-/Antwortkette gelten können. Es ist nicht möglich, eine Direktive auf einen bestimmten Cache zu richten.

Cache-Direktiven werden durch einen Token identifiziert (der case-insensitiv verglichen wird) und haben ein optionales Argument, das sowohl Token- als auch Quoted-String-Syntax verwenden kann. Für die unten definierten Direktiven, bei denen ein Argument definiert ist, sollten (SHOULD) Empfänger beide Formen akzeptieren, auch wenn eine bestimmte Form für die Generierung erforderlich ist.

Cache-Control   = #cache-directive

cache-directive = token [ "=" ( token / quoted-string ) ]

Für die unten definierten Cache-Direktiven ist kein Argument definiert (oder erlaubt), sofern nicht anders angegeben.

5.2.1 Request Directives (Anfrage-Direktiven)

Dieser Abschnitt definiert Cache-Anfrage-Direktiven. Sie sind beratend; Caches können (MAY) sie implementieren, sind aber nicht verpflichtet.

5.2.1.1 max-age

Argumentsyntax:

delta-seconds (siehe Abschnitt 1.2.2)

Die max-age-Anfrage-Direktive zeigt an, dass der Client eine Antwort bevorzugt, deren Alter kleiner oder gleich der angegebenen Anzahl von Sekunden ist. Sofern nicht auch die max-stale-Anfrage-Direktive vorhanden ist, möchte der Client keine veraltete Antwort erhalten.

Diese Direktive verwendet die Token-Form der Argumentsyntax: z.B. 'max-age=5' nicht 'max-age="5"'. Ein Sender darf nicht (MUST NOT) die Quoted-String-Form generieren.

5.2.1.2 max-stale

Argumentsyntax:

delta-seconds (siehe Abschnitt 1.2.2)

Die max-stale-Anfrage-Direktive zeigt an, dass der Client eine Antwort akzeptiert, die ihre Frischelebensdauer überschritten hat. Wenn ein Wert vorhanden ist, ist der Client bereit, eine Antwort zu akzeptieren, die ihre Frischelebensdauer um nicht mehr als die angegebene Anzahl von Sekunden überschritten hat. Wenn max-stale kein Wert zugewiesen wird, akzeptiert der Client eine veraltete Antwort jeden Alters.

Diese Direktive verwendet die Token-Form der Argumentsyntax: z.B. 'max-stale=10' nicht 'max-stale="10"'. Ein Sender darf nicht (MUST NOT) die Quoted-String-Form generieren.

5.2.1.3 min-fresh

Argumentsyntax:

delta-seconds (siehe Abschnitt 1.2.2)

Die min-fresh-Anfrage-Direktive zeigt an, dass der Client eine Antwort bevorzugt, deren Frischelebensdauer nicht kleiner ist als ihr aktuelles Alter plus die angegebene Anzahl von Sekunden. Das heißt, der Client möchte eine Antwort, die mindestens für die angegebene Anzahl von Sekunden frisch bleibt.

Diese Direktive verwendet die Token-Form der Argumentsyntax: z.B. 'min-fresh=20' nicht 'min-fresh="20"'. Ein Sender darf nicht (MUST NOT) die Quoted-String-Form generieren.

5.2.1.4 no-cache

Die no-cache-Anfrage-Direktive zeigt an, dass der Client es vorzieht, dass gespeicherte Antworten nicht zur Erfüllung der Anfrage verwendet werden, ohne erfolgreiche Validierung beim Ursprungsserver.

5.2.1.5 no-store

Die no-store-Anfrage-Direktive zeigt an, dass ein Cache keinen Teil dieser Anfrage oder einer Antwort darauf speichern darf (MUST NOT). Diese Direktive gilt sowohl für private als auch für gemeinsam genutzte Caches. "MUST NOT store" bedeutet in diesem Kontext, dass der Cache die Informationen nicht absichtlich in nicht-flüchtigem Speicher speichern darf (MUST NOT) und nach Möglichkeit bemüht sein muss (MUST), die Informationen so schnell wie möglich nach dem Weiterleiten 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öswillige oder kompromittierte Caches diese Direktive möglicherweise nicht erkennen oder befolgen, und Kommunikationsnetzwerke können anfällig für Abhören sein.

Beachten Sie, dass wenn eine Anfrage, die diese Direktive enthält, aus einem Cache erfüllt wird, die no-store-Anfrage-Direktive nicht für die bereits gespeicherte Antwort gilt.

5.2.1.6 no-transform

Die no-transform-Anfrage-Direktive zeigt an, dass der Client einen Vermittler bittet, die Transformation des Inhalts zu vermeiden, wie in Abschnitt 7.7 von [HTTP] definiert.

5.2.1.7 only-if-cached

Die only-if-cached-Anfrage-Direktive zeigt an, dass der Client nur eine gespeicherte Antwort erhalten möchte. Ein Cache, der diese Anfrage-Direktive berücksichtigt, sollte (SHOULD) beim Empfang mit entweder einer gespeicherten Antwort, die mit den anderen Einschränkungen der Anfrage übereinstimmt, oder einem 504 (Gateway Timeout)-Statuscode antworten.

5.2.2 Response Directives (Antwort-Direktiven)

Dieser Abschnitt definiert Cache-Antwort-Direktiven. Caches müssen (MUST) die in diesem Abschnitt definierten Cache-Control-Direktiven befolgen.

5.2.2.1 max-age

Argumentsyntax:

delta-seconds (siehe Abschnitt 1.2.2)

Die max-age-Antwort-Direktive zeigt an, dass die Antwort als veraltet betrachtet werden soll, nachdem ihr Alter größer als die angegebene Anzahl von Sekunden ist.

Diese Direktive verwendet die Token-Form der Argumentsyntax: z.B. 'max-age=5' nicht 'max-age="5"'. Ein Sender darf nicht (MUST NOT) die Quoted-String-Form generieren.

5.2.2.2 must-revalidate

Die must-revalidate-Antwort-Direktive zeigt an, dass ein Cache, sobald die Antwort veraltet ist, diese Antwort nicht zur Erfüllung einer anderen Anfrage wiederverwenden darf (MUST NOT), bis sie vom Ursprungsserver erfolgreich validiert wurde, wie in Abschnitt 4.3 definiert.

Die must-revalidate-Direktive ist notwendig, um den zuverlässigen Betrieb bestimmter Protokollfunktionen zu unterstützen. Unter allen Umständen darf (MUST NOT) ein Cache die must-revalidate-Direktive nicht ignorieren; insbesondere wenn ein Cache getrennt ist, muss (MUST) der Cache eine Fehlerantwort generieren, anstatt die veraltete Antwort wiederzuverwenden. Der generierte Statuscode sollte (SHOULD) 504 (Gateway Timeout) sein, sofern kein anderer Fehlerstatuscode anwendbarer ist.

Server sollten (SHOULD) die must-revalidate-Direktive nur verwenden, wenn das Versäumnis, eine Anfrage zu revalidieren, zu einem fehlerhaften Betrieb führen könnte (wie z.B. eine stillschweigend nicht ausgeführte Finanztransaktion).

Die must-revalidate-Direktive ermöglicht es einem gemeinsam genutzten Cache auch, eine Antwort auf eine Anfrage mit einem Authorization-Header-Feld (siehe Abschnitt 11.6.2 von [HTTP]) wiederzuverwenden, vorbehaltlich der obigen Anforderung zur Revalidierung (Abschnitt 3.5).

5.2.2.3 must-understand

Die must-understand-Antwort-Direktive beschränkt das Caching der Antwort auf Caches, die die Anforderungen für den Statuscode dieser Antwort verstehen und einhalten.

Eine Antwort, die eine must-understand-Direktive enthält, sollte (SHOULD) auch eine no-store-Direktive enthalten. Wenn ein Cache, der die must-understand-Direktive implementiert, eine Antwort erhält, die sie enthält, sollte (SHOULD) der Cache die no-store-Direktive ignorieren, wenn er die Caching-Anforderungen des Statuscodes versteht und implementiert.

5.2.2.4 no-cache

Argumentsyntax:

#field-name

Die no-cache-Antwort-Direktive in ihrer unqualifizierten Form (ohne Argument) zeigt an, dass die Antwort nicht zur Erfüllung einer anderen Anfrage verwendet werden darf (MUST NOT), ohne sie zur Validierung weiterzuleiten und eine erfolgreiche Antwort zu erhalten; siehe Abschnitt 4.3.

Dies ermöglicht es einem Ursprungsserver, einen Cache daran zu hindern, die Antwort zur Erfüllung einer Anfrage zu verwenden, ohne ihn zu kontaktieren, selbst durch Caches, die so konfiguriert wurden, veraltete Antworten zu senden.

Die qualifizierte Form der no-cache-Antwort-Direktive mit einem Argument, das einen oder mehrere Feldnamen auflistet, zeigt an, dass ein Cache die Antwort zur Erfüllung einer nachfolgenden Anfrage verwenden kann (MAY), vorbehaltlich anderer Einschränkungen für das Caching, wenn die aufgelisteten Header-Felder aus der nachfolgenden Antwort ausgeschlossen werden oder die nachfolgende Antwort mit dem Ursprungsserver erfolgreich revalidiert wurde (wobei diese Felder aktualisiert oder entfernt werden). 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 zulässig ist.

Die angegebenen Feldnamen sind nicht auf die von dieser Spezifikation definierten Header-Felder beschränkt. Feldnamen sind case-insensitiv.

Diese Direktive verwendet die Quoted-String-Form der Argumentsyntax. Ein Sender sollte nicht (SHOULD NOT) die Token-Form generieren (auch wenn für Einelementlisten keine Anführungszeichen erforderlich zu sein scheinen).

Hinweis: Die qualifizierte Form der Direktive wird von Caches häufig so behandelt, als ob eine unqualifizierte no-cache-Direktive empfangen worden wäre; d.h., die Sonderbehandlung der qualifizierten Form ist nicht weit verbreitet implementiert.

5.2.2.5 no-store

Die no-store-Antwort-Direktive zeigt an, dass ein Cache keinen Teil der unmittelbaren Anfrage oder Antwort speichern darf (MUST NOT) und die Antwort nicht zur Erfüllung einer anderen Anfrage verwenden darf (MUST NOT).

Diese Direktive gilt sowohl für private als auch für gemeinsam genutzte Caches. "MUST NOT store" bedeutet in diesem Kontext, dass der Cache die Informationen nicht absichtlich in nicht-flüchtigem Speicher speichern darf (MUST NOT) und nach Möglichkeit bemüht sein muss (MUST), die Informationen so schnell wie möglich nach dem Weiterleiten 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öswillige oder kompromittierte Caches diese Direktive möglicherweise nicht erkennen oder befolgen, und Kommunikationsnetzwerke können anfällig für Abhören sein.

Beachten Sie, dass die must-understand-Cache-Direktive no-store unter bestimmten Umständen überschreibt; siehe Abschnitt 5.2.2.3.

5.2.2.6 no-transform

Die no-transform-Antwort-Direktive zeigt an, dass ein Vermittler (unabhängig davon, ob er einen Cache implementiert) den Inhalt nicht transformieren darf (MUST NOT), wie in Abschnitt 7.7 von [HTTP] definiert.

5.2.2.7 private

Argumentsyntax:

#field-name

Die unqualifizierte private-Antwort-Direktive zeigt an, dass ein gemeinsam genutzter Cache die Antwort nicht speichern darf (MUST NOT) (d.h., die Antwort ist für einen einzelnen Benutzer bestimmt). Sie zeigt auch an, dass ein privater Cache die Antwort speichern kann (MAY), vorbehaltlich der in Abschnitt 3 definierten Einschränkungen, auch wenn die Antwort andernfalls nicht heuristisch von einem privaten Cache cachebar wäre.

Wenn eine qualifizierte private-Antwort-Direktive vorhanden ist (mit einem Argument, das einen oder mehrere Feldnamen auflistet), sind nur die aufgelisteten Header-Felder auf einen einzelnen Benutzer beschränkt: Ein gemeinsam genutzter Cache darf die aufgelisteten Header-Felder nicht speichern (MUST NOT), wenn sie in der ursprünglichen Antwort vorhanden sind, kann aber (MAY) den Rest der Antwortnachricht ohne diese Header-Felder speichern, vorbehaltlich der in Abschnitt 3 definierten Einschränkungen.

Die angegebenen Feldnamen sind nicht auf die von dieser Spezifikation definierten Header-Felder beschränkt. Feldnamen sind case-insensitiv.

Diese Direktive verwendet die Quoted-String-Form der Argumentsyntax. Ein Sender sollte nicht (SHOULD NOT) die Token-Form generieren (auch wenn für Einelementlisten keine Anführungszeichen erforderlich zu sein scheinen).

Hinweis: Diese Verwendung des Wortes "private" kontrolliert nur, wo die Antwort gespeichert werden kann; sie kann die Privatsphäre des Nachrichteninhalts nicht gewährleisten. Außerdem wird die qualifizierte Form der Direktive von Caches häufig so behandelt, als ob eine unqualifizierte private-Direktive empfangen worden wäre; d.h., die Sonderbehandlung der qualifizierten Form ist nicht weit verbreitet implementiert.

5.2.2.8 proxy-revalidate

Die proxy-revalidate-Antwort-Direktive zeigt an, dass ein gemeinsam genutzter Cache, sobald die Antwort veraltet ist, diese Antwort nicht zur Erfüllung einer anderen Anfrage wiederverwenden darf (MUST NOT), bis sie vom Ursprungsserver erfolgreich validiert wurde, wie in Abschnitt 4.3 definiert. Dies ist analog zu must-revalidate (Abschnitt 5.2.2.2), außer dass proxy-revalidate nicht für private Caches gilt.

Beachten Sie, dass proxy-revalidate allein nicht impliziert, dass eine Antwort cachebar ist. Zum Beispiel könnte sie mit der public-Direktive (Abschnitt 5.2.2.9) kombiniert werden, um das Caching einer Antwort zu ermöglichen, während nur gemeinsam genutzte Caches zur Revalidierung aufgefordert werden, wenn sie veraltet ist.

5.2.2.9 public

Die public-Antwort-Direktive zeigt an, dass ein Cache die Antwort speichern kann (MAY), auch wenn sie andernfalls verboten wäre, vorbehaltlich der in Abschnitt 3 definierten Einschränkungen. Mit anderen Worten, public markiert die Antwort explizit als cachebar. Zum Beispiel erlaubt public einem gemeinsam genutzten Cache, eine Antwort auf eine Anfrage mit einem Authorization-Header-Feld wiederzuverwenden (Abschnitt 3.5).

Beachten Sie, dass es nicht notwendig ist, die public-Direktive zu einer Antwort hinzuzufügen, die gemäß Abschnitt 3 bereits cachebar ist.

Wenn eine Antwort mit einer public-Direktive keine expliziten Frischeinformationen hat, ist sie heuristisch cachebar (Abschnitt 4.2.2).

5.2.2.10 s-maxage

Argumentsyntax:

delta-seconds (siehe Abschnitt 1.2.2)

Die s-maxage-Antwort-Direktive zeigt an, dass für einen gemeinsam genutzten Cache 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 enthält die Semantik der proxy-revalidate-Antwort-Direktive (Abschnitt 5.2.2.8) für gemeinsam genutzte Caches. Ein gemeinsam genutzter Cache darf (MUST NOT) eine veraltete Antwort mit s-maxage zur Erfüllung einer anderen Anfrage wiederverwenden, bis sie vom Ursprungsserver erfolgreich validiert wurde, wie in Abschnitt 4.3 definiert. Diese Direktive erlaubt es einem gemeinsam genutzten Cache auch, eine Antwort auf eine Anfrage mit einem Authorization-Header-Feld wiederzuverwenden, vorbehaltlich der obigen Anforderungen zu maximalem Alter und Revalidierung (Abschnitt 3.5).

Diese Direktive verwendet die Token-Form der Argumentsyntax: z.B. 's-maxage=10' nicht 's-maxage="10"'. Ein Sender darf nicht (MUST NOT) die Quoted-String-Form generieren.

5.2.3 Extension Directives (Erweiterungsdirektiven)

Das Cache-Control-Header-Feld kann durch die Verwendung einer oder mehrerer Erweiterungs-Cache-Direktiven erweitert werden. Ein Cache muss (MUST) 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 als Modifikatoren zur bestehenden Basis von Cache-Direktiven fungieren. Sowohl die neue Direktive als auch die alte Direktive werden bereitgestellt, so dass Anwendungen, die die neue Direktive nicht verstehen, standardmäßig auf das durch die alte Direktive angegebene Verhalten zurückgreifen, und diejenigen, die die neue Direktive verstehen, sie als Modifikation der mit der alten Direktive verbundenen Anforderungen erkennen. Auf diese Weise können Erweiterungen zu bestehenden Cache-Direktiven vorgenommen werden, ohne bereitgestellte Caches zu brechen.

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

Cache-Control: private, community="UCI"

Caches, die eine solche community-Cache-Direktive erkennen, könnten ihr Verhalten gemäß dieser Erweiterung erweitern. Caches, die die community-Cache-Direktive nicht erkennen, würden sie ignorieren und sich an die private-Direktive halten.

Neue Erweiterungsdirektiven sollten in Betracht ziehen, Folgendes zu definieren:

• Was es bedeutet, wenn die Direktive mehrmals angegeben wird,

• Wenn das Direktiv-Argument vorhanden ist, was es bedeutet, wenn das Argument fehlt,

• Wenn das Direktiv-Argument erforderlich ist, was es bedeutet, wenn das Argument fehlt, und

• Ob die Direktive anfragespezifisch, antwortspezifisch ist oder in beiden verwendet werden kann.

5.2.4 Cache Directive Registry (Cache-Direktiven-Register)

Das "Hypertext Transfer Protocol (HTTP) Cache Directive Registry" definiert den Namensraum für Cache-Direktiven. Es wurde erstellt und wird jetzt unter https://www.iana.org/assignments/http-cache-directives gepflegt.

Eine Registrierung muss (MUST) die folgenden Felder enthalten:

• Name der Cache-Direktive

• Zeiger auf Spezifikationstext

Werte, die zu diesem Namensraum hinzugefügt werden sollen, erfordern IETF Review (siehe Abschnitt 4.8 von [RFC8126]).

5.3 Expires

Das "Expires"-Antwort-Header-Feld gibt das Datum/die Uhrzeit an, nach der die Antwort als veraltet betrachtet wird. Siehe Abschnitt 4.2 für weitere Diskussion des Frischemodells.

Das Vorhandensein eines Expires-Header-Feldes 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-date-Zeitstempel, wie in Abschnitt 5.6.7 von [HTTP] definiert. Für cache-spezifische Parsing-Anforderungen siehe auch Abschnitt 4.2.

Expires = HTTP-date

Beispiel:

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

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

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

Ein Ursprungsserver ohne Uhr (siehe Abschnitt 5.6.7 von [HTTP]) darf kein Expires-Header-Feld generieren (MUST NOT), es sei denn, sein Wert repräsentiert eine feste Zeit in der Vergangenheit (immer abgelaufen) oder sein Wert wurde durch ein System mit einer Uhr der Ressource zugeordnet.

Historisch verlangte HTTP, dass der Expires-Feldwert nicht mehr als ein Jahr in der Zukunft liegt. Obwohl längere Frischelebensdauern nicht mehr verboten sind, hat sich gezeigt, dass extrem große Werte Probleme verursachen (z.B. Uhrenüberlauf aufgrund der Verwendung von 32-Bit-Ganzzahlen für Zeitwerte), und viele Caches werden eine Antwort viel früher entfernen.

5.4 Pragma

Das "Pragma"-Anfrage-Header-Feld wurde für HTTP/1.0-Caches definiert, damit Clients eine "no-cache"-Anfrage angeben konnten (da Cache-Control erst mit HTTP/1.1 definiert wurde).

Die Unterstützung für Cache-Control ist jedoch mittlerweile weit verbreitet. Infolgedessen macht diese Spezifikation Pragma obsolet.

Hinweis: Da die Bedeutung von "Pragma: no-cache" in Antworten nie spezifiziert wurde, bietet es keinen zuverlässigen Ersatz für "Cache-Control: no-cache" in Antworten.

5.5 Warning

Das "Warning"-Header-Feld wurde verwendet, um zusätzliche Informationen über den Status oder die Transformation einer Nachricht zu übertragen, die möglicherweise nicht im Statuscode widergespiegelt werden. Diese Spezifikation macht es obsolet, da es nicht weit verbreitet generiert oder Benutzern angezeigt wird. Die Informationen, die es übertrug, können durch Untersuchung anderer Header-Felder wie Age gesammelt werden.