rfc2616-sec4.html
12.3 KB
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
<!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>