5. Felder
HTTP verwendet "Felder" (Fields), um Daten in Form von erweiterbaren Name/Wert-Paaren mit einem registrierten Schlüssel-Namensraum bereitzustellen. Felder werden innerhalb der Header- und Trailer-Abschnitte von Nachrichten gesendet und empfangen (Abschnitt 6).
5.1. Feldnamen
Ein Feldname (Field Name) kennzeichnet den entsprechenden Feldwert als mit der durch diesen Namen definierten Semantik versehen. Beispielsweise ist das Date-Header-Feld in Abschnitt 6.6.1 als den Ursprungszeitstempel für die Nachricht enthaltend definiert, in der es erscheint.
field-name = token
Feldnamen sind nicht case-sensitiv und sollten im "Hypertext Transfer Protocol (HTTP) Field Name Registry" registriert werden; siehe Abschnitt 16.3.1.
Die Interpretation eines Feldes ändert sich nicht zwischen Minor-Versionen derselben Major-HTTP-Version, obwohl sich das Standardverhalten eines Empfängers in Abwesenheit eines solchen Feldes ändern kann. Sofern nicht anders angegeben, sind Felder für alle Versionen von HTTP definiert. Insbesondere sollten die Felder Host und Connection von allen HTTP-Implementierungen erkannt werden, unabhängig davon, ob sie die Konformität mit HTTP/1.1 ankündigen oder nicht.
Neue Felder können eingeführt werden, ohne die Protokollversion zu ändern, wenn ihre definierte Semantik es erlaubt, dass sie von Empfängern, die sie nicht erkennen, sicher ignoriert werden; siehe Abschnitt 16.3.
Ein Proxy MUSS nicht erkannte Header-Felder weiterleiten, es sei denn, der Feldname ist im Connection-Header-Feld (Abschnitt 7.6.1) aufgeführt oder der Proxy ist speziell konfiguriert, um solche Felder zu blockieren oder anderweitig zu transformieren. Andere Empfänger SOLLTEN nicht erkannte Header- und Trailer-Felder ignorieren. Die Einhaltung dieser Anforderungen ermöglicht es, die Funktionalität von HTTP zu erweitern, ohne bereitgestellte Intermediäre zu aktualisieren oder zu entfernen.
5.2. Feldzeilen und Kombinierter Feldwert
Feldabschnitte (Field Sections) bestehen aus einer beliebigen Anzahl von "Feldzeilen" (Field Lines), jede mit einem "Feldnamen" (siehe Abschnitt 5.1), der das Feld identifiziert, und einem "Feldzeilenwert" (Field Line Value), der Daten für diese Instanz des Feldes übermittelt.
Wenn ein Feldname nur einmal in einem Abschnitt vorhanden ist, besteht der kombinierte "Feldwert" (Field Value) für dieses Feld aus dem entsprechenden Feldzeilenwert. Wenn ein Feldname innerhalb eines Abschnitts wiederholt wird, besteht sein kombinierter Feldwert aus der Liste der entsprechenden Feldzeilenwerte innerhalb dieses Abschnitts, in der Reihenfolge verkettet, wobei jeder Feldzeilenwert durch ein Komma getrennt ist.
Zum Beispiel enthält dieser Abschnitt:
Example-Field: Foo, Bar
Example-Field: Baz
zwei Feldzeilen, beide mit dem Feldnamen "Example-Field". Die erste Feldzeile hat einen Feldzeilenwert von "Foo, Bar", während der zweite Feldzeilenwert "Baz" ist. Der Feldwert für "Example-Field" ist die Liste "Foo, Bar, Baz".
5.3. Feldreihenfolge
Ein Empfänger KANN mehrere Feldzeilen innerhalb eines Feldabschnitts, die denselben Feldnamen haben, zu einer Feldzeile kombinieren, ohne die Semantik der Nachricht zu ändern, indem jeder nachfolgende Feldzeilenwert in der Reihenfolge an den anfänglichen Feldzeilenwert angehängt wird, getrennt durch ein Komma (",") und optionale Leerzeichen (OWS, definiert in Abschnitt 5.6.3). Für Konsistenz verwenden Sie Komma SP.
Die Reihenfolge, in der Feldzeilen mit demselben Namen empfangen werden, ist daher bedeutsam für die Interpretation des Feldwerts; ein Proxy DARF NICHT die Reihenfolge dieser Feldzeilenwerte beim Weiterleiten einer Nachricht ändern.
Dies bedeutet, dass abgesehen von der unten erwähnten bekannten Ausnahme ein Sender NICHT mehrere Feldzeilen mit demselben Namen in einer Nachricht generieren DARF (weder in den Headern noch in den Trailern) oder eine Feldzeile anhängen DARF, wenn bereits eine Feldzeile mit demselben Namen in der Nachricht existiert, es sei denn, die Definition dieses Feldes erlaubt es, mehrere Feldzeilenwerte als kommagetrennte Liste zu rekombinieren (d.h. mindestens eine Alternative der Felddefinition erlaubt eine kommagetrennte Liste, wie z.B. eine ABNF-Regel von #(values), definiert in Abschnitt 5.6.1).
Hinweis: In der Praxis erscheint das "Set-Cookie"-Header-Feld ([COOKIE]) oft in einer Antwortnachricht über mehrere Feldzeilen hinweg und verwendet nicht die Listensyntax, was gegen die obigen Anforderungen an mehrere Feldzeilen mit demselben Feldnamen verstößt. Da es nicht zu einem einzigen Feldwert kombiniert werden kann, sollten Empfänger "Set-Cookie" als Sonderfall behandeln, während sie Felder verarbeiten. (Siehe Anhang A.2.3 von [Kri2001] für Details.)
Die Reihenfolge, in der Feldzeilen mit unterschiedlichen Feldnamen in einem Abschnitt empfangen werden, ist nicht signifikant. Es ist jedoch gute Praxis, Header-Felder, die zusätzliche Kontrolldaten enthalten, zuerst zu senden, wie Host bei Anfragen und Date bei Antworten, damit Implementierungen so früh wie möglich entscheiden können, eine Nachricht nicht zu verarbeiten.
Ein Server DARF NICHT eine Anfrage auf die Zielressource anwenden, bis er den gesamten Anfrage-Header-Abschnitt erhalten hat, da spätere Header-Feldzeilen Bedingungen, Authentifizierungsnachweise oder absichtlich irreführende doppelte Header-Felder enthalten können, die die Anfrageverarbeitung beeinflussen könnten.
5.4. Feldbegrenzungen
HTTP setzt keine vordefinierte Grenze für die Länge jeder Feldzeile, des Feldwerts oder für die Länge eines Header- oder Trailer-Abschnitts als Ganzes, wie in Abschnitt 2 beschrieben. Verschiedene Ad-hoc-Einschränkungen für individuelle Längen finden sich in der Praxis, oft abhängig von der Semantik des spezifischen Feldes.
Ein Server, der eine Anfrage-Header-Feldzeile, einen Feldwert oder ein Feldset empfängt, das größer ist als er verarbeiten möchte, MUSS mit einem entsprechenden 4xx (Client Error) Statuscode antworten. Das Ignorieren solcher Header-Felder würde die Anfälligkeit des Servers für Request-Smuggling-Angriffe erhöhen (Abschnitt 11.2 von [HTTP/1.1]).
Ein Client KANN empfangene Feldzeilen, die größer sind als der Client verarbeiten möchte, verwerfen oder kürzen, wenn die Feldsemantik derart ist, dass die verworfenen Werte sicher ignoriert werden können, ohne das Nachrichtenframing oder die Antwortsemantik zu ändern.
5.5. Feldwerte
HTTP-Feldwerte (Field Values) bestehen aus einer Zeichensequenz in einem durch die Feldgrammatik definierten Format. Die Grammatik jedes Feldes wird üblicherweise mit ABNF ([RFC5234]) definiert.
field-value = *field-content
field-content = field-vchar
[ 1*( SP / HTAB / field-vchar ) field-vchar ]
field-vchar = VCHAR / obs-text
obs-text = %x80-FF
Feldwerte enthalten keine führenden oder nachfolgenden Leerzeichen. Wenn eine bestimmte HTTP-Version erlaubt, dass solche Leerzeichen in einer Nachricht erscheinen, MUSS eine Feldanalyse-Implementierung solche Leerzeichen vor der Bewertung des Feldwerts ausschließen.
Feldwerte sind üblicherweise auf den Bereich von US-ASCII-Zeichen [USASCII] beschränkt. Felder, die einen größeren Zeichenbereich benötigen, können eine Kodierung verwenden, wie die in [RFC8187] definierte. Historisch hat HTTP Feldinhalte mit Text im ISO-8859-1-Zeichensatz [ISO-8859-1] erlaubt und andere Zeichensätze nur durch die Verwendung von [RFC2047]-Kodierung unterstützt. Spezifikationen für neu definierte Felder SOLLTEN ihre Werte auf sichtbare US-ASCII-Oktette (VCHAR), SP und HTAB beschränken. Ein Empfänger SOLLTE andere erlaubte Oktette im Feldinhalt (d.h. obs-text) als opake Daten behandeln.
Feldwerte, die CR-, LF- oder NUL-Zeichen enthalten, sind ungültig und gefährlich, da Implementierungen diese Zeichen auf verschiedene Weise parsen und interpretieren können; ein Empfänger von CR, LF oder NUL innerhalb eines Feldwerts MUSS entweder die Nachricht ablehnen oder jedes dieser Zeichen durch SP ersetzen, bevor die Nachricht weiter verarbeitet oder weitergeleitet wird. Feldwerte, die andere CTL-Zeichen enthalten, sind ebenfalls ungültig; Empfänger KÖNNEN solche Zeichen jedoch aus Gründen der Robustheit beibehalten, wenn sie in einem sicheren Kontext erscheinen (z.B. eine anwendungsspezifische zitierte Zeichenkette, die nicht von einem nachgelagerten HTTP-Parser verarbeitet wird).
Felder, die nur ein einzelnes Mitglied als Feldwert erwarten, werden als "Singleton-Felder" (Singleton Fields) bezeichnet.
Felder, die mehrere Mitglieder als Feldwert erlauben, werden als "listenbasierte Felder" (List-Based Fields) bezeichnet. Die Listenoperator-Erweiterung von Abschnitt 5.6.1 wird als gemeinsame Notation zur Definition von Feldwerten verwendet, die mehrere Mitglieder enthalten können.
Da Kommas (",") als Trennzeichen zwischen Mitgliedern verwendet werden, müssen sie sorgfältig behandelt werden, wenn sie als Daten innerhalb eines Mitglieds erlaubt sind. Dies gilt sowohl für listenbasierte als auch für Singleton-Felder, da ein Singleton-Feld fälschlicherweise mit mehreren Mitgliedern gesendet werden kann und das Erkennen solcher Fehler die Interoperabilität verbessert. Felder, die erwarten, ein Komma innerhalb eines Mitglieds zu enthalten, wie innerhalb eines HTTP-Datums- oder URI-Referenzelements, sollten Trennzeichen um dieses Element herum definieren, um jedes Komma innerhalb dieser Daten von potenziellen Listentrennzeichen zu unterscheiden.
Zum Beispiel könnten ein textuelles Datum und ein URI (beide können ein Komma enthalten) sicher in listenbasierten Feldwerten wie diesen transportiert werden:
Example-URIs: "http://example.com/a.html,foo",
"http://without-a-comma.example.com/"
Example-Dates: "Sat, 04 May 1996", "Wed, 14 Sep 2005"
Beachten Sie, dass doppelte Anführungszeichen-Trennzeichen fast immer mit der quoted-string-Produktion (Abschnitt 5.6.4) verwendet werden; die Verwendung einer anderen Syntax innerhalb doppelter Anführungszeichen wird wahrscheinlich unnötige Verwirrung verursachen.
Viele Felder (z.B. Content-Type, definiert in Abschnitt 8.3) verwenden eine gemeinsame Syntax für Parameter, die sowohl nicht zitierte (token) als auch zitierte (quoted-string) Syntax für einen Parameterwert erlaubt (Abschnitt 5.6.6). Die Verwendung gemeinsamer Syntax ermöglicht es Empfängern, bestehende Parser-Komponenten wiederzuverwenden. Wenn beide Formen erlaubt sind, sollte die Bedeutung eines Parameterwerts unabhängig von der Form sein, die zur Übermittlung dieses Werts verwendet wird.
Hinweis: Zur Definition der Feldwertsyntax verwendet diese Spezifikation eine ABNF-Regel, die nach dem Feldnamen benannt ist, um die zulässige Grammatik für den Wert dieses Feldes zu definieren (nachdem der Feldwert aus der zugrunde liegenden Messaging-Syntax extrahiert und mehrere Instanzen zu einer Liste kombiniert wurden).
5.6. Gemeinsame Regeln zur Definition von Feldwerten
5.6.1. Listen (#rule ABNF Extension)
Eine #rule-Erweiterung der ABNF-Regeln von [RFC5234] wird verwendet, um die Lesbarkeit in den Definitionen einiger listenbasierter Feldwerte zu verbessern.
Ein Konstrukt "#" wird definiert, ähnlich zu "*", zur Definition von kommagetrennten Listen von Elementen. Die vollständige Form ist "<n>#<m>element", die mindestens <n> und höchstens <m> Elemente anzeigt, jedes getrennt durch ein einzelnes Komma (",") und optionale Leerzeichen (OWS, definiert in Abschnitt 5.6.3).
5.6.1.1. Sender-Anforderungen
In jeder Produktion, die das Listenkonstrukt verwendet, DARF ein Sender KEINE leeren Listenelemente generieren. Mit anderen Worten, ein Sender muss Listen generieren, die die folgende Syntax erfüllen:
1#element => element *( OWS "," OWS element )
und:
#element => [ 1#element ]
und für n >= 1 und m > 1:
<n>#<m>element => element <n-1>*<m-1>( OWS "," OWS element )
Anhang A zeigt das gesammelte ABNF für Sender, nachdem die Listenkonstrukte erweitert wurden.
5.6.1.2. Empfänger-Anforderungen
Leere Elemente tragen nicht zur Anzahl der vorhandenen Elemente bei. Ein Empfänger MUSS eine vernünftige Anzahl leerer Listenelemente parsen und ignorieren: genug, um gängige Fehler von Sendern zu behandeln, die Werte zusammenführen, aber nicht so viel, dass sie als Denial-of-Service-Mechanismus verwendet werden können. Mit anderen Worten, ein Empfänger MUSS Listen akzeptieren, die die folgende Syntax erfüllen:
#element => [ element ] *( OWS "," OWS [ element ] )
Beachten Sie, dass aufgrund der potenziellen Anwesenheit leerer Listenelemente das RFC 5234 ABNF die Kardinalität von Listenelementen nicht durchsetzen kann, und daher werden alle Fälle so abgebildet, als ob keine Kardinalität angegeben wäre.
Zum Beispiel, gegeben diese ABNF-Produktionen:
example-list = 1#example-list-elmt
example-list-elmt = token ; siehe Abschnitt 5.6.2
Dann sind die folgenden gültige Werte für example-list (ohne die doppelten Anführungszeichen, die nur zur Abgrenzung vorhanden sind):
"foo,bar"
"foo ,bar,"
"foo , ,bar,charlie"
Im Gegensatz dazu wären die folgenden ungültig, da die example-list-Produktion mindestens ein nicht-leeres Element erfordert:
""
","
", ,"
5.6.2. Tokens
Tokens sind kurze textuelle Identifikatoren, die keine Leerzeichen oder Trennzeichen enthalten.
token = 1*tchar
tchar = "!" / "#" / "$" / "%" / "&" / "'" / "*"
/ "+" / "-" / "." / "^" / "_" / "`" / "|" / "~"
/ DIGIT / ALPHA
; jedes VCHAR außer Trennzeichen
Viele HTTP-Feldwerte werden unter Verwendung gemeinsamer Syntaxkomponenten definiert, die durch Leerzeichen oder spezifische Trennzeichen getrennt sind. Trennzeichen werden aus dem Satz von US-ASCII-sichtbaren Zeichen ausgewählt, die in einem Token nicht erlaubt sind (DQUOTE und "(),/:;<=>?@[\]{}").
5.6.3. Leerzeichen
Diese Spezifikation verwendet drei Regeln zur Bezeichnung der Verwendung linearer Leerzeichen: OWS (optionale Leerzeichen, Optional Whitespace), RWS (erforderliche Leerzeichen, Required Whitespace) und BWS ("schlechte" Leerzeichen, "Bad" Whitespace).
Die OWS-Regel wird verwendet, wo null oder mehr lineare Leerzeichen-Oktette erscheinen können. Für Protokollelemente, bei denen optionale Leerzeichen bevorzugt werden, um die Lesbarkeit zu verbessern, SOLLTE ein Sender die optionalen Leerzeichen als einzelnes SP generieren; andernfalls SOLLTE ein Sender keine optionalen Leerzeichen generieren, außer wenn sie während der In-Place-Nachrichtenfilterung zum Filtern ungültiger oder unerwünschter Protokollelemente benötigt werden.
Die RWS-Regel wird verwendet, wenn mindestens ein lineares Leerzeichen-Oktett erforderlich ist, um Feld-Tokens zu trennen. Ein Sender SOLLTE RWS als einzelnes SP generieren.
Die OWS- und RWS-Regeln haben dieselbe Semantik wie ein einzelnes SP. Jeder Inhalt, der als OWS oder RWS definiert ist, KANN durch ein einzelnes SP ersetzt werden, bevor er interpretiert oder die Nachricht nachgelagert weitergeleitet wird.
Die BWS-Regel wird verwendet, wo die Grammatik optionale Leerzeichen nur aus historischen Gründen erlaubt. Ein Sender DARF NICHT BWS in Nachrichten generieren. Ein Empfänger MUSS solche schlechten Leerzeichen parsen und vor der Interpretation des Protokollelements entfernen.
BWS hat keine Semantik. Jeder Inhalt, der als BWS definiert ist, KANN entfernt werden, bevor er interpretiert oder die Nachricht nachgelagert weitergeleitet wird.
OWS = *( SP / HTAB )
; optionale Leerzeichen
RWS = 1*( SP / HTAB )
; erforderliche Leerzeichen
BWS = OWS
; "schlechte" Leerzeichen
5.6.4. Zitierte Zeichenketten
Eine Textzeichenkette wird als einzelner Wert geparst, wenn sie mit doppelten Anführungszeichen zitiert wird.
quoted-string = DQUOTE *( qdtext / quoted-pair ) DQUOTE
qdtext = HTAB / SP / %x21 / %x23-5B / %x5D-7E / obs-text
Das Backslash-Oktett ("") kann als Einzel-Oktett-Zitierungsmechanismus innerhalb von quoted-string- und comment-Konstrukten verwendet werden. Empfänger, die den Wert einer quoted-string verarbeiten, MÜSSEN ein quoted-pair behandeln, als ob es durch das Oktett, das dem Backslash folgt, ersetzt würde.
quoted-pair = "\" ( HTAB / SP / VCHAR / obs-text )
Ein Sender SOLLTE NICHT ein quoted-pair in einer quoted-string generieren, außer wo es notwendig ist, DQUOTE- und Backslash-Oktette zu zitieren, die in dieser Zeichenkette vorkommen. Ein Sender SOLLTE NICHT ein quoted-pair in einem Kommentar generieren, außer wo es notwendig ist, Klammern ["(" und ")"] und Backslash-Oktette zu zitieren, die in diesem Kommentar vorkommen.
5.6.5. Kommentare
Kommentare können in einige HTTP-Felder eingefügt werden, indem der Kommentartext mit Klammern umgeben wird. Kommentare sind nur in Feldern erlaubt, die "comment" als Teil ihrer Feldwert-Definition enthalten.
comment = "(" *( ctext / quoted-pair / comment ) ")"
ctext = HTAB / SP / %x21-27 / %x2A-5B / %x5D-7E / obs-text
5.6.6. Parameter
Parameter (Parameters) sind Instanzen von Name/Wert-Paaren; sie werden oft in Feldwerten als gemeinsame Syntax zum Anhängen von Zusatzinformationen an ein Element verwendet. Jeder Parameter wird üblicherweise durch ein unmittelbar vorangehendes Semikolon getrennt.
parameters = *( OWS ";" OWS [ parameter ] )
parameter = parameter-name "=" parameter-value
parameter-name = token
parameter-value = ( token / quoted-string )
Parameternamen sind nicht case-sensitiv. Parameterwerte können case-sensitiv oder nicht case-sensitiv sein, abhängig von der Semantik des Parameternamens. Beispiele für Parameter und einige äquivalente Formen können in Medientypen (Abschnitt 8.3.1) und dem Accept-Header-Feld (Abschnitt 12.5.1) gesehen werden.
Ein Parameterwert, der mit der token-Produktion übereinstimmt, kann entweder als token oder innerhalb einer quoted-string übertragen werden. Die zitierten und nicht zitierten Werte sind äquivalent.
Hinweis: Parameter erlauben keine Leerzeichen (nicht einmal "schlechte" Leerzeichen) um das "="-Zeichen herum.
5.6.7. Datums-/Zeitformate
Vor 1995 gab es drei verschiedene Formate, die üblicherweise von Servern zur Kommunikation von Zeitstempeln verwendet wurden. Der Kompatibilität mit alten Implementierungen wegen werden hier alle drei definiert. Das bevorzugte Format ist eine Teilmenge mit fester Länge und einzelner Zeitzone der Datums- und Zeitspezifikation, die vom Internet Message Format [RFC5322] verwendet wird.
HTTP-date = IMF-fixdate / obs-date
Ein Beispiel des bevorzugten Formats ist
Sun, 06 Nov 1994 08:49:37 GMT ; IMF-fixdate
Beispiele der zwei veralteten Formate sind
Sunday, 06-Nov-94 08:49:37 GMT ; veraltetes RFC 850-Format
Sun Nov 6 08:49:37 1994 ; ANSI C's asctime()-Format
Ein Empfänger, der einen Zeitstempelwert in einem HTTP-Feld parst, MUSS alle drei HTTP-date-Formate akzeptieren. Wenn ein Sender ein Feld generiert, das einen oder mehrere als HTTP-date definierte Zeitstempel enthält, MUSS der Sender diese Zeitstempel im IMF-fixdate-Format generieren.
Ein HTTP-date-Wert repräsentiert Zeit als Instanz der Koordinierten Weltzeit (Coordinated Universal Time, UTC). Die ersten beiden Formate zeigen UTC durch die dreistellige Abkürzung für Greenwich Mean Time, "GMT", einem Vorgänger des UTC-Namens, an; Werte im asctime-Format werden als in UTC angenommen.
Eine "Uhr" (Clock) ist eine Implementierung, die eine vernünftige Näherung des aktuellen Moments in UTC liefern kann. Eine Uhr-Implementierung sollte NTP ([RFC5905]) oder ein ähnliches Protokoll verwenden, um sich mit UTC zu synchronisieren.
Bevorzugtes Format:
IMF-fixdate = day-name "," SP date1 SP time-of-day SP GMT
; Teilmenge mit fester Länge/Zone/Großschreibung des Formats
; siehe Abschnitt 3.3 von [RFC5322]
day-name = %s"Mon" / %s"Tue" / %s"Wed"
/ %s"Thu" / %s"Fri" / %s"Sat" / %s"Sun"
date1 = day SP month SP year
; z.B., 02 Jun 1982
day = 2DIGIT
month = %s"Jan" / %s"Feb" / %s"Mar" / %s"Apr"
/ %s"May" / %s"Jun" / %s"Jul" / %s"Aug"
/ %s"Sep" / %s"Oct" / %s"Nov" / %s"Dec"
year = 4DIGIT
GMT = %s"GMT"
time-of-day = hour ":" minute ":" second
; 00:00:00 - 23:59:60 (Schaltsekunde)
hour = 2DIGIT
minute = 2DIGIT
second = 2DIGIT
Veraltete Formate:
obs-date = rfc850-date / asctime-date
rfc850-date = day-name-l "," SP date2 SP time-of-day SP GMT
date2 = day "-" month "-" 2DIGIT
; z.B., 02-Jun-82
day-name-l = %s"Monday" / %s"Tuesday" / %s"Wednesday"
/ %s"Thursday" / %s"Friday" / %s"Saturday"
/ %s"Sunday"
asctime-date = day-name SP date3 SP time-of-day SP year
date3 = month SP ( 2DIGIT / ( SP 1DIGIT ))
; z.B., Jun 2
HTTP-date ist case-sensitiv. Beachten Sie, dass Abschnitt 4.2 von [CACHING] dies für Cache-Empfänger lockert.
Ein Sender DARF NICHT zusätzliche Leerzeichen in einem HTTP-date über das hinaus generieren, was ausdrücklich als SP in der Grammatik enthalten ist. Die Semantik von day-name, day, month, year und time-of-day ist dieselbe wie die für die Internet Message Format-Konstrukte mit dem entsprechenden Namen definierten ([RFC5322], Abschnitt 3.3).
Empfänger eines Zeitstempelwerts im rfc850-date-Format, das ein zweistelliges Jahr verwendet, MÜSSEN einen Zeitstempel, der mehr als 50 Jahre in der Zukunft zu liegen scheint, als das jüngste Jahr in der Vergangenheit interpretieren, das dieselben letzten zwei Ziffern hatte.
Empfänger von Zeitstempelwerten werden ermutigt, beim Parsen von Zeitstempeln robust zu sein, sofern nicht durch die Felddefinition anders eingeschränkt. Zum Beispiel werden Nachrichten gelegentlich über HTTP von einer Nicht-HTTP-Quelle weitergeleitet, die eine beliebige der durch das Internet Message Format definierten Datums- und Zeitspezifikationen generieren könnte.
Hinweis: HTTP-Anforderungen für das Datums-/Zeitstempelformat gelten nur für deren Verwendung im Protokollstream. Implementierungen sind nicht verpflichtet, diese Formate für Benutzerpräsentation, Anforderungsprotokollierung usw. zu verwenden.