5. Header Field Definitions (Header-Felddefinitionen)

Dieser Abschnitt definiert die Syntax und Semantik der HTTP/1.1-Header-Felder im Zusammenhang mit der Zwischenspeicherung (Caching).

5.1. Age

Das „Age"-Header-Feld übermittelt die Schätzung des Senders über die Zeit, die seit der Erzeugung oder erfolgreichen Validierung der Antwort beim Ursprungsserver vergangen ist. Age-Werte werden gemäß Abschnitt 4.2.3 berechnet.

Age = delta-seconds

Der Age-Feldwert ist eine nicht-negative ganze Zahl, die die Zeit in Sekunden darstellt (siehe Abschnitt 1.2.1).

Das Vorhandensein eines Age-Header-Felds impliziert, dass die Antwort nicht vom Ursprungsserver für diese Anforderung erzeugt oder validiert wurde. Das Fehlen eines Age-Header-Felds impliziert jedoch nicht, dass der Ursprungsserver kontaktiert wurde, da die Antwort möglicherweise von einem HTTP/1.0-Cache empfangen wurde, der Age nicht implementiert.

5.2. Cache-Control

Das „Cache-Control"-Header-Feld wird verwendet, um Direktiven für Caches entlang der Anforderungs-/Antwortkette anzugeben. Solche Cache-Direktiven sind unidirektional, d. h. das Vorhandensein einer Direktive in einer Anforderung impliziert nicht, dass dieselbe Direktive in der Antwort angegeben werden muss.

Ein Cache MUSS die Anforderungen der in diesem Abschnitt definierten Cache-Control-Direktiven einhalten. Informationen zur Behandlung von anderswo definierten Cache-Control-Direktiven finden Sie in Abschnitt 5.2.3.

Hinweis: Einige HTTP/1.0-Caches implementieren Cache-Control möglicherweise nicht.

Ein Proxy, unabhängig davon, ob er einen Cache implementiert, MUSS Cache-Direktiven in weitergeleiteten Nachrichten durchleiten, unabhängig von ihrer Bedeutung für diese Anwendung, da die Direktiven möglicherweise für alle Empfänger entlang der Anforderungs-/Antwortkette gelten. Es ist nicht möglich, eine Direktive auf einen bestimmten Cache zu richten.

Cache-Direktiven werden durch ein Token identifiziert, das ohne Berücksichtigung der Groß-/Kleinschreibung verglichen wird, und haben ein optionales Argument, das sowohl Token- als auch Quoted-String-Syntax verwenden kann. Für die unten definierten Direktiven, die Argumente definieren, SOLLTEN Empfänger beide Formen akzeptieren, auch wenn eine als bevorzugt dokumentiert ist. Für jede Direktive, die nicht durch diese Spezifikation definiert ist, MUSS ein Empfänger beide Formen akzeptieren.

Cache-Control   = 1#cache-directive

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

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

5.2.1. Request Cache-Control Directives (Anforderungs-Cache-Control-Direktiven)

5.2.1.1. max-age

Argumentsyntax:

delta-seconds (siehe Abschnitt 1.2.1)

Die „max-age"-Anforderungsdirektive zeigt an, dass der Client keine Antwort akzeptieren möchte, deren Alter größer als die angegebene Anzahl von Sekunden ist. Sofern die max-stale-Anforderungsdirektive nicht ebenfalls vorhanden ist, ist der Client nicht bereit, eine veraltete Antwort zu akzeptieren.

Diese Direktive verwendet die Token-Form der Argumentsyntax: z. B. 'max-age=5' und nicht 'max-age="5"'. Ein Sender SOLLTE die Quoted-String-Form nicht erzeugen.

5.2.1.2. max-stale

Argumentsyntax:

delta-seconds (siehe Abschnitt 1.2.1)

Die „max-stale"-Anforderungsdirektive zeigt an, dass der Client bereit ist, eine Antwort zu akzeptieren, die ihre Frischelebensdauer überschritten hat. Wenn max-stale ein Wert zugewiesen wird, 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, ist der Client bereit, eine veraltete Antwort beliebigen Alters zu akzeptieren.

Diese Direktive verwendet die Token-Form der Argumentsyntax: z. B. 'max-stale=10' und nicht 'max-stale="10"'. Ein Sender SOLLTE die Quoted-String-Form nicht erzeugen.

