You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
242 lines
12 KiB
242 lines
12 KiB
<!DOCTYPE html
|
|
PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
|
|
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
|
|
<html xmlns='http://www.w3.org/1999/xhtml'>
|
|
<head><title>HTTP/1.1: HTTP Message</title></head>
|
|
<body><address>part of <a rev='Section' href='rfc2616.html'>Hypertext Transfer Protocol -- HTTP/1.1</a><br />
|
|
RFC 2616 Fielding, et al.</address>
|
|
<h2><a id='sec4'>4</a> HTTP Message</h2>
|
|
<h3><a id='sec4.1'>4.1</a> Message Types</h3>
|
|
<p>
|
|
HTTP messages consist of requests from client to server and responses
|
|
from server to client.
|
|
</p>
|
|
<pre> HTTP-message = Request | Response ; HTTP/1.1 messages
|
|
</pre>
|
|
<p>
|
|
Request (section 5) and Response (section 6) messages use the generic
|
|
message format of RFC 822 [9] for transferring entities (the payload
|
|
of the message). Both types of message consist of a start-line, zero
|
|
or more header fields (also known as "headers"), an empty line (i.e.,
|
|
a line with nothing preceding the CRLF) indicating the end of the
|
|
header fields, and possibly a message-body.
|
|
</p>
|
|
<pre> generic-message = start-line
|
|
*(message-header CRLF)
|
|
CRLF
|
|
[ message-body ]
|
|
start-line = Request-Line | Status-Line
|
|
</pre>
|
|
<p>
|
|
In the interest of robustness, servers SHOULD ignore any empty
|
|
line(s) received where a Request-Line is expected. In other words, if
|
|
the server is reading the protocol stream at the beginning of a
|
|
message and receives a CRLF first, it should ignore the CRLF.
|
|
</p>
|
|
<p>
|
|
Certain buggy HTTP/1.0 client implementations generate extra CRLF's
|
|
after a POST request. To restate what is explicitly forbidden by the
|
|
BNF, an HTTP/1.1 client MUST NOT preface or follow a request with an
|
|
extra CRLF.
|
|
</p>
|
|
<h3><a id='sec4.2'>4.2</a> Message Headers</h3>
|
|
<p>
|
|
HTTP header fields, which include general-header (section <a rel='xref' href='rfc2616-sec4.html#sec4.5'>4.5</a>),
|
|
request-header (section 5.3), response-header (section 6.2), and
|
|
entity-header (section <a rel='xref' href='rfc2616-sec7.html#sec7.1'>7.1</a>) fields, follow the same generic format as
|
|
that given in Section <a rel='xref' href='rfc2616-sec3.html#sec3.1'>3.1</a> of RFC 822 <a rel='bibref' href='rfc2616-sec17.html#bib9'>[9]</a>. Each header field consists
|
|
of a name followed by a colon (":") and the field value. Field names
|
|
are case-insensitive. The field value MAY be preceded by any amount
|
|
of LWS, though a single SP is preferred. Header fields can be
|
|
extended over multiple lines by preceding each extra line with at
|
|
least one SP or HT. Applications ought to follow "common form", where
|
|
one is known or indicated, when generating HTTP constructs, since
|
|
there might exist some implementations that fail to accept anything
|
|
</p>
|
|
<p>
|
|
beyond the common forms.
|
|
</p>
|
|
<pre> 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>
|
|
</pre>
|
|
<p>
|
|
The field-content does not include any leading or trailing LWS:
|
|
linear white space occurring before the first non-whitespace
|
|
character of the field-value or after the last non-whitespace
|
|
character of the field-value. Such leading or trailing LWS MAY be
|
|
removed without changing the semantics of the field value. Any LWS
|
|
that occurs between field-content MAY be replaced with a single SP
|
|
before interpreting the field value or forwarding the message
|
|
downstream.
|
|
</p>
|
|
<p>
|
|
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.
|
|
</p>
|
|
<p>
|
|
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.
|
|
</p>
|
|
<h3><a id='sec4.3'>4.3</a> Message Body</h3>
|
|
<p>
|
|
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
|
|
<a rel='xref' href='rfc2616-sec14.html#sec14.41'>14.41</a>).
|
|
</p>
|
|
<pre> message-body = entity-body
|
|
| <entity-body encoded as per Transfer-Encoding>
|
|
</pre>
|
|
<p>
|
|
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
|
|
</p>
|
|
<p>
|
|
entity, and thus MAY be added or removed by any application along the
|
|
request/response chain. (However, section 3.6 places restrictions on
|
|
when certain transfer-codings may be used.)
|
|
</p>
|
|
<p>
|
|
The rules for when a message-body is allowed in a message differ for
|
|
requests and responses.
|
|
</p>
|
|
<p>
|
|
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 MUST NOT be included in
|
|
a request if the specification of the request method (section <a rel='xref' href='rfc2616-sec5.html#sec5.1.1'>5.1.1</a>)
|
|
does not allow sending an entity-body in requests. A server SHOULD
|
|
read and forward a message-body on any request; if the request method
|
|
does not include defined semantics for an entity-body, then the
|
|
message-body SHOULD be ignored when handling the request.
|
|
</p>
|
|
<p>
|
|
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 <a rel='xref' href='rfc2616-sec6.html#sec6.1.1'>6.1.1</a>). 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.
|
|
</p>
|
|
<h3><a id='sec4.4'>4.4</a> Message Length</h3>
|
|
<p>
|
|
The transfer-length of a message is the length of the message-body as
|
|
it appears in the message; that is, after any transfer-codings have
|
|
been applied. When a message-body is included with a message, the
|
|
transfer-length of that body is determined by one of the following
|
|
(in order of precedence):
|
|
</p>
|
|
<p>
|
|
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.
|
|
</p>
|
|
<p>
|
|
2.If a Transfer-Encoding header field (section <a rel='xref' href='rfc2616-sec14.html#sec14.41'>14.41</a>) is present and
|
|
has any value other than "identity", then the transfer-length is
|
|
defined by use of the "chunked" transfer-coding (section <a rel='xref' href='rfc2616-sec3.html#sec3.6'>3.6</a>),
|
|
unless the message is terminated by closing the connection.
|
|
</p>
|
|
<p>
|
|
3.If a Content-Length header field (section <a rel='xref' href='rfc2616-sec14.html#sec14.13'>14.13</a>) is present, its
|
|
decimal value in OCTETs represents both the entity-length and the
|
|
transfer-length. The Content-Length header field MUST NOT be sent
|
|
if these two lengths are different (i.e., if a Transfer-Encoding
|
|
</p>
|
|
<pre> header field is present). If a message is received with both a
|
|
Transfer-Encoding header field and a Content-Length header field,
|
|
the latter MUST be ignored.
|
|
</pre>
|
|
<p>
|
|
4.If the message uses the media type "multipart/byteranges", and the
|
|
transfer-length is not otherwise specified, then this self-
|
|
delimiting media type defines the transfer-length. This media type
|
|
MUST NOT be used unless the sender knows that the recipient can parse
|
|
it; the presence in a request of a Range header with multiple byte-
|
|
range specifiers from a <a rel='xref' href='rfc2616-sec1.html#sec1.1'>1.1</a>
|
|
client implies that the client can parse multipart/byteranges responses.
|
|
</p>
|
|
<pre> A range header might be forwarded by a 1.0 proxy that does not
|
|
understand multipart/byteranges; in this case the server MUST
|
|
delimit the message using methods defined in items 1,3 or 5 of
|
|
this section.
|
|
</pre>
|
|
<p>
|
|
5.By the server closing the connection. (Closing the connection
|
|
cannot be used to indicate the end of a request body, since that
|
|
would leave no possibility for the server to send back a response.)
|
|
</p>
|
|
<p>
|
|
For compatibility with HTTP/1.0 applications, HTTP/1.1 requests
|
|
containing a message-body MUST include a valid Content-Length header
|
|
field unless the server is known to be HTTP/1.1 compliant. If a
|
|
request contains a message-body and a Content-Length is not given,
|
|
the server SHOULD respond with 400 (bad request) if it cannot
|
|
determine the length of the message, or with 411 (length required) if
|
|
it wishes to insist on receiving a valid Content-Length.
|
|
</p>
|
|
<p>
|
|
All HTTP/1.1 applications that receive entities MUST accept the
|
|
"chunked" transfer-coding (section 3.6), thus allowing this mechanism
|
|
to be used for messages when the message length cannot be determined
|
|
in advance.
|
|
</p>
|
|
<p>
|
|
Messages MUST NOT include both a Content-Length header field and a
|
|
non-identity transfer-coding. If the message does include a non-
|
|
identity transfer-coding, the Content-Length MUST be ignored.
|
|
</p>
|
|
<p>
|
|
When a Content-Length is given in a message where a message-body is
|
|
allowed, its field value MUST exactly match the number of OCTETs in
|
|
the message-body. HTTP/1.1 user agents MUST notify the user when an
|
|
invalid length is received and detected.
|
|
</p>
|
|
<h3><a id='sec4.5'>4.5</a> General Header Fields</h3>
|
|
<p>
|
|
There are a few header fields which have general applicability for
|
|
both request and response messages, but which do not apply to the
|
|
entity being transferred. These header fields apply only to the
|
|
</p>
|
|
<p>
|
|
message being transmitted.
|
|
</p>
|
|
<pre> general-header = Cache-Control ; Section 14.9
|
|
| Connection ; Section <a rel='xref' href='rfc2616-sec14.html#sec14.10'>14.10</a>
|
|
| Date ; Section <a rel='xref' href='rfc2616-sec14.html#sec14.18'>14.18</a>
|
|
| Pragma ; Section <a rel='xref' href='rfc2616-sec14.html#sec14.32'>14.32</a>
|
|
| Trailer ; Section <a rel='xref' href='rfc2616-sec14.html#sec14.40'>14.40</a>
|
|
| Transfer-Encoding ; Section <a rel='xref' href='rfc2616-sec14.html#sec14.41'>14.41</a>
|
|
| Upgrade ; Section <a rel='xref' href='rfc2616-sec14.html#sec14.42'>14.42</a>
|
|
| Via ; Section <a rel='xref' href='rfc2616-sec14.html#sec14.45'>14.45</a>
|
|
| Warning ; Section <a rel='xref' href='rfc2616-sec14.html#sec14.46'>14.46</a>
|
|
</pre>
|
|
<p>
|
|
General-header field names can be extended reliably only in
|
|
combination with a change in the protocol version. However, new or
|
|
experimental header fields may be given the semantics of general
|
|
header fields if all parties in the communication recognize them to
|
|
be general-header fields. Unrecognized header fields are treated as
|
|
entity-header fields.
|
|
</p>
|
|
</body></html>
|