Zum Hauptinhalt springen

3. Message Format (Nachrichtenformat)

Alle HTTP-Nachrichten bestehen aus einer Startzeile, gefolgt von einer Byte-Sequenz mit einer Syntax ähnlich dem Internet Message Format [RFC5322]: null oder mehr Header-Felder (kollektiv als "Header" oder "Header-Abschnitt" bezeichnet), eine Leerzeile, die das Ende des Header-Abschnitts anzeigt, und ein optionaler Nachrichtenkörper.

HTTP-message   = start-line
                 *( header-field CRLF )
                 CRLF
                 [ message-body ]

3.1. Start Line (Startzeile)​

Eine HTTP-Nachricht beginnt mit einer Startzeile (start-line).

start-line     = request-line / status-line

3.1.1. Request Line (Anfrage zeile)​

Eine Anfragezeile (request-line) beginnt mit einem Methoden-Token, gefolgt von einem Anfrageziel, einer Protokollversion und endet mit CRLF.

request-line   = method SP request-target SP HTTP-version CRLF
method         = token

3.1.2. Status Line (Statuszeile)​

Die erste Zeile einer Antwortnachricht ist die Statuszeile (status-line), bestehend aus der Protokollversion, einem Leerzeichen, einem Statuscode, einem weiteren Leerzeichen, einer möglicherweise leeren Begründungsphrase und endend mit CRLF.

status-line = HTTP-version SP status-code SP reason-phrase CRLF
status-code = 3DIGIT
reason-phrase  = *( HTAB / SP / VCHAR / obs-text )

3.2. Header Fields (Header-Felder)​

Jedes Header-Feld besteht aus einem case-insensitiven Feldnamen, gefolgt von einem Doppelpunkt (":"), optionalem Whitespace, dem Feldwert und optionalem Whitespace.

header-field   = field-name ":" OWS field-value OWS
field-name     = token
field-value    = *( field-content / obs-fold )
field-content  = field-vchar [ 1*( SP / HTAB ) field-vchar ]
field-vchar    = VCHAR / obs-text
obs-fold       = CRLF 1*( SP / HTAB )

3.2.1. Field Extensibility (Felderweiterbarkeit)​

Header-Felder sind vollständig erweiterbar: Es gibt keine Begrenzung für die Anzahl der Header-Felder, die in einer Nachricht verwendet werden können.

3.2.2. Field Order (Feldreihenfolge)​

Die Reihenfolge, in der Header-Felder mit unterschiedlichen Feldnamen empfangen werden, ist nicht signifikant.

3.2.3. Whitespace (Leerzeichen)​

Optionales Whitespace (OWS) wird nur verwendet, um die Lesbarkeit zu verbessern.

OWS            = *( SP / HTAB )
RWS            = 1*( SP / HTAB )
BWS            = OWS

3.2.4. Field Parsing (Feld-Parsing)​

Nachrichten werden mit einem allgemeinen Ansatz geparst, der unabhängig von einzelnen Feldnamen ist.

3.2.5. Field Limits (Feldbegrenzungen)​

HTTP-Implementierungen legen keine vordefinierten Grenzen für die Länge jedes Header-Felds oder auf die Länge des Header-Abschnitts als Ganzes fest.

3.2.6. Field Value Components (Feldwertkomponenten)​

Die meisten HTTP-Header-Feldwerte werden mithilfe einer gemeinsamen Grammatik von Feldwerttypen definiert.

token          = 1*tchar
tchar          = "!" / "#" / "$" / "%" / "&" / "'" / "*"
               / "+" / "-" / "." / "0"-"9" / "A"-"Z" / "^" / "_"
               / "`" / "a"-"z" / "|" / "~"
quoted-string  = DQUOTE *( qdtext / quoted-pair ) DQUOTE
qdtext         = HTAB / SP / "!" / %x23-5B / %x5D-7E / obs-text
quoted-pair    = "\" ( HTAB / SP / VCHAR / obs-text )
comment        = "(" *( ctext / quoted-pair / comment ) ")"
ctext          = HTAB / SP / %x21-27 / %x2A-5B / %x5D-7E / obs-text

3.3. Message Body (Nachrichtenkörper)​

Der Nachrichtenkörper (message-body, falls vorhanden) einer HTTP-Nachricht wird verwendet, um die Nutzlast (Payload) der Nachricht zu übertragen.

message-body = *OCTET

3.3.1. Transfer-Encoding​

Der Transfer-Encoding-Header listet die Transferkodierungsnamen auf, die der Sequenz von Transferkodierungen entsprechen, die auf die Nutzlast angewendet wurden (oder werden), um den Nachrichtenkörper zu bilden.

Transfer-Encoding = 1#transfer-coding

Ein Server MUSS einen Statuscode 400 (Bad Request, Ungültige Anfrage) für jede empfangene Anfrage generieren, die sowohl einen Content-Length- als auch einen Transfer-Encoding-Header enthält.

3.3.2. Content-Length​

Der Content-Length-Header gibt die erwartete Länge des Nachrichtenkörpers in Oktetten an.

Content-Length = 1*DIGIT

3.3.3. Message Body Length (Nachrichtenkörperlänge)​

Die Länge eines Nachrichtenkörpers wird durch eines der folgenden Elemente bestimmt (in Prioritätsreihenfolge):

  1. Jede Antwort auf eine HEAD-Anfrage und jede Antwort mit einem Statuscode 1xx (Informational, Informativ), 204 (No Content, Kein Inhalt) oder 304 (Not Modified, Nicht Geändert) wird immer durch die erste Leerzeile nach den Header-Feldern beendet.

  2. Wenn ein Transfer-Encoding-Header vorhanden ist und der chunked-Transferkodierungswert der Endwert ist, dann besteht der Nachrichtenkörper aus einem oder mehreren Chunks.

  3. Wenn ein Content-Length-Header vorhanden ist, repräsentiert sein Dezimalwert in Oktetten sowohl die Nutzlastlänge als auch die Nachrichtenkörperlänge.

  4. Wenn die Nachricht die "multipart/byteranges"-Transferkodierung verwendet und der Content-Length-Header nicht anders angegeben ist, dann definiert dieser selbst-delimierende Medientyp die Nachrichtenkörperlänge.

  5. Durch Schließen der Verbindung durch den Server.

3.4. Handling Incomplete Messages (Behandlung unvollständiger Nachrichten)​

Ein Server, der eine unvollständige Anfragenachricht erhält, normalerweise aufgrund einer vorzeitig geschlossenen Verbindung, MUSS mit einem Statuscode 400 (Bad Request, Ungültige Anfrage) antworten.

3.5. Message Parsing Robustness (Robustheit des Nachrichten-Parsings)​

Obwohl die Anforderungen dieses Dokuments in Begriffen strenger Konformität ausgedrückt werden, werden Implementierungen ermutigt, beim Parsing tolerant zu sein.

Letztes Update am