5.2.1.3. min-fresh

Argumentsyntax:

delta-seconds (siehe Abschnitt 1.2.1)

Die „min-fresh"-Anforderungsdirektive zeigt an, dass der Client bereit ist, eine Antwort zu akzeptieren, deren Frischelebensdauer nicht kleiner als ihr aktuelles Alter plus die angegebene Zeit in Sekunden ist. Das heißt, der Client möchte eine Antwort, die noch mindestens die angegebene Anzahl von Sekunden frisch sein wird.

Diese Direktive verwendet die Token-Form der Argumentsyntax: z. B. 'min-fresh=20' und nicht 'min-fresh="20"'. Ein Sender SOLLTE die Quoted-String-Form nicht erzeugen.

5.2.1.4. no-cache

Die „no-cache"-Anforderungsdirektive zeigt an, dass ein Cache KEINE gespeicherte Antwort verwenden DARF, um die Anforderung ohne erfolgreiche Validierung beim Ursprungsserver zu erfüllen.

5.2.1.5. no-store

Die „no-store"-Anforderungsdirektive zeigt an, dass ein Cache KEINEN Teil dieser Anforderung oder einer Antwort darauf speichern DARF. Diese Direktive gilt sowohl für private als auch für gemeinsam genutzte Caches. „DARF NICHT speichern" bedeutet in diesem Zusammenhang, dass der Cache die Informationen NICHT absichtlich in nichtflüchtigem Speicher speichern DARF und MUSS sich nach besten Kräften bemühen, 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 des Datenschutzes. Insbesondere erkennen bösartige oder kompromittierte Caches diese Direktive möglicherweise nicht oder halten sie nicht ein, und Kommunikationsnetzwerke können anfällig für Abhören sein.

Beachten Sie, dass die no-store-Anforderungsdirektive nicht für die bereits gespeicherte Antwort gilt, wenn eine Anforderung mit dieser Direktive aus einem Cache erfüllt wird.

5.2.1.6. no-transform

Die „no-transform"-Anforderungsdirektive zeigt an, dass ein Vermittler (unabhängig davon, ob er einen Cache implementiert) die Nutzlast NICHT transformieren DARF, wie in Abschnitt 5.7.2 von [RFC7230] definiert.

5.2.1.7. only-if-cached

Die „only-if-cached"-Anforderungsdirektive zeigt an, dass der Client nur eine gespeicherte Antwort erhalten möchte. Wenn ein Cache diese Direktive empfängt, SOLLTE er entweder mit einer gespeicherten Antwort antworten, die mit den anderen Einschränkungen der Anforderung übereinstimmt, oder mit dem Statuscode 504 (Gateway Timeout) antworten. Wenn eine Gruppe von Caches als einheitliches System mit guter interner Konnektivität betrieben wird, KANN ein Mitglied-Cache eine solche Anforderung innerhalb dieser Gruppe von Caches weiterleiten.

5.2.2. Response Cache-Control Directives (Antwort-Cache-Control-Direktiven)

5.2.2.1. must-revalidate

Die „must-revalidate"-Antwortdirektive zeigt an, dass ein Cache, sobald die Antwort veraltet ist, KEINE veraltete Antwort verwenden DARF, um nachfolgende Anforderungen ohne erfolgreiche Validierung beim Ursprungsserver zu erfüllen.

Die must-revalidate-Direktive ist notwendig, um den zuverlässigen Betrieb bestimmter Protokollfunktionen zu unterstützen. Unter allen Umständen MUSS ein Cache die must-revalidate-Direktive einhalten; insbesondere MUSS er eine 504 (Gateway Timeout)-Antwort erzeugen, wenn er den Ursprungsserver aus irgendeinem Grund nicht erreichen kann.

Die must-revalidate-Direktive SOLLTE von Servern nur dann verwendet werden, wenn das Versäumnis, eine Anforderung auf der Darstellung zu validieren, zu einem falschen Betrieb führen könnte, wie z. B. einer stillschweigend nicht ausgeführten Finanztransaktion.

5.2.2.2. no-cache

Argumentsyntax:

#field-name

