4. HTTP Message (HTTP-Nachricht)
4.1 Message Types (Nachrichtentypen)
HTTP-Nachrichten bestehen aus Anfragen (request) vom Client an den Server und Antworten (response) vom Server an den Client.
HTTP-message = Request | Response ; HTTP/1.1 messages
Anfrage- (Abschnitt 5) und Antwortnachrichten (Abschnitt 6) verwenden das generische Nachrichtenformat von RFC 822 [9], um Entitäten (entity) (die Nutzlast der Nachricht) zu übertragen. Beide Nachrichtentypen bestehen aus einer Startzeile (start line), null oder mehr Header-Feldern (header field) (auch "headers" genannt), einer Leerzeile, die das Ende der Header-Felder anzeigt (d.h. eine Zeile mit nichts vor dem CRLF), und möglicherweise einem Nachrichtenkörper (message body).
generic-message = start-line
*(message-header CRLF)
CRLF
[ message-body ]
start-line = Request-Line | Status-Line
Für Robustheit sollten (SHOULD) Server jede Leerzeile ignorieren, die an der Stelle empfangen wird, an der eine Request-Line erwartet wird. Mit anderen Worten, wenn der Server den Protokollstrom zu Beginn einer Nachricht liest und zuerst ein CRLF empfängt, sollte er dieses CRLF ignorieren.
Einige fehlerhafte HTTP/1.0-Client-Implementierungen erzeugen zusätzliche CRLFs nach POST-Anfragen. Um zu wiederholen, was das BNF ausdrücklich verbietet: HTTP/1.1-Clients dürfen (MUST NOT) zusätzliche CRLFs vor oder nach Anfragen hinzufügen.
4.2 Message Headers (Nachrichten-Header)
HTTP-Header-Felder, einschließlich der Felder für allgemeine Header (general-header) (Abschnitt 4.5), Anfrage-Header (request-header) (Abschnitt 5.3), Antwort-Header (response-header) (Abschnitt 6.2) und Entitäts-Header (entity-header) (Abschnitt 7.1), folgen demselben generischen Format wie in Abschnitt 3.1 von RFC 822 [9] angegeben. Jedes Header-Feld besteht aus einem Namen, gefolgt von einem Doppelpunkt (":") und dem Feldwert. Feldnamen sind case-insensitive. Dem Feldwert kann (MAY) eine beliebige Anzahl von LWS vorangestellt werden, obwohl ein einzelnes SP bevorzugt wird. Header-Felder können über mehrere Zeilen erweitert werden, indem jeder zusätzlichen Zeile mindestens ein SP oder HT vorangestellt wird. Anwendungen sollten (ought to) bei der Erzeugung von HTTP-Konstrukten der "gemeinsamen Form" (common form) folgen, wenn sie bekannt oder angegeben ist, da möglicherweise Implementierungen existieren, die nichts über die gemeinsame Form hinaus akzeptieren können.
message-header = field-name ":" [ field-value ]
field-name = token
field-value = *( field-content | LWS )
field-content = <the OCTETs making up the field-value
and consisting of either *TEXT or combinations
of token, separators, and quoted-string>
field-content enthält keine führenden oder nachfolgenden LWS: lineares Leerzeichen, das vor dem ersten Nicht-Leerzeichen von field-value oder nach dem letzten Nicht-Leerzeichen von field-value erscheint. Solche führenden oder nachfolgenden LWS können (MAY) entfernt werden, ohne die Semantik des Feldwerts zu ändern. Jedes LWS, das zwischen field-content erscheint, kann (MAY) durch ein einzelnes SP ersetzt werden, bevor der Feldwert interpretiert oder die Nachricht downstream weitergeleitet wird.
Die Reihenfolge, in der Header-Felder mit unterschiedlichen Feldnamen empfangen werden, ist nicht wichtig. Es ist jedoch "gute Praxis" (good practice), zuerst allgemeine Header-Felder zu senden, dann Anfrage- oder Antwort-Header-Felder und schließlich Entitäts-Header-Felder.
Mehrere message-header-Felder mit demselben field-name können (MAY) in einer Nachricht vorhanden sein, wenn und nur wenn der gesamte field-value für dieses Header-Feld als kommagetrennte Liste [d.h. #(values)] definiert ist. Es muss (MUST) möglich sein, mehrere Header-Felder zu einem einzigen "field-name: field-value"-Paar zu kombinieren, ohne die Semantik der Nachricht zu ändern, indem jeder nachfolgende field-value an den ersten angefügt wird, jeweils durch ein Komma getrennt. Die Reihenfolge, in der Header-Felder mit demselben field-name empfangen werden, ist daher wichtig für die Interpretation des kombinierten Feldwerts, und daher darf (MUST NOT) ein Proxy die Reihenfolge dieser Feldwerte beim Weiterleiten einer Nachricht nicht ändern.
4.3 Message Body (Nachrichtenkörper)
Der message-body einer HTTP-Nachricht wird, falls vorhanden, verwendet, um den mit der Anfrage oder Antwort verbundenen entity-body zu transportieren. Der message-body unterscheidet sich vom entity-body nur dann, wenn eine Übertragungskodierung (transfer-coding) angewendet wurde, wie durch das Transfer-Encoding-Header-Feld (Abschnitt 14.41) angegeben.
message-body = entity-body
| <entity-body encoded as per Transfer-Encoding>
Transfer-Encoding muss (MUST) verwendet werden, um jede Übertragungskodierung anzuzeigen, die von einer Anwendung angewendet wurde, um eine sichere und ordnungsgemäße Übertragung der Nachricht zu gewährleisten. Transfer-Encoding ist eine Eigenschaft der Nachricht und nicht der Entität und kann (MAY) daher von jeder vermittelnden Anwendung hinzugefügt oder entfernt werden.
Wenn ein message-body in einer Nachricht vorhanden ist, wird die Übertragungslänge (transfer-length) dieses message-body durch die in Abschnitt 4.4 definierten Regeln bestimmt.
4.4 Message Length (Nachrichtenlänge)
Die Übertragungslänge einer Nachricht ist die Länge des message-body, wie er in der Übertragung erscheint. Wenn ein message-body in einer Nachricht vorhanden ist, wird die Übertragungslänge dieses Körpers durch eines der folgenden Elemente bestimmt (in der Reihenfolge der Priorität):
-
Jede Antwortnachricht, die keinen (MUST NOT) message-body enthalten darf (wie 1xx-, 204- und 304-Antworten und jede Antwort auf eine HEAD-Anfrage), wird immer durch die erste Leerzeile nach den Header-Feldern beendet, unabhängig davon, welche Entitäts-Header-Felder in der Nachricht vorhanden sind.
-
Wenn ein Transfer-Encoding-Header-Feld vorhanden ist und nicht "identity" ist, wird die Übertragungslänge durch die "chunked"-Übertragungskodierung definiert, es sei denn, die Nachricht wird durch das Schließen der Verbindung beendet.
-
Wenn ein Content-Length-Header-Feld (Abschnitt 14.13) vorhanden ist, repräsentiert sein Dezimalwert in Oktetten sowohl die Entity-Length als auch die transfer-length. Wenn diese beiden Längen unterschiedlich sind (d.h. wenn ein Transfer-Encoding-Header-Feld vorhanden ist), darf (MUST NOT) das Content-Length-Header-Feld nicht gesendet werden. (Hinweis: Einige ältere Implementierungen sendeten fälschlicherweise Content-Length mit einem non-identity Transfer-Encoding.)
-
Wenn die Nachricht den Medientyp "multipart/byteranges" verwendet und die transfer-length nicht anderweitig angegeben ist, definiert dieser selbstabgrenzende (self-delimiting) Medientyp die transfer-length. Dieser Medientyp darf (MUST NOT) verwendet werden, es sei denn, der Absender weiß, dass der Empfänger ihn analysieren kann; das Vorhandensein eines Range-Header-Felds bei einem Empfänger zeigt an, dass der Client multipart/byteranges-Antworten analysieren kann.
Ein Range-Header-Feld könnte von einem HTTP/1.0-Proxy weitergeleitet werden, der multipart/byteranges nicht versteht; in diesem Fall muss (MUST) der Server die Nachricht mit einem Content-Range-Feld abgrenzen.
-
Durch das Schließen der Verbindung durch den Server. (Das Schließen der Verbindung kann nicht verwendet werden, um das Ende eines Anfragekörpers anzuzeigen, da dies den Server daran hindern würde, eine Antwort zurückzusenden.)
Für die Kompatibilität mit HTTP/1.0-Anwendungen müssen (MUST) HTTP/1.1-Anfragen, die einen message-body enthalten, ein gültiges Content-Length-Header-Feld enthalten, es sei denn, es ist bekannt, dass der Server HTTP/1.1-konform ist. Wenn eine Anfrage einen message-body enthält und kein Content-Length enthält, sollte (SHOULD) der Server mit 400 (bad request) antworten, wenn er die Länge der Nachricht nicht bestimmen kann, oder mit 411 (length required), wenn er darauf besteht, ein gültiges Content-Length zu erhalten.
Alle HTTP/1.1-Anwendungen müssen (MUST) den "chunked"-transfer-coding in Anfragenachrichten akzeptieren, auch wenn die Anwendung selbst keine gechunkten Nachrichten sendet. Wenn eine HTTP/1.1-Anfrage einen message-body enthält, aber kein Content-Length, sollte (SHOULD) der Server mit 400 (bad request) antworten, wenn er die Länge der Anfrage nicht bestimmen kann, oder mit 411 (length required), wenn er darauf besteht, ein gültiges Content-Length zu erhalten.
Wenn eine Anfrage einen message-body enthält und kein Content-Length angegeben ist, sollte (SHOULD) der Server mit 400 (bad request) antworten, wenn er die Länge der Nachricht nicht bestimmen kann, oder mit 411 (length required), wenn er darauf besteht, ein gültiges Content-Length zu erhalten.
Eine Nachricht sollte (SHOULD NOT) sowohl ein Transfer-Encoding- als auch ein Content-Length-Header-Feld enthalten. Wenn eine Nachricht beide enthält, muss (MUST) Transfer-Encoding Content-Length entfernen.
Wenn eine inhaltskodierte Entität empfangen und analysiert wird, wird die message-body-Länge durch die dekodierten Daten bestimmt, wenn die Inhaltskodierung bekannt ist.
4.5 General Header Fields (Allgemeine Header-Felder)
Es gibt einige Header-Felder, die allgemeine Anwendbarkeit für Anfrage- und Antwortnachrichten haben, aber nicht auf die übertragene Entität anwendbar sind. Diese Header-Felder gelten nur für die übertragene Nachricht.
general-header = Cache-Control ; Section 14.9
| Connection ; Section 14.10
| Date ; Section 14.18
| Pragma ; Section 14.32
| Trailer ; Section 14.40
| Transfer-Encoding ; Section 14.41
| Upgrade ; Section 14.42
| Via ; Section 14.45
| Warning ; Section 14.46
Allgemeine Header-Feldnamen können nur durch Ändern der Protokollversion zuverlässig erweitert werden. Neue oder experimentelle Header-Felder können jedoch Feldwerten zugewiesen werden, ohne die Protokollversion zu ändern. Abschnitt 7.1 definiert die Semantik von Entitäts-Header-Feldern.
Nicht erkannte Header-Felder sollten (SHOULD) vom Empfänger als Entitäts-Header-Felder behandelt werden.