extended over multiple lines by preceding each extra line with at
least one SP or HT. Applications SHOULD follow "common form" when
generating HTTP constructs, since there might exist some
implementations that fail to accept anything beyond the common forms.
message-header = field-name ":" [ field-value ] CRLF
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, tspecials, and quoted-string>
The order in which header fields with differing field names are
received is not significant. However, it is "good practice" to send
general-header fields first, followed by request-header or response-
header fields, and ending with the entity-header fields.
Multiple message-header fields with the same field-name may be
present in a message if and only if the entire field-value for that
header field is defined as a comma-separated list [i.e., #(values)].
It MUST be possible to combine the multiple header fields into one
"field-name: field-value" pair, without changing the semantics of the
message, by appending each subsequent field-value to the first, each
separated by a comma. The order in which header fields with the same
field-name are received is therefore significant to the
interpretation of the combined field value, and thus a proxy MUST NOT
change the order of these field values when a message is forwarded.
RFC 2068 HTTP/1.1 January 1997
4.3 Message Body
The message-body (if any) of an HTTP message is used to carry the
entity-body associated with the request or response. The message-body
differs from the entity-body only when a transfer coding has been
applied, as indicated by the Transfer-Encoding header field (section
14.40).
message-body = entity-body
| <entity-body encoded as per Transfer-Encoding>
Transfer-Encoding MUST be used to indicate any transfer codings
applied by an application to ensure safe and proper transfer of the
message. Transfer-Encoding is a property of the message, not of the
entity, and thus can be added or removed by any application along the
request/response chain.
The rules for when a message-body is allowed in a message differ for
requests and responses.
The presence of a message-body in a request is signaled by the
inclusion of a Content-Length or Transfer-Encoding header field in
the request's message-headers. A message-body MAY be included in a
request only when the request method (section 5.1.1) allows an
entity-body.
For response messages, whether or not a message-body is included with
a message is dependent on both the request method and the response
status code (section 6.1.1). All responses to the HEAD request method
MUST NOT include a message-body, even though the presence of entity-
header fields might lead one to believe they do. All 1xx
(informational), 204 (no content), and 304 (not modified) responses
MUST NOT include a message-body. All other responses do include a
message-body, although it may be of zero length.
4.4 Message Length
When a message-body is included with a message, the length of that
body is determined by one of the following (in order of precedence):
1. Any response message which MUST NOT include a message-body
(such as the 1xx, 204, and 304 responses and any response to a HEAD
request) is always terminated by the first empty line after the
header fields, regardless of the entity-header fields present in the
message.
2. If a Transfer-Encoding header field (section 14.40) is present and
indicates that the "chunked" transfer coding has been applied, then
RFC 2068 HTTP/1.1 January 1997
the length is defined by the chunked encoding (section 3.6).
=18= |