Die „no-cache"-Antwortdirektive zeigt an, dass die Antwort NICHT verwendet werden DARF, um eine nachfolgende Anforderung ohne erfolgreiche Validierung beim Ursprungsserver zu erfüllen. Dies ermöglicht es einem Ursprungsserver, zu verhindern, dass ein Cache sie zur Erfüllung einer Anforderung verwendet, ohne ihn zu kontaktieren, selbst bei Caches, die so konfiguriert wurden, veraltete Antworten zu senden.

Wenn die no-cache-Antwortdirektive einen oder mehrere Feldnamen angibt, KANN ein Cache die Antwort verwenden, um eine nachfolgende Anforderung zu erfüllen, vorbehaltlich anderer Einschränkungen für die Zwischenspeicherung. Alle Header-Felder in der Antwort, die die aufgeführten Feldnamen haben, DÜRFEN jedoch NICHT in der Antwort auf eine nachfolgende Anforderung gesendet werden, ohne erfolgreiche Revalidierung beim Ursprungsserver. Dies ermöglicht es einem Ursprungsserver, die Wiederverwendung bestimmter Header-Felder in einer Antwort zu verhindern, während die Zwischenspeicherung des restlichen Teils der Antwort weiterhin erlaubt wird.

Die angegebenen Feldnamen sind nicht auf die Menge der durch diese Spezifikation definierten Header-Felder beschränkt. Feldnamen sind nicht case-sensitiv.

Diese Direktive verwendet die Quoted-String-Form der Argumentsyntax. Ein Sender SOLLTE die Token-Form nicht erzeugen (auch wenn das Quoting für Einzeleintragslisten nicht erforderlich zu sein scheint).

Hinweis: Obwohl auf viele Implementierungen zurückportiert, erkennen einige HTTP/1.0-Caches diese Direktive nicht oder halten sie nicht ein. Darüber hinaus wird die no-cache-Antwortdirektive mit Feldnamen von Caches typischerweise so behandelt, als ob eine nicht qualifizierte no-cache-Direktive empfangen wurde; d. h. die spezielle Behandlung der qualifizierten Form ist nicht weit verbreitet implementiert.

5.2.2.3. no-store

Die „no-store"-Antwortdirektive zeigt an, dass ein Cache KEINEN Teil der unmittelbaren Anforderung oder Antwort speichern DARF. Diese Direktive gilt sowohl für private als auch für gemeinsam genutzte Caches. „DARF NICHT speichern" bedeutet in diesem Zusammenhang, dass der Cache die Informationen NICHT absichtlich in nichtflüchtigem Speicher speichern DARF und MUSS sich nach besten Kräften bemühen, 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 des Datenschutzes. Insbesondere erkennen bösartige oder kompromittierte Caches diese Direktive möglicherweise nicht oder halten sie nicht ein, und Kommunikationsnetzwerke können anfällig für Abhören sein.

5.2.2.4. no-transform

Die „no-transform"-Antwortdirektive zeigt an, dass ein Vermittler (unabhängig davon, ob er einen Cache implementiert) die Nutzlast NICHT transformieren DARF, wie in Abschnitt 5.7.2 von [RFC7230] definiert.

5.2.2.5. public

Die „public"-Antwortdirektive zeigt an, dass jeder Cache die Antwort speichern KANN, auch wenn die Antwort normalerweise nicht zwischenspeicherbar oder nur in einem privaten Cache zwischenspeicherbar wäre. (Weitere Details zur Verwendung von public als Antwort auf eine Anforderung mit Authorization finden Sie in Abschnitt 3.2, und Details dazu, wie public Antworten beeinflusst, die normalerweise nicht gespeichert würden, da ihre Statuscodes standardmäßig nicht als zwischenspeicherbar definiert sind, finden Sie in Abschnitt 3; siehe Abschnitt 4.2.2.)

5.2.2.6. private

Argumentsyntax:

#field-name

Die „private"-Antwortdirektive zeigt an, dass die Antwortnachricht für einen einzelnen Benutzer bestimmt ist und NICHT von einem gemeinsam genutzten Cache gespeichert werden DARF. Ein privater Cache KANN die Antwort speichern und für spätere Anforderungen wiederverwenden, auch wenn die Antwort normalerweise nicht zwischenspeicherbar wäre.

Wenn die private-Antwortdirektive einen oder mehrere Feldnamen angibt, ist diese Anforderung auf die Feldwerte beschränkt, die den aufgeführten Antwort-Header-Feldern zugeordnet sind. Das heißt, ein gemeinsam genutzter Cache DARF die angegebenen Feldnamen NICHT speichern, während er den Rest der Antwortnachricht speichern KANN.

Die angegebenen Feldnamen sind nicht auf die Menge der durch diese Spezifikation definierten Header-Felder beschränkt. Feldnamen sind nicht case-sensitiv.

Diese Direktive verwendet die Quoted-String-Form der Argumentsyntax. Ein Sender SOLLTE die Token-Form nicht erzeugen (auch wenn das Quoting für Einzeleintragslisten nicht erforderlich zu sein scheint).

Hinweis: Diese Verwendung des Begriffs „private" steuert nur, wo die Antwort gespeichert werden kann; sie gewährleistet nicht den Datenschutz des Nachrichteninhalts. Darüber hinaus wird die private-Antwortdirektive mit Feldnamen von Caches typischerweise so behandelt, als ob eine nicht qualifizierte private-Direktive empfangen wurde; d. h. die spezielle Behandlung der qualifizierten Form ist nicht weit verbreitet implementiert.

5.2.2.7. proxy-revalidate

Die „proxy-revalidate"-Antwortdirektive hat dieselbe Bedeutung wie die must-revalidate-Antwortdirektive, gilt jedoch nicht für private Caches.

5.2.2.8. max-age

Argumentsyntax:

delta-seconds (siehe Abschnitt 1.2.1)

Die „max-age"-Antwortdirektive zeigt an, dass die Antwort als veraltet gilt, wenn ihr Alter größer als die angegebene Anzahl von Sekunden ist.

Diese Direktive verwendet die Token-Form der Argumentsyntax: z. B. 'max-age=5' und nicht 'max-age="5"'. Ein Sender SOLLTE die Quoted-String-Form nicht erzeugen.

5.2.2.9. s-maxage

Argumentsyntax:

delta-seconds (siehe Abschnitt 1.2.1)

Die „s-maxage"-Antwortdirektive zeigt 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' und nicht 's-maxage="10"'. Ein Sender SOLLTE die Quoted-String-Form nicht erzeugen.

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

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 als Modifikatoren für die bestehende Basis von Cache-Direktiven fungieren. Sowohl die neue als auch die alte Direktive werden bereitgestellt, sodass Anwendungen, die die neue Direktive nicht verstehen, standardmäßig das durch die alte Direktive angegebene Verhalten verwenden, und diejenigen, die die neue Direktive verstehen, sie als Modifikation der mit der alten Direktive verbundenen Anforderungen erkennen. Auf diese Weise können Erweiterungen der bestehenden Cache-Control-Direktiven vorgenommen werden, ohne eingesetzte Caches zu beschädigen.

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 durch Einbeziehung von Folgendem tun:

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 die private-Direktive einhalten.

5.3. Expires

Das „Expires"-Header-Feld gibt das Datum/die Uhrzeit an, nach der die Antwort als veraltet gilt. Weitere Diskussionen zum Frischemodell finden Sie in Abschnitt 4.2.

Das Vorhandensein eines Expires-Felds impliziert nicht, dass die ursprüngliche Ressource sich zu, vor oder nach diesem Zeitpunkt ändern oder aufhören zu existieren wird.

Der Expires-Wert 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 einen Zeitpunkt in der Vergangenheit interpretieren (d. h. „bereits abgelaufen").

Wenn eine Antwort ein Cache-Control-Feld mit der max-age-Direktive (Abschnitt 5.2.2.8) enthält, MUSS ein Empfänger das Expires-Feld ignorieren. Ebenso MUSS ein gemeinsam genutzter Cache-Empfänger das Expires-Feld ignorieren, wenn eine Antwort die s-maxage-Direktive (Abschnitt 5.2.2.9) enthält. 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 KEIN Expires-Feld erzeugen, es sei denn, sein Wert stellt einen festen Zeitpunkt in der Vergangenheit dar (immer abgelaufen) oder sein Wert wurde der Ressource von einem System oder Benutzer mit einer zuverlässigen Uhr zugeordnet.

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

5.4. Pragma

Das „Pragma"-Header-Feld ermöglicht die Rückwärtskompatibilität mit HTTP/1.0-Caches, sodass Clients eine „no-cache"-Anforderung angeben können, die sie verstehen werden (da Cache-Control erst in HTTP/1.1 definiert wurde). Wenn das Cache-Control-Header-Feld ebenfalls vorhanden ist und in einer Anforderung 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 solche Erweiterungen, um die Interoperabilität zu verbessern.

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

Wenn das Cache-Control-Header-Feld in einer Anforderung nicht vorhanden ist, MÜSSEN Caches die no-cache-Anforderungs-Pragma-Direktive so behandeln, als ob „Cache-Control: no-cache" vorhanden wäre (siehe Abschnitt 5.2.1).

Beim Senden einer no-cache-Anforderung SOLLTE ein Client sowohl die Pragma- als auch die Cache-Control-Direktiven einbeziehen, es sei denn, Cache-Control: no-cache wird absichtlich weggelassen, um andere Cache-Control-Antwortdirektiven bei HTTP/1.1-Caches anzusprechen. Zum Beispiel:

GET / HTTP/1.1
Host: www.example.com
Cache-Control: max-age=30
Pragma: no-cache

Dies schränkt HTTP/1.1-Caches darauf ein, eine Antwort zu liefern, die nicht älter als 30 Sekunden ist, während Implementierungen, die Cache-Control nicht verstehen, daran gehindert werden, eine zwischengespeicherte Antwort zu liefern.

Hinweis: Da die Bedeutung von „Pragma: no-cache" in Antworten nicht spezifiziert ist, kann es keinen zuverlässigen Ersatz für „Cache-Control: no-cache" bieten.

5.5. Warning

Das „Warning"-Header-Feld wird verwendet, um zusätzliche Informationen über den Status oder die Transformation einer Nachricht zu übermitteln, die möglicherweise nicht im Statuscode widergespiegelt werden. Diese Informationen werden typischerweise verwendet, um vor möglichen Ungenauigkeiten zu warnen, die durch Caching-Operationen oder Transformationen eingeführt wurden, die auf die Nutzlast der Nachricht angewendet wurden.

Warnungen können für andere Zwecke verwendet werden, sowohl cache-bezogen als auch anderweitig. Die Verwendung einer Warnung anstelle eines Fehlerstatuscodes unterscheidet diese Antworten von echten Fehlern.

Warning-Header-Felder können im Allgemeinen auf jede Nachricht angewendet werden, einige Warn-Codes sind jedoch spezifisch für Caches und können nur auf Antwortnachrichten angewendet werden.

Warning       = 1#warning-value

warning-value = warn-code SP warn-agent SP warn-text
                                      [ SP warn-date ]

warn-code  = 3DIGIT
warn-agent = ( uri-host [ ":" port ] ) / pseudonym
                ; der Name oder Pseudonym des Servers, der das
                ; Warning-Header-Feld hinzufügt, zur Verwendung
                ; beim Debuggen; ein einzelnes "-" wird empfohlen,
                ; wenn der Agent unbekannt ist
warn-text  = quoted-string
warn-date  = DQUOTE HTTP-date DQUOTE

In einer Antwort können mehrere Warnungen erzeugt werden (entweder vom Ursprungsserver oder von einem Cache), einschließlich mehrerer Warnungen mit derselben Warn-Code-Nummer, die sich nur im warn-text unterscheiden.

Ein Benutzeragent, der ein oder mehrere Warning-Header-Felder empfängt, SOLLTE den Benutzer über so viele davon wie möglich informieren, in der Reihenfolge, in der sie in der Antwort erscheinen. Sender, die mehrere Warning-Header-Felder erzeugen, werden ermutigt, sie unter Berücksichtigung dieses Benutzeragentenverhaltens zu ordnen. Ein Sender, der neue Warning-Header-Felder erzeugt, MUSS sie nach vorhandenen Warning-Header-Feldern anhängen.

Warnungen werden dreistellige Warn-Codes zugewiesen. Die erste Ziffer gibt an, ob die Warnung nach der Validierung aus einer gespeicherten Antwort gelöscht werden muss:

• 1xx-Warn-Codes beschreiben den Frische- oder Validierungsstatus der Antwort und MÜSSEN daher nach der Validierung von einem Cache gelöscht werden. Sie können nur von einem Cache beim Validieren eines zwischengespeicherten Eintrags erzeugt werden und DÜRFEN in keiner anderen Situation erzeugt werden.

• 2xx-Warn-Codes beschreiben einen Aspekt der Darstellung, der durch eine Validierung nicht behoben wird (z. B. eine verlustbehaftete Komprimierung der Darstellung), und sie DÜRFEN nach der Validierung NICHT von einem Cache gelöscht werden, es sei denn, eine vollständige Antwort wird gesendet, in diesem Fall MÜSSEN sie gelöscht werden.

Wenn ein Sender einen oder mehrere 1xx-Warn-Codes in einer Nachricht erzeugt, die an einen Empfänger gesendet werden soll, von dem bekannt ist, dass er nur HTTP/1.0 implementiert, MUSS der Sender in jedem entsprechenden warning-value ein warn-date einbeziehen, das mit dem Date-Header-Feld in der Nachricht übereinstimmt. Zum Beispiel:

HTTP/1.1 200 OK
Date: Sat, 25 Aug 2012 23:34:45 GMT
Warning: 112 - "network down" "Sat, 25 Aug 2012 23:34:45 GMT"

Warnungen haben begleitenden warn-text, der den Fehler beschreibt, z. B. für die Protokollierung. Er ist nur beratend, und sein Inhalt beeinflusst nicht die Interpretation des warn-code.

Wenn ein Empfänger, der Warning-Header-Felder verwendet, auswertet oder anzeigt, ein warn-date empfängt, das sich vom Date-Wert in derselben Nachricht unterscheidet, MUSS der Empfänger den warning-value, der dieses warn-date enthält, vor dem Speichern, Weiterleiten oder Verwenden der Nachricht ausschließen. Dies ermöglicht es Empfängern, warning-values auszuschließen, die nach einer Cache-Validierung unangemessen beibehalten wurden. Wenn alle warning-values ausgeschlossen werden, MUSS der Empfänger auch das Warning-Header-Feld ausschließen.

Die folgenden Warn-Codes werden durch diese Spezifikation definiert, jeder mit einem empfohlenen warn-text auf Englisch und einer Beschreibung seiner Bedeutung. Das Verfahren zur Definition zusätzlicher Warn-Codes ist in Abschnitt 7.2.1 beschrieben.

5.5.1. Warning: 110 - „Response is Stale" (Antwort ist veraltet)

Ein Cache SOLLTE dies immer dann erzeugen, wenn die gesendete Antwort veraltet ist.

5.5.2. Warning: 111 - „Revalidation Failed" (Revalidierung fehlgeschlagen)

Ein Cache SOLLTE dies erzeugen, wenn er eine veraltete Antwort sendet, weil ein Versuch, die Antwort zu validieren, aufgrund der Unfähigkeit, den Server zu erreichen, fehlgeschlagen ist.

5.5.3. Warning: 112 - „Disconnected Operation" (Getrennte Operation)

Ein Cache SOLLTE dies erzeugen, wenn er absichtlich für einen Zeitraum vom Rest des Netzwerks getrennt ist.

5.5.4. Warning: 113 - „Heuristic Expiration" (Heuristische Ablaufzeit)

Ein Cache SOLLTE dies erzeugen, wenn er heuristisch eine Frischelebensdauer von mehr als 24 Stunden gewählt hat und das Alter der Antwort größer als 24 Stunden ist.

5.5.5. Warning: 199 - „Miscellaneous Warning" (Verschiedene Warnung)

Der Warntext kann beliebige Informationen enthalten, die einem menschlichen Benutzer präsentiert oder protokolliert werden sollen. Ein System, das diese Warnung empfängt, DARF KEINE automatisierten Maßnahmen ergreifen, außer die Warnung dem Benutzer zu präsentieren.

5.5.6. Warning: 214 - „Transformation Applied" (Transformation angewendet)

Dieser Warn-Code MUSS von einem Proxy hinzugefügt werden, wenn er eine Transformation auf die Darstellung anwendet, wie z. B. das Ändern der Content-Coding, des Medientyps oder das Modifizieren der Darstellungsdaten, es sei denn, dieser Warn-Code erscheint bereits in der Antwort.

5.5.7. Warning: 299 - „Miscellaneous Persistent Warning" (Verschiedene persistente Warnung)

Der Warntext kann beliebige Informationen enthalten, die einem menschlichen Benutzer präsentiert oder protokolliert werden sollen. Ein System, das diese Warnung empfängt, DARF KEINE automatisierten Maßnahmen ergreifen.