1 | <?xml version="1.0" encoding="UTF-8"?> |
---|
2 | <!-- |
---|
3 | This XML document is the output of clean-for-DTD.xslt; a tool that strips |
---|
4 | extensions to RFC2629(bis) from documents for processing with xml2rfc. |
---|
5 | --> |
---|
6 | <?xml-stylesheet type='text/xsl' href='../myxml2rfc.xslt'?> |
---|
7 | <?rfc toc="yes" ?> |
---|
8 | <?rfc symrefs="yes" ?> |
---|
9 | <?rfc sortrefs="yes" ?> |
---|
10 | <?rfc compact="yes"?> |
---|
11 | <?rfc subcompact="no" ?> |
---|
12 | <?rfc linkmailto="no" ?> |
---|
13 | <?rfc editing="no" ?> |
---|
14 | <?rfc comments="yes"?> |
---|
15 | <?rfc inline="yes"?> |
---|
16 | <!DOCTYPE rfc |
---|
17 | PUBLIC "" "rfc2629.dtd"> |
---|
18 | <rfc obsoletes="2616" category="std" ipr="pre5378Trust200902" docName="draft-ietf-httpbis-p1-messaging-07"> |
---|
19 | <front> |
---|
20 | |
---|
21 | <title abbrev="HTTP/1.1, Part 1">HTTP/1.1, part 1: URIs, Connections, and Message Parsing</title> |
---|
22 | |
---|
23 | <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor"> |
---|
24 | <organization abbrev="Day Software">Day Software</organization> |
---|
25 | <address> |
---|
26 | <postal> |
---|
27 | <street>23 Corporate Plaza DR, Suite 280</street> |
---|
28 | <city>Newport Beach</city> |
---|
29 | <region>CA</region> |
---|
30 | <code>92660</code> |
---|
31 | <country>USA</country> |
---|
32 | </postal> |
---|
33 | <phone>+1-949-706-5300</phone> |
---|
34 | <facsimile>+1-949-706-5305</facsimile> |
---|
35 | <email>fielding@gbiv.com</email> |
---|
36 | <uri>http://roy.gbiv.com/</uri> |
---|
37 | </address> |
---|
38 | </author> |
---|
39 | |
---|
40 | <author initials="J." surname="Gettys" fullname="Jim Gettys"> |
---|
41 | <organization>One Laptop per Child</organization> |
---|
42 | <address> |
---|
43 | <postal> |
---|
44 | <street>21 Oak Knoll Road</street> |
---|
45 | <city>Carlisle</city> |
---|
46 | <region>MA</region> |
---|
47 | <code>01741</code> |
---|
48 | <country>USA</country> |
---|
49 | </postal> |
---|
50 | <email>jg@laptop.org</email> |
---|
51 | <uri>http://www.laptop.org/</uri> |
---|
52 | </address> |
---|
53 | </author> |
---|
54 | |
---|
55 | <author initials="J." surname="Mogul" fullname="Jeffrey C. Mogul"> |
---|
56 | <organization abbrev="HP">Hewlett-Packard Company</organization> |
---|
57 | <address> |
---|
58 | <postal> |
---|
59 | <street>HP Labs, Large Scale Systems Group</street> |
---|
60 | <street>1501 Page Mill Road, MS 1177</street> |
---|
61 | <city>Palo Alto</city> |
---|
62 | <region>CA</region> |
---|
63 | <code>94304</code> |
---|
64 | <country>USA</country> |
---|
65 | </postal> |
---|
66 | <email>JeffMogul@acm.org</email> |
---|
67 | </address> |
---|
68 | </author> |
---|
69 | |
---|
70 | <author initials="H." surname="Frystyk" fullname="Henrik Frystyk Nielsen"> |
---|
71 | <organization abbrev="Microsoft">Microsoft Corporation</organization> |
---|
72 | <address> |
---|
73 | <postal> |
---|
74 | <street>1 Microsoft Way</street> |
---|
75 | <city>Redmond</city> |
---|
76 | <region>WA</region> |
---|
77 | <code>98052</code> |
---|
78 | <country>USA</country> |
---|
79 | </postal> |
---|
80 | <email>henrikn@microsoft.com</email> |
---|
81 | </address> |
---|
82 | </author> |
---|
83 | |
---|
84 | <author initials="L." surname="Masinter" fullname="Larry Masinter"> |
---|
85 | <organization abbrev="Adobe Systems">Adobe Systems, Incorporated</organization> |
---|
86 | <address> |
---|
87 | <postal> |
---|
88 | <street>345 Park Ave</street> |
---|
89 | <city>San Jose</city> |
---|
90 | <region>CA</region> |
---|
91 | <code>95110</code> |
---|
92 | <country>USA</country> |
---|
93 | </postal> |
---|
94 | <email>LMM@acm.org</email> |
---|
95 | <uri>http://larry.masinter.net/</uri> |
---|
96 | </address> |
---|
97 | </author> |
---|
98 | |
---|
99 | <author initials="P." surname="Leach" fullname="Paul J. Leach"> |
---|
100 | <organization abbrev="Microsoft">Microsoft Corporation</organization> |
---|
101 | <address> |
---|
102 | <postal> |
---|
103 | <street>1 Microsoft Way</street> |
---|
104 | <city>Redmond</city> |
---|
105 | <region>WA</region> |
---|
106 | <code>98052</code> |
---|
107 | </postal> |
---|
108 | <email>paulle@microsoft.com</email> |
---|
109 | </address> |
---|
110 | </author> |
---|
111 | |
---|
112 | <author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee"> |
---|
113 | <organization abbrev="W3C/MIT">World Wide Web Consortium</organization> |
---|
114 | <address> |
---|
115 | <postal> |
---|
116 | <street>MIT Computer Science and Artificial Intelligence Laboratory</street> |
---|
117 | <street>The Stata Center, Building 32</street> |
---|
118 | <street>32 Vassar Street</street> |
---|
119 | <city>Cambridge</city> |
---|
120 | <region>MA</region> |
---|
121 | <code>02139</code> |
---|
122 | <country>USA</country> |
---|
123 | </postal> |
---|
124 | <email>timbl@w3.org</email> |
---|
125 | <uri>http://www.w3.org/People/Berners-Lee/</uri> |
---|
126 | </address> |
---|
127 | </author> |
---|
128 | |
---|
129 | <author initials="Y." surname="Lafon" fullname="Yves Lafon" role="editor"> |
---|
130 | <organization abbrev="W3C">World Wide Web Consortium</organization> |
---|
131 | <address> |
---|
132 | <postal> |
---|
133 | <street>W3C / ERCIM</street> |
---|
134 | <street>2004, rte des Lucioles</street> |
---|
135 | <city>Sophia-Antipolis</city> |
---|
136 | <region>AM</region> |
---|
137 | <code>06902</code> |
---|
138 | <country>France</country> |
---|
139 | </postal> |
---|
140 | <email>ylafon@w3.org</email> |
---|
141 | <uri>http://www.raubacapeu.net/people/yves/</uri> |
---|
142 | </address> |
---|
143 | </author> |
---|
144 | |
---|
145 | <author initials="J. F." surname="Reschke" fullname="Julian F. Reschke" role="editor"> |
---|
146 | <organization abbrev="greenbytes">greenbytes GmbH</organization> |
---|
147 | <address> |
---|
148 | <postal> |
---|
149 | <street>Hafenweg 16</street> |
---|
150 | <city>Muenster</city><region>NW</region><code>48155</code> |
---|
151 | <country>Germany</country> |
---|
152 | </postal> |
---|
153 | <phone>+49 251 2807760</phone> |
---|
154 | <facsimile>+49 251 2807761</facsimile> |
---|
155 | <email>julian.reschke@greenbytes.de</email> |
---|
156 | <uri>http://greenbytes.de/tech/webdav/</uri> |
---|
157 | </address> |
---|
158 | </author> |
---|
159 | |
---|
160 | <date day="13" month="July" year="2009"/> |
---|
161 | <workgroup>HTTPbis Working Group</workgroup> |
---|
162 | |
---|
163 | <abstract> |
---|
164 | <t> |
---|
165 | The Hypertext Transfer Protocol (HTTP) is an application-level |
---|
166 | protocol for distributed, collaborative, hypertext information |
---|
167 | systems. HTTP has been in use by the World Wide Web global information |
---|
168 | initiative since 1990. This document is Part 1 of the seven-part specification |
---|
169 | that defines the protocol referred to as "HTTP/1.1" and, taken together, |
---|
170 | obsoletes RFC 2616. Part 1 provides an overview of HTTP and |
---|
171 | its associated terminology, defines the "http" and "https" Uniform |
---|
172 | Resource Identifier (URI) schemes, defines the generic message syntax |
---|
173 | and parsing requirements for HTTP message frames, and describes |
---|
174 | general security concerns for implementations. |
---|
175 | </t> |
---|
176 | </abstract> |
---|
177 | |
---|
178 | <note title="Editorial Note (To be removed by RFC Editor)"> |
---|
179 | <t> |
---|
180 | Discussion of this draft should take place on the HTTPBIS working group |
---|
181 | mailing list (ietf-http-wg@w3.org). The current issues list is |
---|
182 | at <eref target="http://tools.ietf.org/wg/httpbis/trac/report/11"/> |
---|
183 | and related documents (including fancy diffs) can be found at |
---|
184 | <eref target="http://tools.ietf.org/wg/httpbis/"/>. |
---|
185 | </t> |
---|
186 | <t> |
---|
187 | The changes in this draft are summarized in <xref target="changes.since.06"/>. |
---|
188 | </t> |
---|
189 | </note> |
---|
190 | </front> |
---|
191 | <middle> |
---|
192 | <section title="Introduction" anchor="introduction"> |
---|
193 | <t> |
---|
194 | The Hypertext Transfer Protocol (HTTP) is an application-level |
---|
195 | request/response protocol that uses extensible semantics and MIME-like |
---|
196 | message payloads for flexible interaction with network-based hypertext |
---|
197 | information systems. HTTP relies upon the Uniform Resource Identifier (URI) |
---|
198 | standard <xref target="RFC3986"/> to indicate request targets and |
---|
199 | relationships between resources. |
---|
200 | Messages are passed in a format similar to that used by Internet mail |
---|
201 | <xref target="RFC5322"/> and the Multipurpose Internet Mail Extensions |
---|
202 | (MIME) <xref target="RFC2045"/> (see Appendix A of <xref target="Part3"/> for the differences |
---|
203 | between HTTP and MIME messages). |
---|
204 | </t> |
---|
205 | <t> |
---|
206 | HTTP is a generic interface protocol for information systems. It is |
---|
207 | designed to hide the details of how a service is implemented by presenting |
---|
208 | a uniform interface to clients that is independent of the types of |
---|
209 | resources provided. Likewise, servers do not need to be aware of each |
---|
210 | client's purpose: an HTTP request can be considered in isolation rather |
---|
211 | than being associated with a specific type of client or a predetermined |
---|
212 | sequence of application steps. The result is a protocol that can be used |
---|
213 | effectively in many different contexts and for which implementations can |
---|
214 | evolve independently over time. |
---|
215 | </t> |
---|
216 | <t> |
---|
217 | HTTP is also designed for use as a generic protocol for translating |
---|
218 | communication to and from other Internet information systems. |
---|
219 | HTTP proxies and gateways provide access to alternative information |
---|
220 | services by translating their diverse protocols into a hypertext |
---|
221 | format that can be viewed and manipulated by clients in the same way |
---|
222 | as HTTP services. |
---|
223 | </t> |
---|
224 | <t> |
---|
225 | One consequence of HTTP flexibility is that the protocol cannot be |
---|
226 | defined in terms of what occurs behind the interface. Instead, we |
---|
227 | are limited to defining the syntax of communication, the intent |
---|
228 | of received communication, and the expected behavior of recipients. |
---|
229 | If the communication is considered in isolation, then successful |
---|
230 | actions should be reflected in corresponding changes to the |
---|
231 | observable interface provided by servers. However, since multiple |
---|
232 | clients may act in parallel and perhaps at cross-purposes, we |
---|
233 | cannot require that such changes be observable beyond the scope |
---|
234 | of a single response. |
---|
235 | </t> |
---|
236 | <t> |
---|
237 | This document is Part 1 of the seven-part specification of HTTP, |
---|
238 | defining the protocol referred to as "HTTP/1.1" and obsoleting |
---|
239 | <xref target="RFC2616"/>. |
---|
240 | Part 1 describes the architectural elements that are used or |
---|
241 | referred to in HTTP and defines the URI schemes specific to |
---|
242 | HTTP-based resources, overall network operation, connection |
---|
243 | management, and HTTP message framing and forwarding requirements. |
---|
244 | Our goal is to define all of the mechanisms necessary for HTTP message |
---|
245 | handling that are independent of message semantics, thereby defining the |
---|
246 | complete set of requirements for message parsers and |
---|
247 | message-forwarding intermediaries. |
---|
248 | </t> |
---|
249 | |
---|
250 | <section title="Requirements" anchor="intro.requirements"> |
---|
251 | <t> |
---|
252 | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", |
---|
253 | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this |
---|
254 | document are to be interpreted as described in <xref target="RFC2119"/>. |
---|
255 | </t> |
---|
256 | <t> |
---|
257 | An implementation is not compliant if it fails to satisfy one or more |
---|
258 | of the MUST or REQUIRED level requirements for the protocols it |
---|
259 | implements. An implementation that satisfies all the MUST or REQUIRED |
---|
260 | level and all the SHOULD level requirements for its protocols is said |
---|
261 | to be "unconditionally compliant"; one that satisfies all the MUST |
---|
262 | level requirements but not all the SHOULD level requirements for its |
---|
263 | protocols is said to be "conditionally compliant." |
---|
264 | </t> |
---|
265 | </section> |
---|
266 | |
---|
267 | <section title="Syntax Notation" anchor="notation"> |
---|
268 | <iref primary="true" item="Grammar" subitem="ALPHA"/> |
---|
269 | <iref primary="true" item="Grammar" subitem="CR"/> |
---|
270 | <iref primary="true" item="Grammar" subitem="CRLF"/> |
---|
271 | <iref primary="true" item="Grammar" subitem="CTL"/> |
---|
272 | <iref primary="true" item="Grammar" subitem="DIGIT"/> |
---|
273 | <iref primary="true" item="Grammar" subitem="DQUOTE"/> |
---|
274 | <iref primary="true" item="Grammar" subitem="HEXDIG"/> |
---|
275 | <iref primary="true" item="Grammar" subitem="LF"/> |
---|
276 | <iref primary="true" item="Grammar" subitem="OCTET"/> |
---|
277 | <iref primary="true" item="Grammar" subitem="SP"/> |
---|
278 | <iref primary="true" item="Grammar" subitem="VCHAR"/> |
---|
279 | <iref primary="true" item="Grammar" subitem="WSP"/> |
---|
280 | <t> |
---|
281 | This specification uses the Augmented Backus-Naur Form (ABNF) notation |
---|
282 | of <xref target="RFC5234"/>. |
---|
283 | </t> |
---|
284 | <t anchor="core.rules"> |
---|
285 | |
---|
286 | |
---|
287 | |
---|
288 | |
---|
289 | |
---|
290 | |
---|
291 | |
---|
292 | |
---|
293 | |
---|
294 | |
---|
295 | |
---|
296 | |
---|
297 | The following core rules are included by |
---|
298 | reference, as defined in <xref target="RFC5234"/>, Appendix B.1: |
---|
299 | ALPHA (letters), CR (carriage return), CRLF (CR LF), CTL (controls), |
---|
300 | DIGIT (decimal 0-9), DQUOTE (double quote), |
---|
301 | HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), |
---|
302 | OCTET (any 8-bit sequence of data), SP (space), |
---|
303 | VCHAR (any visible <xref target="USASCII"/> character), |
---|
304 | and WSP (whitespace). |
---|
305 | </t> |
---|
306 | |
---|
307 | <section title="ABNF Extension: #rule" anchor="notation.abnf"> |
---|
308 | <t> |
---|
309 | One extension to the ABNF rules of <xref target="RFC5234"/> is used to |
---|
310 | improve readability. |
---|
311 | </t> |
---|
312 | <t> |
---|
313 | A construct "#" is defined, similar to "*", for defining lists of |
---|
314 | elements. The full form is "<n>#<m>element" indicating at least |
---|
315 | <n> and at most <m> elements, each separated by a single comma |
---|
316 | (",") and optional whitespace (OWS). |
---|
317 | </t> |
---|
318 | <figure><preamble> |
---|
319 | Thus, |
---|
320 | </preamble><artwork type="example"><![CDATA[ |
---|
321 | 1#element => element *( OWS "," OWS element ) |
---|
322 | ]]></artwork></figure> |
---|
323 | <figure><preamble> |
---|
324 | and: |
---|
325 | </preamble><artwork type="example"><![CDATA[ |
---|
326 | #element => [ 1#element ] |
---|
327 | ]]></artwork></figure> |
---|
328 | <figure><preamble> |
---|
329 | and for n >= 1 and m > 1: |
---|
330 | </preamble><artwork type="example"><![CDATA[ |
---|
331 | <n>#<m>element => element <n-1>*<m-1>( OWS "," OWS element ) |
---|
332 | ]]></artwork></figure> |
---|
333 | <t> |
---|
334 | For compatibility with legacy list rules, recipients SHOULD accept empty |
---|
335 | list elements. In other words, consumers would follow the list productions: |
---|
336 | </t> |
---|
337 | <figure><artwork type="example"><![CDATA[ |
---|
338 | #element => [ ( "," / element ) *( OWS "," [ OWS element ] ) ] |
---|
339 | |
---|
340 | 1#element => *( "," OWS ) element *( OWS "," [ OWS element ] ) |
---|
341 | ]]></artwork></figure> |
---|
342 | <t> |
---|
343 | <xref target="collected.abnf"/> shows the collected ABNF, with the list rules |
---|
344 | expanded as explained above. |
---|
345 | </t> |
---|
346 | </section> |
---|
347 | |
---|
348 | <section title="Basic Rules" anchor="basic.rules"> |
---|
349 | <t anchor="rule.CRLF"> |
---|
350 | |
---|
351 | HTTP/1.1 defines the sequence CR LF as the end-of-line marker for all |
---|
352 | protocol elements except the entity-body (see <xref target="tolerant.applications"/> for |
---|
353 | tolerant applications). The end-of-line marker within an entity-body |
---|
354 | is defined by its associated media type, as described in Section 2.3 of <xref target="Part3"/>. |
---|
355 | </t> |
---|
356 | <t anchor="rule.LWS"> |
---|
357 | This specification uses three rules to denote the use of linear |
---|
358 | whitespace: OWS (optional whitespace), RWS (required whitespace), and |
---|
359 | BWS ("bad" whitespace). |
---|
360 | </t> |
---|
361 | <t> |
---|
362 | The OWS rule is used where zero or more linear whitespace characters may |
---|
363 | appear. OWS SHOULD either not be produced or be produced as a single SP |
---|
364 | character. Multiple OWS characters that occur within field-content SHOULD |
---|
365 | be replaced with a single SP before interpreting the field value or |
---|
366 | forwarding the message downstream. |
---|
367 | </t> |
---|
368 | <t> |
---|
369 | RWS is used when at least one linear whitespace character is required to |
---|
370 | separate field tokens. RWS SHOULD be produced as a single SP character. |
---|
371 | Multiple RWS characters that occur within field-content SHOULD be |
---|
372 | replaced with a single SP before interpreting the field value or |
---|
373 | forwarding the message downstream. |
---|
374 | </t> |
---|
375 | <t> |
---|
376 | BWS is used where the grammar allows optional whitespace for historical |
---|
377 | reasons but senders SHOULD NOT produce it in messages. HTTP/1.1 |
---|
378 | recipients MUST accept such bad optional whitespace and remove it before |
---|
379 | interpreting the field value or forwarding the message downstream. |
---|
380 | </t> |
---|
381 | <t anchor="rule.whitespace"> |
---|
382 | |
---|
383 | |
---|
384 | |
---|
385 | |
---|
386 | </t> |
---|
387 | <figure><iref primary="true" item="Grammar" subitem="OWS"/><iref primary="true" item="Grammar" subitem="RWS"/><iref primary="true" item="Grammar" subitem="BWS"/><artwork type="abnf2616"><![CDATA[ |
---|
388 | OWS = *( [ obs-fold ] WSP ) |
---|
389 | ; "optional" whitespace |
---|
390 | RWS = 1*( [ obs-fold ] WSP ) |
---|
391 | ; "required" whitespace |
---|
392 | BWS = OWS |
---|
393 | ; "bad" whitespace |
---|
394 | obs-fold = CRLF |
---|
395 | ; see Section 4.2 |
---|
396 | ]]></artwork></figure> |
---|
397 | <t anchor="rule.token.separators"> |
---|
398 | |
---|
399 | |
---|
400 | Many HTTP/1.1 header field values consist of words separated by whitespace |
---|
401 | or special characters. These special characters MUST be in a quoted |
---|
402 | string to be used within a parameter value (as defined in |
---|
403 | <xref target="transfer.codings"/>). |
---|
404 | </t> |
---|
405 | <figure><iref primary="true" item="Grammar" subitem="token"/><iref primary="true" item="Grammar" subitem="tchar"/><artwork type="abnf2616"><![CDATA[ |
---|
406 | tchar = "!" / "#" / "$" / "%" / "&" / "'" / "*" |
---|
407 | / "+" / "-" / "." / "^" / "_" / "`" / "|" / "~" |
---|
408 | / DIGIT / ALPHA |
---|
409 | |
---|
410 | token = 1*tchar |
---|
411 | ]]></artwork></figure> |
---|
412 | <t anchor="rule.quoted-string"> |
---|
413 | |
---|
414 | |
---|
415 | |
---|
416 | A string of text is parsed as a single word if it is quoted using |
---|
417 | double-quote marks. |
---|
418 | </t> |
---|
419 | <figure><iref primary="true" item="Grammar" subitem="quoted-string"/><iref primary="true" item="Grammar" subitem="qdtext"/><iref primary="true" item="Grammar" subitem="obs-text"/><artwork type="abnf2616"><![CDATA[ |
---|
420 | quoted-string = DQUOTE *( qdtext / quoted-pair ) DQUOTE |
---|
421 | qdtext = OWS / %x21 / %x23-5B / %x5D-7E / obs-text |
---|
422 | ; OWS / <VCHAR except DQUOTE and "\"> / obs-text |
---|
423 | obs-text = %x80-FF |
---|
424 | ]]></artwork></figure> |
---|
425 | <t anchor="rule.quoted-pair"> |
---|
426 | |
---|
427 | |
---|
428 | The backslash character ("\") MAY be used as a single-character |
---|
429 | quoting mechanism only within quoted-string and comment constructs. |
---|
430 | </t> |
---|
431 | <figure><iref primary="true" item="Grammar" subitem="quoted-text"/><iref primary="true" item="Grammar" subitem="quoted-pair"/><artwork type="abnf2616"><![CDATA[ |
---|
432 | quoted-text = %x01-09 / |
---|
433 | %x0B-0C / |
---|
434 | %x0E-FF ; Characters excluding NUL, CR and LF |
---|
435 | quoted-pair = "\" quoted-text |
---|
436 | ]]></artwork></figure> |
---|
437 | </section> |
---|
438 | |
---|
439 | <section title="ABNF Rules defined in other Parts of the Specification" anchor="abnf.dependencies"> |
---|
440 | |
---|
441 | |
---|
442 | |
---|
443 | |
---|
444 | |
---|
445 | |
---|
446 | |
---|
447 | <t> |
---|
448 | The ABNF rules below are defined in other parts: |
---|
449 | </t> |
---|
450 | <figure><artwork type="abnf2616"><![CDATA[ |
---|
451 | request-header = <request-header, defined in [Part2], Section 3> |
---|
452 | response-header = <response-header, defined in [Part2], Section 5> |
---|
453 | ]]></artwork></figure> |
---|
454 | <figure><artwork type="abnf2616"><![CDATA[ |
---|
455 | entity-body = <entity-body, defined in [Part3], Section 3.2> |
---|
456 | entity-header = <entity-header, defined in [Part3], Section 3.1> |
---|
457 | ]]></artwork></figure> |
---|
458 | <figure><artwork type="abnf2616"><![CDATA[ |
---|
459 | Cache-Control = <Cache-Control, defined in [Part6], Section 3.4> |
---|
460 | Pragma = <Pragma, defined in [Part6], Section 3.4> |
---|
461 | Warning = <Warning, defined in [Part6], Section 3.6> |
---|
462 | ]]></artwork></figure> |
---|
463 | </section> |
---|
464 | |
---|
465 | </section> |
---|
466 | </section> |
---|
467 | |
---|
468 | <section title="HTTP architecture" anchor="architecture"> |
---|
469 | <t> |
---|
470 | HTTP was created with a specific architecture in mind, the World Wide Web, |
---|
471 | and has evolved over time to support the scalability needs of a worldwide |
---|
472 | hypertext system. Much of that architecture is reflected in the terminology |
---|
473 | and syntax productions used to define HTTP. |
---|
474 | </t> |
---|
475 | |
---|
476 | <section title="Uniform Resource Identifiers" anchor="uri"> |
---|
477 | <t> |
---|
478 | Uniform Resource Identifiers (URIs) <xref target="RFC3986"/> are used |
---|
479 | throughout HTTP as the means for identifying resources. URI references |
---|
480 | are used to target requests, redirect responses, and define relationships. |
---|
481 | HTTP does not limit what a resource may be; it merely defines an interface |
---|
482 | that can be used to interact with a resource via HTTP. More information on |
---|
483 | the scope of URIs and resources can be found in <xref target="RFC3986"/>. |
---|
484 | </t> |
---|
485 | |
---|
486 | |
---|
487 | |
---|
488 | |
---|
489 | |
---|
490 | |
---|
491 | |
---|
492 | |
---|
493 | |
---|
494 | |
---|
495 | |
---|
496 | |
---|
497 | <t> |
---|
498 | This specification adopts the definitions of "URI-reference", |
---|
499 | "absolute-URI", "relative-part", "fragment", "port", "host", |
---|
500 | "path-abempty", "path-absolute", "query", and "authority" from |
---|
501 | <xref target="RFC3986"/>. In addition, we define a partial-URI rule for |
---|
502 | protocol elements that allow a relative URI without a fragment. |
---|
503 | </t> |
---|
504 | <figure><iref primary="true" item="Grammar" subitem="URI-reference"/><iref primary="true" item="Grammar" subitem="absolute-URI"/><iref primary="true" item="Grammar" subitem="authority"/><iref primary="true" item="Grammar" subitem="path-absolute"/><iref primary="true" item="Grammar" subitem="port"/><iref primary="true" item="Grammar" subitem="query"/><iref primary="true" item="Grammar" subitem="uri-host"/><artwork type="abnf2616"><![CDATA[ |
---|
505 | URI = <URI, defined in [RFC3986], Section 3> |
---|
506 | URI-reference = <URI-reference, defined in [RFC3986], Section 4.1> |
---|
507 | absolute-URI = <absolute-URI, defined in [RFC3986], Section 4.3> |
---|
508 | relative-part = <relative-part, defined in [RFC3986], Section 4.2> |
---|
509 | authority = <authority, defined in [RFC3986], Section 3.2> |
---|
510 | fragment = <fragment, defined in [RFC3986], Section 3.5> |
---|
511 | path-abempty = <path-abempty, defined in [RFC3986], Section 3.3> |
---|
512 | path-absolute = <path-absolute, defined in [RFC3986], Section 3.3> |
---|
513 | port = <port, defined in [RFC3986], Section 3.2.3> |
---|
514 | query = <query, defined in [RFC3986], Section 3.4> |
---|
515 | uri-host = <host, defined in [RFC3986], Section 3.2.2> |
---|
516 | |
---|
517 | partial-URI = relative-part [ "?" query ] |
---|
518 | ]]></artwork></figure> |
---|
519 | <t> |
---|
520 | Each protocol element in HTTP that allows a URI reference will indicate in |
---|
521 | its ABNF production whether the element allows only a URI in absolute form |
---|
522 | (absolute-URI), any relative reference (relative-ref), or some other subset |
---|
523 | of the URI-reference grammar. Unless otherwise indicated, URI references |
---|
524 | are parsed relative to the request target (the default base URI for both |
---|
525 | the request and its corresponding response). |
---|
526 | </t> |
---|
527 | |
---|
528 | <section title="http URI scheme" anchor="http.uri"> |
---|
529 | |
---|
530 | <iref item="http URI scheme" primary="true"/> |
---|
531 | <iref item="URI scheme" subitem="http" primary="true"/> |
---|
532 | <t> |
---|
533 | The "http" scheme is used to locate network resources via the HTTP |
---|
534 | protocol. |
---|
535 | </t> |
---|
536 | <figure><iref primary="true" item="Grammar" subitem="http-URI"/><artwork type="abnf2616"><![CDATA[ |
---|
537 | http-URI = "http:" "//" authority path-abempty [ "?" query ] |
---|
538 | ]]></artwork></figure> |
---|
539 | <t> |
---|
540 | If the port is empty or not given, port 80 is assumed. The semantics |
---|
541 | are that the identified resource is located at the server listening |
---|
542 | for TCP connections on that port of that host, and the request-target |
---|
543 | for the resource is path-absolute (<xref target="request-target"/>). The use of IP addresses |
---|
544 | in URLs SHOULD be avoided whenever possible (see <xref target="RFC1900"/>). If |
---|
545 | the path-absolute is not present in the URL, it MUST be given as "/" when |
---|
546 | used as a request-target for a resource (<xref target="request-target"/>). If a proxy |
---|
547 | receives a host name which is not a fully qualified domain name, it |
---|
548 | MAY add its domain to the host name it received. If a proxy receives |
---|
549 | a fully qualified domain name, the proxy MUST NOT change the host |
---|
550 | name. |
---|
551 | </t> |
---|
552 | </section> |
---|
553 | |
---|
554 | <section title="https URI scheme" anchor="https.uri"> |
---|
555 | <iref item="https URI scheme"/> |
---|
556 | <iref item="URI scheme" subitem="https"/> |
---|
557 | <t> |
---|
558 | <cref>TBD: Define and explain purpose of https scheme.</cref> |
---|
559 | </t> |
---|
560 | <t><list> |
---|
561 | <t> |
---|
562 | Note: the "https" scheme is defined in <xref target="RFC2818"/>. |
---|
563 | </t> |
---|
564 | </list></t> |
---|
565 | </section> |
---|
566 | |
---|
567 | <section title="URI Comparison" anchor="uri.comparison"> |
---|
568 | <t> |
---|
569 | When comparing two URIs to decide if they match or not, a client |
---|
570 | SHOULD use a case-sensitive octet-by-octet comparison of the entire |
---|
571 | URIs, with these exceptions: |
---|
572 | <list style="symbols"> |
---|
573 | <t>A port that is empty or not given is equivalent to the default |
---|
574 | port for that URI-reference;</t> |
---|
575 | <t>Comparisons of host names MUST be case-insensitive;</t> |
---|
576 | <t>Comparisons of scheme names MUST be case-insensitive;</t> |
---|
577 | <t>An empty path-absolute is equivalent to a path-absolute of "/".</t> |
---|
578 | <t>Characters other than those in the "reserved" set are equivalent to their |
---|
579 | percent-encoded octets (see <xref target="RFC3986"/>, Section 2.1). |
---|
580 | </t> |
---|
581 | </list> |
---|
582 | </t> |
---|
583 | <t> |
---|
584 | For example, the following three URIs are equivalent: |
---|
585 | </t> |
---|
586 | <figure><artwork type="example"><![CDATA[ |
---|
587 | http://example.com:80/~smith/home.html |
---|
588 | http://EXAMPLE.com/%7Esmith/home.html |
---|
589 | http://EXAMPLE.com:/%7esmith/home.html |
---|
590 | ]]></artwork></figure> |
---|
591 | </section> |
---|
592 | |
---|
593 | <section title="Scheme aliases considered harmful" anchor="scheme.aliases"> |
---|
594 | <t> |
---|
595 | </t> |
---|
596 | </section> |
---|
597 | </section> |
---|
598 | |
---|
599 | <section title="Overall Operation" anchor="intro.overall.operation"> |
---|
600 | <t> |
---|
601 | HTTP is a request/response protocol. A client sends a |
---|
602 | request to the server in the form of a request method, URI, and |
---|
603 | protocol version, followed by a MIME-like message containing request |
---|
604 | modifiers, client information, and possible body content over a |
---|
605 | connection with a server. The server responds with a status line, |
---|
606 | including the message's protocol version and a success or error code, |
---|
607 | followed by a MIME-like message containing server information, entity |
---|
608 | metainformation, and possible entity-body content. |
---|
609 | </t> |
---|
610 | <t> |
---|
611 | Most HTTP communication is initiated by a user agent and consists of |
---|
612 | a request to be applied to a resource on some origin server. In the |
---|
613 | simplest case, this may be accomplished via a single connection (v) |
---|
614 | between the user agent (UA) and the origin server (O). |
---|
615 | </t> |
---|
616 | <figure><artwork type="drawing"><![CDATA[ |
---|
617 | request chain ------------------------> |
---|
618 | UA -------------------v------------------- O |
---|
619 | <----------------------- response chain |
---|
620 | ]]></artwork></figure> |
---|
621 | <t> |
---|
622 | A more complicated situation occurs when one or more intermediaries |
---|
623 | are present in the request/response chain. There are three common |
---|
624 | forms of intermediary: proxy, gateway, and tunnel. A proxy is a |
---|
625 | forwarding agent, receiving requests for a URI in its absolute form, |
---|
626 | rewriting all or part of the message, and forwarding the reformatted |
---|
627 | request toward the server identified by the URI. A gateway is a |
---|
628 | receiving agent, acting as a layer above some other server(s) and, if |
---|
629 | necessary, translating the requests to the underlying server's |
---|
630 | protocol. A tunnel acts as a relay point between two connections |
---|
631 | without changing the messages; tunnels are used when the |
---|
632 | communication needs to pass through an intermediary (such as a |
---|
633 | firewall) even when the intermediary cannot understand the contents |
---|
634 | of the messages. |
---|
635 | </t> |
---|
636 | <figure><artwork type="drawing"><![CDATA[ |
---|
637 | request chain --------------------------------------> |
---|
638 | UA -----v----- A -----v----- B -----v----- C -----v----- O |
---|
639 | <------------------------------------- response chain |
---|
640 | ]]></artwork></figure> |
---|
641 | <t> |
---|
642 | The figure above shows three intermediaries (A, B, and C) between the |
---|
643 | user agent and origin server. A request or response message that |
---|
644 | travels the whole chain will pass through four separate connections. |
---|
645 | This distinction is important because some HTTP communication options |
---|
646 | may apply only to the connection with the nearest, non-tunnel |
---|
647 | neighbor, only to the end-points of the chain, or to all connections |
---|
648 | along the chain. Although the diagram is linear, each participant may |
---|
649 | be engaged in multiple, simultaneous communications. For example, B |
---|
650 | may be receiving requests from many clients other than A, and/or |
---|
651 | forwarding requests to servers other than C, at the same time that it |
---|
652 | is handling A's request. |
---|
653 | </t> |
---|
654 | <t> |
---|
655 | Any party to the communication which is not acting as a tunnel may |
---|
656 | employ an internal cache for handling requests. The effect of a cache |
---|
657 | is that the request/response chain is shortened if one of the |
---|
658 | participants along the chain has a cached response applicable to that |
---|
659 | request. The following illustrates the resulting chain if B has a |
---|
660 | cached copy of an earlier response from O (via C) for a request which |
---|
661 | has not been cached by UA or A. |
---|
662 | </t> |
---|
663 | <figure><artwork type="drawing"><![CDATA[ |
---|
664 | request chain ----------> |
---|
665 | UA -----v----- A -----v----- B - - - - - - C - - - - - - O |
---|
666 | <--------- response chain |
---|
667 | ]]></artwork></figure> |
---|
668 | <t> |
---|
669 | Not all responses are usefully cacheable, and some requests may |
---|
670 | contain modifiers which place special requirements on cache behavior. |
---|
671 | HTTP requirements for cache behavior and cacheable responses are |
---|
672 | defined in Section 1 of <xref target="Part6"/>. |
---|
673 | </t> |
---|
674 | <t> |
---|
675 | In fact, there are a wide variety of architectures and configurations |
---|
676 | of caches and proxies currently being experimented with or deployed |
---|
677 | across the World Wide Web. These systems include national hierarchies |
---|
678 | of proxy caches to save transoceanic bandwidth, systems that |
---|
679 | broadcast or multicast cache entries, organizations that distribute |
---|
680 | subsets of cached data via CD-ROM, and so on. HTTP systems are used |
---|
681 | in corporate intranets over high-bandwidth links, and for access via |
---|
682 | PDAs with low-power radio links and intermittent connectivity. The |
---|
683 | goal of HTTP/1.1 is to support the wide diversity of configurations |
---|
684 | already deployed while introducing protocol constructs that meet the |
---|
685 | needs of those who build web applications that require high |
---|
686 | reliability and, failing that, at least reliable indications of |
---|
687 | failure. |
---|
688 | </t> |
---|
689 | <t> |
---|
690 | HTTP communication usually takes place over TCP/IP connections. The |
---|
691 | default port is TCP 80 (<eref target="http://www.iana.org/assignments/port-numbers"/>), but other ports can be used. This does |
---|
692 | not preclude HTTP from being implemented on top of any other protocol |
---|
693 | on the Internet, or on other networks. HTTP only presumes a reliable |
---|
694 | transport; any protocol that provides such guarantees can be used; |
---|
695 | the mapping of the HTTP/1.1 request and response structures onto the |
---|
696 | transport data units of the protocol in question is outside the scope |
---|
697 | of this specification. |
---|
698 | </t> |
---|
699 | <t> |
---|
700 | In HTTP/1.0, most implementations used a new connection for each |
---|
701 | request/response exchange. In HTTP/1.1, a connection may be used for |
---|
702 | one or more request/response exchanges, although connections may be |
---|
703 | closed for a variety of reasons (see <xref target="persistent.connections"/>). |
---|
704 | </t> |
---|
705 | </section> |
---|
706 | |
---|
707 | <section title="Use of HTTP for proxy communication" anchor="http.proxy"> |
---|
708 | <t> |
---|
709 | <cref>TBD: Configured to use HTTP to proxy HTTP or other protocols.</cref> |
---|
710 | </t> |
---|
711 | </section> |
---|
712 | <section title="Interception of HTTP for access control" anchor="http.intercept"> |
---|
713 | <t> |
---|
714 | <cref>TBD: Interception of HTTP traffic for initiating access control.</cref> |
---|
715 | </t> |
---|
716 | </section> |
---|
717 | <section title="Use of HTTP by other protocols" anchor="http.others"> |
---|
718 | <t> |
---|
719 | <cref>TBD: Profiles of HTTP defined by other protocol. |
---|
720 | Extensions of HTTP like WebDAV.</cref> |
---|
721 | </t> |
---|
722 | </section> |
---|
723 | <section title="Use of HTTP by media type specification" anchor="http.media"> |
---|
724 | <t> |
---|
725 | <cref>TBD: Instructions on composing HTTP requests via hypertext formats.</cref> |
---|
726 | </t> |
---|
727 | </section> |
---|
728 | </section> |
---|
729 | |
---|
730 | <section title="Protocol Parameters" anchor="protocol.parameters"> |
---|
731 | |
---|
732 | <section title="HTTP Version" anchor="http.version"> |
---|
733 | |
---|
734 | |
---|
735 | <t> |
---|
736 | HTTP uses a "<major>.<minor>" numbering scheme to indicate versions |
---|
737 | of the protocol. The protocol versioning policy is intended to allow |
---|
738 | the sender to indicate the format of a message and its capacity for |
---|
739 | understanding further HTTP communication, rather than the features |
---|
740 | obtained via that communication. No change is made to the version |
---|
741 | number for the addition of message components which do not affect |
---|
742 | communication behavior or which only add to extensible field values. |
---|
743 | The <minor> number is incremented when the changes made to the |
---|
744 | protocol add features which do not change the general message parsing |
---|
745 | algorithm, but which may add to the message semantics and imply |
---|
746 | additional capabilities of the sender. The <major> number is |
---|
747 | incremented when the format of a message within the protocol is |
---|
748 | changed. See <xref target="RFC2145"/> for a fuller explanation. |
---|
749 | </t> |
---|
750 | <t> |
---|
751 | The version of an HTTP message is indicated by an HTTP-Version field |
---|
752 | in the first line of the message. HTTP-Version is case-sensitive. |
---|
753 | </t> |
---|
754 | <figure><iref primary="true" item="Grammar" subitem="HTTP-Version"/><iref primary="true" item="Grammar" subitem="HTTP-Prot-Name"/><artwork type="abnf2616"><![CDATA[ |
---|
755 | HTTP-Version = HTTP-Prot-Name "/" 1*DIGIT "." 1*DIGIT |
---|
756 | HTTP-Prot-Name = %x48.54.54.50 ; "HTTP", case-sensitive |
---|
757 | ]]></artwork></figure> |
---|
758 | <t> |
---|
759 | Note that the major and minor numbers MUST be treated as separate |
---|
760 | integers and that each MAY be incremented higher than a single digit. |
---|
761 | Thus, HTTP/2.4 is a lower version than HTTP/2.13, which in turn is |
---|
762 | lower than HTTP/12.3. Leading zeros MUST be ignored by recipients and |
---|
763 | MUST NOT be sent. |
---|
764 | </t> |
---|
765 | <t> |
---|
766 | An application that sends a request or response message that includes |
---|
767 | HTTP-Version of "HTTP/1.1" MUST be at least conditionally compliant |
---|
768 | with this specification. Applications that are at least conditionally |
---|
769 | compliant with this specification SHOULD use an HTTP-Version of |
---|
770 | "HTTP/1.1" in their messages, and MUST do so for any message that is |
---|
771 | not compatible with HTTP/1.0. For more details on when to send |
---|
772 | specific HTTP-Version values, see <xref target="RFC2145"/>. |
---|
773 | </t> |
---|
774 | <t> |
---|
775 | The HTTP version of an application is the highest HTTP version for |
---|
776 | which the application is at least conditionally compliant. |
---|
777 | </t> |
---|
778 | <t> |
---|
779 | Proxy and gateway applications need to be careful when forwarding |
---|
780 | messages in protocol versions different from that of the application. |
---|
781 | Since the protocol version indicates the protocol capability of the |
---|
782 | sender, a proxy/gateway MUST NOT send a message with a version |
---|
783 | indicator which is greater than its actual version. If a higher |
---|
784 | version request is received, the proxy/gateway MUST either downgrade |
---|
785 | the request version, or respond with an error, or switch to tunnel |
---|
786 | behavior. |
---|
787 | </t> |
---|
788 | <t> |
---|
789 | Due to interoperability problems with HTTP/1.0 proxies discovered |
---|
790 | since the publication of <xref target="RFC2068"/>, caching proxies MUST, gateways |
---|
791 | MAY, and tunnels MUST NOT upgrade the request to the highest version |
---|
792 | they support. The proxy/gateway's response to that request MUST be in |
---|
793 | the same major version as the request. |
---|
794 | </t> |
---|
795 | <t><list> |
---|
796 | <t> |
---|
797 | Note: Converting between versions of HTTP may involve modification |
---|
798 | of header fields required or forbidden by the versions involved. |
---|
799 | </t> |
---|
800 | </list></t> |
---|
801 | </section> |
---|
802 | |
---|
803 | <section title="Date/Time Formats: Full Date" anchor="date.time.formats.full.date"> |
---|
804 | |
---|
805 | <t> |
---|
806 | HTTP applications have historically allowed three different formats |
---|
807 | for the representation of date/time stamps: |
---|
808 | </t> |
---|
809 | <figure><artwork type="example"><![CDATA[ |
---|
810 | Sun, 06 Nov 1994 08:49:37 GMT ; RFC 1123 |
---|
811 | Sunday, 06-Nov-94 08:49:37 GMT ; obsolete RFC 850 format |
---|
812 | Sun Nov 6 08:49:37 1994 ; ANSI C's asctime() format |
---|
813 | ]]></artwork></figure> |
---|
814 | <t> |
---|
815 | The first format is preferred as an Internet standard and represents |
---|
816 | a fixed-length subset of that defined by <xref target="RFC1123"/>. The |
---|
817 | other formats are described here only for |
---|
818 | compatibility with obsolete implementations. |
---|
819 | HTTP/1.1 clients and servers that parse the date value MUST accept |
---|
820 | all three formats (for compatibility with HTTP/1.0), though they MUST |
---|
821 | only generate the RFC 1123 format for representing HTTP-date values |
---|
822 | in header fields. See <xref target="tolerant.applications"/> for further information. |
---|
823 | </t> |
---|
824 | <t> |
---|
825 | All HTTP date/time stamps MUST be represented in Greenwich Mean Time |
---|
826 | (GMT), without exception. For the purposes of HTTP, GMT is exactly |
---|
827 | equal to UTC (Coordinated Universal Time). This is indicated in the |
---|
828 | first two formats by the inclusion of "GMT" as the three-letter |
---|
829 | abbreviation for time zone, and MUST be assumed when reading the |
---|
830 | asctime format. HTTP-date is case sensitive and MUST NOT include |
---|
831 | additional whitespace beyond that specifically included as SP in the |
---|
832 | grammar. |
---|
833 | </t> |
---|
834 | <figure><iref primary="true" item="Grammar" subitem="HTTP-date"/><artwork type="abnf2616"><![CDATA[ |
---|
835 | HTTP-date = rfc1123-date / obs-date |
---|
836 | ]]></artwork></figure> |
---|
837 | <t anchor="preferred.date.format"> |
---|
838 | |
---|
839 | |
---|
840 | |
---|
841 | |
---|
842 | |
---|
843 | |
---|
844 | |
---|
845 | |
---|
846 | |
---|
847 | |
---|
848 | Preferred format: |
---|
849 | </t> |
---|
850 | <figure><iref primary="true" item="Grammar" subitem="rfc1123-date"/><iref primary="true" item="Grammar" subitem="date1"/><iref primary="true" item="Grammar" subitem="time-of-day"/><iref primary="true" item="Grammar" subitem="hour"/><iref primary="true" item="Grammar" subitem="minute"/><iref primary="true" item="Grammar" subitem="second"/><iref primary="true" item="Grammar" subitem="day-name"/><iref primary="true" item="Grammar" subitem="day-name-l"/><iref primary="true" item="Grammar" subitem="day"/><iref primary="true" item="Grammar" subitem="month"/><iref primary="true" item="Grammar" subitem="year"/><iref primary="true" item="Grammar" subitem="GMT"/><artwork type="abnf2616"><![CDATA[ |
---|
851 | rfc1123-date = day-name "," SP date1 SP time-of-day SP GMT |
---|
852 | |
---|
853 | day-name = %x4D.6F.6E ; "Mon", case-sensitive |
---|
854 | / %x54.75.65 ; "Tue", case-sensitive |
---|
855 | / %x57.65.64 ; "Wed", case-sensitive |
---|
856 | / %x54.68.75 ; "Thu", case-sensitive |
---|
857 | / %x46.72.69 ; "Fri", case-sensitive |
---|
858 | / %x53.61.74 ; "Sat", case-sensitive |
---|
859 | / %x53.75.6E ; "Sun", case-sensitive |
---|
860 | |
---|
861 | date1 = day SP month SP year |
---|
862 | ; e.g., 02 Jun 1982 |
---|
863 | |
---|
864 | day = 2DIGIT |
---|
865 | month = %x4A.61.6E ; "Jan", case-sensitive |
---|
866 | / %x46.65.62 ; "Feb", case-sensitive |
---|
867 | / %x4D.61.72 ; "Mar", case-sensitive |
---|
868 | / %x41.70.72 ; "Apr", case-sensitive |
---|
869 | / %x4D.61.79 ; "May", case-sensitive |
---|
870 | / %x4A.75.6E ; "Jun", case-sensitive |
---|
871 | / %x4A.75.6C ; "Jul", case-sensitive |
---|
872 | / %x41.75.67 ; "Aug", case-sensitive |
---|
873 | / %x53.65.70 ; "Sep", case-sensitive |
---|
874 | / %x4F.63.74 ; "Oct", case-sensitive |
---|
875 | / %x4E.6F.76 ; "Nov", case-sensitive |
---|
876 | / %x44.65.63 ; "Dec", case-sensitive |
---|
877 | year = 4DIGIT |
---|
878 | |
---|
879 | GMT = %x47.4D.54 ; "GMT", case-sensitive |
---|
880 | |
---|
881 | time-of-day = hour ":" minute ":" second |
---|
882 | ; 00:00:00 - 23:59:59 |
---|
883 | |
---|
884 | hour = 2DIGIT |
---|
885 | minute = 2DIGIT |
---|
886 | second = 2DIGIT |
---|
887 | ]]></artwork></figure> |
---|
888 | <t> |
---|
889 | The semantics of <xref target="preferred.date.format" format="none">day-name</xref>, <xref target="preferred.date.format" format="none">day</xref>, |
---|
890 | <xref target="preferred.date.format" format="none">month</xref>, <xref target="preferred.date.format" format="none">year</xref>, and <xref target="preferred.date.format" format="none">time-of-day</xref> are the |
---|
891 | same as those defined for the RFC 5322 constructs |
---|
892 | with the corresponding name (<xref target="RFC5322"/>, Section 3.3). |
---|
893 | </t> |
---|
894 | <t anchor="obsolete.date.formats"> |
---|
895 | |
---|
896 | |
---|
897 | |
---|
898 | |
---|
899 | |
---|
900 | |
---|
901 | |
---|
902 | |
---|
903 | Obsolete formats: |
---|
904 | </t> |
---|
905 | <figure><iref primary="true" item="Grammar" subitem="obs-date"/><artwork type="abnf2616"><![CDATA[ |
---|
906 | obs-date = rfc850-date / asctime-date |
---|
907 | ]]></artwork></figure> |
---|
908 | <figure><iref primary="true" item="Grammar" subitem="rfc850-date"/><artwork type="abnf2616"><![CDATA[ |
---|
909 | rfc850-date = day-name-l "," SP date2 SP time-of-day SP GMT |
---|
910 | date2 = day "-" month "-" 2DIGIT |
---|
911 | ; day-month-year (e.g., 02-Jun-82) |
---|
912 | |
---|
913 | day-name-l = %x4D.6F.6E.64.61.79 ; "Monday", case-sensitive |
---|
914 | / %x54.75.65.73.64.61.79 ; "Tuesday", case-sensitive |
---|
915 | / %x57.65.64.6E.65.73.64.61.79 ; "Wednesday", case-sensitive |
---|
916 | / %x54.68.75.72.73.64.61.79 ; "Thursday", case-sensitive |
---|
917 | / %x46.72.69.64.61.79 ; "Friday", case-sensitive |
---|
918 | / %x53.61.74.75.72.64.61.79 ; "Saturday", case-sensitive |
---|
919 | / %x53.75.6E.64.61.79 ; "Sunday", case-sensitive |
---|
920 | ]]></artwork></figure> |
---|
921 | <figure><iref primary="true" item="Grammar" subitem="asctime-date"/><artwork type="abnf2616"><![CDATA[ |
---|
922 | asctime-date = day-name SP date3 SP time-of-day SP year |
---|
923 | date3 = month SP ( 2DIGIT / ( SP 1DIGIT )) |
---|
924 | ; month day (e.g., Jun 2) |
---|
925 | ]]></artwork></figure> |
---|
926 | <t><list> |
---|
927 | <t> |
---|
928 | Note: Recipients of date values are encouraged to be robust in |
---|
929 | accepting date values that may have been sent by non-HTTP |
---|
930 | applications, as is sometimes the case when retrieving or posting |
---|
931 | messages via proxies/gateways to SMTP or NNTP. |
---|
932 | </t> |
---|
933 | </list></t> |
---|
934 | <t><list> |
---|
935 | <t> |
---|
936 | Note: HTTP requirements for the date/time stamp format apply only |
---|
937 | to their usage within the protocol stream. Clients and servers are |
---|
938 | not required to use these formats for user presentation, request |
---|
939 | logging, etc. |
---|
940 | </t> |
---|
941 | </list></t> |
---|
942 | </section> |
---|
943 | |
---|
944 | <section title="Transfer Codings" anchor="transfer.codings"> |
---|
945 | |
---|
946 | |
---|
947 | <t> |
---|
948 | Transfer-coding values are used to indicate an encoding |
---|
949 | transformation that has been, can be, or may need to be applied to an |
---|
950 | entity-body in order to ensure "safe transport" through the network. |
---|
951 | This differs from a content coding in that the transfer-coding is a |
---|
952 | property of the message, not of the original entity. |
---|
953 | </t> |
---|
954 | <figure><iref primary="true" item="Grammar" subitem="transfer-coding"/><iref primary="true" item="Grammar" subitem="transfer-extension"/><artwork type="abnf2616"><![CDATA[ |
---|
955 | transfer-coding = "chunked" / transfer-extension |
---|
956 | transfer-extension = token *( OWS ";" OWS transfer-parameter ) |
---|
957 | ]]></artwork></figure> |
---|
958 | <t anchor="rule.parameter"> |
---|
959 | |
---|
960 | |
---|
961 | |
---|
962 | Parameters are in the form of attribute/value pairs. |
---|
963 | </t> |
---|
964 | <figure><iref primary="true" item="Grammar" subitem="transfer-parameter"/><iref primary="true" item="Grammar" subitem="attribute"/><iref primary="true" item="Grammar" subitem="value"/><iref primary="true" item="Grammar" subitem="date2"/><iref primary="true" item="Grammar" subitem="date3"/><artwork type="abnf2616"><![CDATA[ |
---|
965 | transfer-parameter = attribute BWS "=" BWS value |
---|
966 | attribute = token |
---|
967 | value = token / quoted-string |
---|
968 | ]]></artwork></figure> |
---|
969 | <t> |
---|
970 | All transfer-coding values are case-insensitive. HTTP/1.1 uses |
---|
971 | transfer-coding values in the TE header field (<xref target="header.te"/>) and in |
---|
972 | the Transfer-Encoding header field (<xref target="header.transfer-encoding"/>). |
---|
973 | </t> |
---|
974 | <t> |
---|
975 | Whenever a transfer-coding is applied to a message-body, the set of |
---|
976 | transfer-codings MUST include "chunked", unless the message indicates it |
---|
977 | is terminated by closing the connection. When the "chunked" transfer-coding |
---|
978 | is used, it MUST be the last transfer-coding applied to the |
---|
979 | message-body. The "chunked" transfer-coding MUST NOT be applied more |
---|
980 | than once to a message-body. These rules allow the recipient to |
---|
981 | determine the transfer-length of the message (<xref target="message.length"/>). |
---|
982 | </t> |
---|
983 | <t> |
---|
984 | Transfer-codings are analogous to the Content-Transfer-Encoding |
---|
985 | values of MIME <xref target="RFC2045"/>, which were designed to enable safe transport of |
---|
986 | binary data over a 7-bit transport service. However, safe transport |
---|
987 | has a different focus for an 8bit-clean transfer protocol. In HTTP, |
---|
988 | the only unsafe characteristic of message-bodies is the difficulty in |
---|
989 | determining the exact body length (<xref target="message.length"/>), or the desire to |
---|
990 | encrypt data over a shared transport. |
---|
991 | </t> |
---|
992 | <t> |
---|
993 | The Internet Assigned Numbers Authority (IANA) acts as a registry for |
---|
994 | transfer-coding value tokens. Initially, the registry contains the |
---|
995 | following tokens: "chunked" (<xref target="chunked.transfer.encoding"/>), |
---|
996 | "gzip", "compress", and "deflate" (Section 2.2 of <xref target="Part3"/>). |
---|
997 | </t> |
---|
998 | <t> |
---|
999 | New transfer-coding value tokens SHOULD be registered in the same way |
---|
1000 | as new content-coding value tokens (Section 2.2 of <xref target="Part3"/>). |
---|
1001 | </t> |
---|
1002 | <t> |
---|
1003 | A server which receives an entity-body with a transfer-coding it does |
---|
1004 | not understand SHOULD return 501 (Not Implemented), and close the |
---|
1005 | connection. A server MUST NOT send transfer-codings to an HTTP/1.0 |
---|
1006 | client. |
---|
1007 | </t> |
---|
1008 | |
---|
1009 | <section title="Chunked Transfer Coding" anchor="chunked.transfer.encoding"> |
---|
1010 | |
---|
1011 | |
---|
1012 | |
---|
1013 | |
---|
1014 | |
---|
1015 | |
---|
1016 | |
---|
1017 | |
---|
1018 | |
---|
1019 | <t> |
---|
1020 | The chunked encoding modifies the body of a message in order to |
---|
1021 | transfer it as a series of chunks, each with its own size indicator, |
---|
1022 | followed by an OPTIONAL trailer containing entity-header fields. This |
---|
1023 | allows dynamically produced content to be transferred along with the |
---|
1024 | information necessary for the recipient to verify that it has |
---|
1025 | received the full message. |
---|
1026 | </t> |
---|
1027 | <figure><iref primary="true" item="Grammar" subitem="Chunked-Body"/><iref primary="true" item="Grammar" subitem="chunk"/><iref primary="true" item="Grammar" subitem="chunk-size"/><iref primary="true" item="Grammar" subitem="last-chunk"/><iref primary="true" item="Grammar" subitem="chunk-ext"/><iref primary="true" item="Grammar" subitem="chunk-ext-name"/><iref primary="true" item="Grammar" subitem="chunk-ext-val"/><iref primary="true" item="Grammar" subitem="chunk-data"/><iref primary="true" item="Grammar" subitem="trailer-part"/><artwork type="abnf2616"><![CDATA[ |
---|
1028 | Chunked-Body = *chunk |
---|
1029 | last-chunk |
---|
1030 | trailer-part |
---|
1031 | CRLF |
---|
1032 | |
---|
1033 | chunk = chunk-size *WSP [ chunk-ext ] CRLF |
---|
1034 | chunk-data CRLF |
---|
1035 | chunk-size = 1*HEXDIG |
---|
1036 | last-chunk = 1*("0") *WSP [ chunk-ext ] CRLF |
---|
1037 | |
---|
1038 | chunk-ext = *( ";" *WSP chunk-ext-name |
---|
1039 | [ "=" chunk-ext-val ] *WSP ) |
---|
1040 | chunk-ext-name = token |
---|
1041 | chunk-ext-val = token / quoted-string |
---|
1042 | chunk-data = 1*OCTET ; a sequence of chunk-size octets |
---|
1043 | trailer-part = *( entity-header CRLF ) |
---|
1044 | ]]></artwork></figure> |
---|
1045 | <t> |
---|
1046 | The chunk-size field is a string of hex digits indicating the size of |
---|
1047 | the chunk-data in octets. The chunked encoding is ended by any chunk whose size is |
---|
1048 | zero, followed by the trailer, which is terminated by an empty line. |
---|
1049 | </t> |
---|
1050 | <t> |
---|
1051 | The trailer allows the sender to include additional HTTP header |
---|
1052 | fields at the end of the message. The Trailer header field can be |
---|
1053 | used to indicate which header fields are included in a trailer (see |
---|
1054 | <xref target="header.trailer"/>). |
---|
1055 | </t> |
---|
1056 | <t> |
---|
1057 | A server using chunked transfer-coding in a response MUST NOT use the |
---|
1058 | trailer for any header fields unless at least one of the following is |
---|
1059 | true: |
---|
1060 | <list style="numbers"> |
---|
1061 | <t>the request included a TE header field that indicates "trailers" is |
---|
1062 | acceptable in the transfer-coding of the response, as described in |
---|
1063 | <xref target="header.te"/>; or,</t> |
---|
1064 | |
---|
1065 | <t>the server is the origin server for the response, the trailer |
---|
1066 | fields consist entirely of optional metadata, and the recipient |
---|
1067 | could use the message (in a manner acceptable to the origin server) |
---|
1068 | without receiving this metadata. In other words, the origin server |
---|
1069 | is willing to accept the possibility that the trailer fields might |
---|
1070 | be silently discarded along the path to the client.</t> |
---|
1071 | </list> |
---|
1072 | </t> |
---|
1073 | <t> |
---|
1074 | This requirement prevents an interoperability failure when the |
---|
1075 | message is being received by an HTTP/1.1 (or later) proxy and |
---|
1076 | forwarded to an HTTP/1.0 recipient. It avoids a situation where |
---|
1077 | compliance with the protocol would have necessitated a possibly |
---|
1078 | infinite buffer on the proxy. |
---|
1079 | </t> |
---|
1080 | <t> |
---|
1081 | A process for decoding the "chunked" transfer-coding |
---|
1082 | can be represented in pseudo-code as: |
---|
1083 | </t> |
---|
1084 | <figure><artwork type="code"><![CDATA[ |
---|
1085 | length := 0 |
---|
1086 | read chunk-size, chunk-ext (if any) and CRLF |
---|
1087 | while (chunk-size > 0) { |
---|
1088 | read chunk-data and CRLF |
---|
1089 | append chunk-data to entity-body |
---|
1090 | length := length + chunk-size |
---|
1091 | read chunk-size and CRLF |
---|
1092 | } |
---|
1093 | read entity-header |
---|
1094 | while (entity-header not empty) { |
---|
1095 | append entity-header to existing header fields |
---|
1096 | read entity-header |
---|
1097 | } |
---|
1098 | Content-Length := length |
---|
1099 | Remove "chunked" from Transfer-Encoding |
---|
1100 | ]]></artwork></figure> |
---|
1101 | <t> |
---|
1102 | All HTTP/1.1 applications MUST be able to receive and decode the |
---|
1103 | "chunked" transfer-coding, and MUST ignore chunk-ext extensions |
---|
1104 | they do not understand. |
---|
1105 | </t> |
---|
1106 | </section> |
---|
1107 | </section> |
---|
1108 | |
---|
1109 | <section title="Product Tokens" anchor="product.tokens"> |
---|
1110 | |
---|
1111 | |
---|
1112 | <t> |
---|
1113 | Product tokens are used to allow communicating applications to |
---|
1114 | identify themselves by software name and version. Most fields using |
---|
1115 | product tokens also allow sub-products which form a significant part |
---|
1116 | of the application to be listed, separated by whitespace. By |
---|
1117 | convention, the products are listed in order of their significance |
---|
1118 | for identifying the application. |
---|
1119 | </t> |
---|
1120 | <figure><iref primary="true" item="Grammar" subitem="product"/><iref primary="true" item="Grammar" subitem="product-version"/><artwork type="abnf2616"><![CDATA[ |
---|
1121 | product = token ["/" product-version] |
---|
1122 | product-version = token |
---|
1123 | ]]></artwork></figure> |
---|
1124 | <t> |
---|
1125 | Examples: |
---|
1126 | </t> |
---|
1127 | <figure><artwork type="example"><![CDATA[ |
---|
1128 | User-Agent: CERN-LineMode/2.15 libwww/2.17b3 |
---|
1129 | Server: Apache/0.8.4 |
---|
1130 | ]]></artwork></figure> |
---|
1131 | <t> |
---|
1132 | Product tokens SHOULD be short and to the point. They MUST NOT be |
---|
1133 | used for advertising or other non-essential information. Although any |
---|
1134 | token character MAY appear in a product-version, this token SHOULD |
---|
1135 | only be used for a version identifier (i.e., successive versions of |
---|
1136 | the same product SHOULD only differ in the product-version portion of |
---|
1137 | the product value). |
---|
1138 | </t> |
---|
1139 | </section> |
---|
1140 | |
---|
1141 | <section title="Quality Values" anchor="quality.values"> |
---|
1142 | |
---|
1143 | <t> |
---|
1144 | Both transfer codings (TE request header, <xref target="header.te"/>) |
---|
1145 | and content negotiation (Section 4 of <xref target="Part3"/>) use short "floating point" |
---|
1146 | numbers to indicate the relative importance ("weight") of various |
---|
1147 | negotiable parameters. A weight is normalized to a real number in |
---|
1148 | the range 0 through 1, where 0 is the minimum and 1 the maximum |
---|
1149 | value. If a parameter has a quality value of 0, then content with |
---|
1150 | this parameter is `not acceptable' for the client. HTTP/1.1 |
---|
1151 | applications MUST NOT generate more than three digits after the |
---|
1152 | decimal point. User configuration of these values SHOULD also be |
---|
1153 | limited in this fashion. |
---|
1154 | </t> |
---|
1155 | <figure><iref primary="true" item="Grammar" subitem="qvalue"/><artwork type="abnf2616"><![CDATA[ |
---|
1156 | qvalue = ( "0" [ "." 0*3DIGIT ] ) |
---|
1157 | / ( "1" [ "." 0*3("0") ] ) |
---|
1158 | ]]></artwork></figure> |
---|
1159 | <t><list> |
---|
1160 | <t> |
---|
1161 | Note: "Quality values" is a misnomer, since these values merely represent |
---|
1162 | relative degradation in desired quality. |
---|
1163 | </t> |
---|
1164 | </list></t> |
---|
1165 | </section> |
---|
1166 | |
---|
1167 | </section> |
---|
1168 | |
---|
1169 | <section title="HTTP Message" anchor="http.message"> |
---|
1170 | |
---|
1171 | <section title="Message Types" anchor="message.types"> |
---|
1172 | |
---|
1173 | |
---|
1174 | |
---|
1175 | <t> |
---|
1176 | HTTP messages consist of requests from client to server and responses |
---|
1177 | from server to client. |
---|
1178 | </t> |
---|
1179 | <figure><iref primary="true" item="Grammar" subitem="HTTP-message"/><artwork type="abnf2616"><![CDATA[ |
---|
1180 | HTTP-message = Request / Response ; HTTP/1.1 messages |
---|
1181 | ]]></artwork></figure> |
---|
1182 | <t> |
---|
1183 | Request (<xref target="request"/>) and Response (<xref target="response"/>) messages use the generic |
---|
1184 | message format of <xref target="RFC5322"/> for transferring entities (the payload |
---|
1185 | of the message). Both types of message consist of a start-line, zero |
---|
1186 | or more header fields (also known as "headers"), an empty line (i.e., |
---|
1187 | a line with nothing preceding the CRLF) indicating the end of the |
---|
1188 | header fields, and possibly a message-body. |
---|
1189 | </t> |
---|
1190 | <figure><iref primary="true" item="Grammar" subitem="generic-message"/><iref primary="true" item="Grammar" subitem="start-line"/><artwork type="abnf2616"><![CDATA[ |
---|
1191 | generic-message = start-line |
---|
1192 | *( message-header CRLF ) |
---|
1193 | CRLF |
---|
1194 | [ message-body ] |
---|
1195 | start-line = Request-Line / Status-Line |
---|
1196 | ]]></artwork></figure> |
---|
1197 | <t> |
---|
1198 | In the interest of robustness, servers SHOULD ignore any empty |
---|
1199 | line(s) received where a Request-Line is expected. In other words, if |
---|
1200 | the server is reading the protocol stream at the beginning of a |
---|
1201 | message and receives a CRLF first, it should ignore the CRLF. |
---|
1202 | </t> |
---|
1203 | <t> |
---|
1204 | Certain buggy HTTP/1.0 client implementations generate extra CRLF's |
---|
1205 | after a POST request. To restate what is explicitly forbidden by the |
---|
1206 | BNF, an HTTP/1.1 client MUST NOT preface or follow a request with an |
---|
1207 | extra CRLF. |
---|
1208 | </t> |
---|
1209 | <t> |
---|
1210 | Whitespace (WSP) MUST NOT be sent between the start-line and the first |
---|
1211 | header field. The presence of whitespace might be an attempt to trick a |
---|
1212 | noncompliant implementation of HTTP into ignoring that field or processing |
---|
1213 | the next line as a new request, either of which may result in security |
---|
1214 | issues when implementations within the request chain interpret the |
---|
1215 | same message differently. HTTP/1.1 servers MUST reject such a message |
---|
1216 | with a 400 (Bad Request) response. |
---|
1217 | </t> |
---|
1218 | </section> |
---|
1219 | |
---|
1220 | <section title="Message Headers" anchor="message.headers"> |
---|
1221 | |
---|
1222 | |
---|
1223 | |
---|
1224 | |
---|
1225 | <t> |
---|
1226 | HTTP header fields follow the same general format as Internet messages in |
---|
1227 | Section 2.1 of <xref target="RFC5322"/>. Each header field consists |
---|
1228 | of a name followed by a colon (":"), optional whitespace, and the field |
---|
1229 | value. Field names are case-insensitive. |
---|
1230 | </t> |
---|
1231 | <figure><iref primary="true" item="Grammar" subitem="message-header"/><iref primary="true" item="Grammar" subitem="field-name"/><iref primary="true" item="Grammar" subitem="field-value"/><iref primary="true" item="Grammar" subitem="field-content"/><artwork type="abnf2616"><![CDATA[ |
---|
1232 | message-header = field-name ":" OWS [ field-value ] OWS |
---|
1233 | field-name = token |
---|
1234 | field-value = *( field-content / OWS ) |
---|
1235 | field-content = *( WSP / VCHAR / obs-text ) |
---|
1236 | ]]></artwork></figure> |
---|
1237 | <t> |
---|
1238 | Historically, HTTP has allowed field-content with text in the ISO-8859-1 |
---|
1239 | <xref target="ISO-8859-1"/> character encoding (allowing other character sets |
---|
1240 | through use of <xref target="RFC2047"/> encoding). In practice, most HTTP |
---|
1241 | header field-values use only a subset of the US-ASCII charset |
---|
1242 | <xref target="USASCII"/>. Newly defined header fields SHOULD constrain |
---|
1243 | their field-values to US-ASCII characters. Recipients SHOULD treat other |
---|
1244 | (obs-text) octets in field-content as opaque data. |
---|
1245 | </t> |
---|
1246 | <t> |
---|
1247 | No whitespace is allowed between the header field-name and colon. For |
---|
1248 | security reasons, any request message received containing such whitespace |
---|
1249 | MUST be rejected with a response code of 400 (Bad Request) and any such |
---|
1250 | whitespace in a response message MUST be removed. |
---|
1251 | </t> |
---|
1252 | <t> |
---|
1253 | The field value MAY be preceded by optional whitespace; a single SP is |
---|
1254 | preferred. The field-value does not include any leading or trailing white |
---|
1255 | space: OWS occurring before the first non-whitespace character of the |
---|
1256 | field-value or after the last non-whitespace character of the field-value |
---|
1257 | is ignored and MAY be removed without changing the meaning of the header |
---|
1258 | field. |
---|
1259 | </t> |
---|
1260 | <t> |
---|
1261 | Historically, HTTP header field values could be extended over multiple |
---|
1262 | lines by preceding each extra line with at least one space or horizontal |
---|
1263 | tab character (line folding). This specification deprecates such line |
---|
1264 | folding except within the message/http media type |
---|
1265 | (<xref target="internet.media.type.message.http"/>). |
---|
1266 | HTTP/1.1 senders MUST NOT produce messages that include line folding |
---|
1267 | (i.e., that contain any field-content that matches the obs-fold rule) unless |
---|
1268 | the message is intended for packaging within the message/http media type. |
---|
1269 | HTTP/1.1 recipients SHOULD accept line folding and replace any embedded |
---|
1270 | obs-fold whitespace with a single SP prior to interpreting the field value |
---|
1271 | or forwarding the message downstream. |
---|
1272 | </t> |
---|
1273 | <t anchor="rule.comment"> |
---|
1274 | |
---|
1275 | |
---|
1276 | Comments can be included in some HTTP header fields by surrounding |
---|
1277 | the comment text with parentheses. Comments are only allowed in |
---|
1278 | fields containing "comment" as part of their field value definition. |
---|
1279 | In all other fields, parentheses are considered part of the field |
---|
1280 | value. |
---|
1281 | </t> |
---|
1282 | <figure><iref primary="true" item="Grammar" subitem="comment"/><iref primary="true" item="Grammar" subitem="ctext"/><artwork type="abnf2616"><![CDATA[ |
---|
1283 | comment = "(" *( ctext / quoted-pair / comment ) ")" |
---|
1284 | ctext = OWS / %x21-27 / %x2A-5B / %x5D-7E / obs-text |
---|
1285 | ; OWS / <VCHAR except "(", ")", and "\"> / obs-text |
---|
1286 | ]]></artwork></figure> |
---|
1287 | <t> |
---|
1288 | The order in which header fields with differing field names are |
---|
1289 | received is not significant. However, it is "good practice" to send |
---|
1290 | general-header fields first, followed by request-header or response-header |
---|
1291 | fields, and ending with the entity-header fields. |
---|
1292 | </t> |
---|
1293 | <t> |
---|
1294 | Multiple message-header fields with the same field-name MAY be |
---|
1295 | present in a message if and only if the entire field-value for that |
---|
1296 | header field is defined as a comma-separated list [i.e., #(values)]. |
---|
1297 | It MUST be possible to combine the multiple header fields into one |
---|
1298 | "field-name: field-value" pair, without changing the semantics of the |
---|
1299 | message, by appending each subsequent field-value to the first, each |
---|
1300 | separated by a comma. The order in which header fields with the same |
---|
1301 | field-name are received is therefore significant to the |
---|
1302 | interpretation of the combined field value, and thus a proxy MUST NOT |
---|
1303 | change the order of these field values when a message is forwarded. |
---|
1304 | </t> |
---|
1305 | <t><list> |
---|
1306 | <t> |
---|
1307 | Note: the "Set-Cookie" header as implemented in |
---|
1308 | practice (as opposed to how it is specified in <xref target="RFC2109"/>) |
---|
1309 | can occur multiple times, but does not use the list syntax, and thus cannot |
---|
1310 | be combined into a single line. (See Appendix A.2.3 of <xref target="Kri2001"/> |
---|
1311 | for details.) Also note that the Set-Cookie2 header specified in |
---|
1312 | <xref target="RFC2965"/> does not share this problem. |
---|
1313 | </t> |
---|
1314 | </list></t> |
---|
1315 | |
---|
1316 | </section> |
---|
1317 | |
---|
1318 | <section title="Message Body" anchor="message.body"> |
---|
1319 | |
---|
1320 | <t> |
---|
1321 | The message-body (if any) of an HTTP message is used to carry the |
---|
1322 | entity-body associated with the request or response. The message-body |
---|
1323 | differs from the entity-body only when a transfer-coding has been |
---|
1324 | applied, as indicated by the Transfer-Encoding header field (<xref target="header.transfer-encoding"/>). |
---|
1325 | </t> |
---|
1326 | <figure><iref primary="true" item="Grammar" subitem="message-body"/><artwork type="abnf2616"><![CDATA[ |
---|
1327 | message-body = entity-body |
---|
1328 | / <entity-body encoded as per Transfer-Encoding> |
---|
1329 | ]]></artwork></figure> |
---|
1330 | <t> |
---|
1331 | Transfer-Encoding MUST be used to indicate any transfer-codings |
---|
1332 | applied by an application to ensure safe and proper transfer of the |
---|
1333 | message. Transfer-Encoding is a property of the message, not of the |
---|
1334 | entity, and thus MAY be added or removed by any application along the |
---|
1335 | request/response chain. (However, <xref target="transfer.codings"/> places restrictions on |
---|
1336 | when certain transfer-codings may be used.) |
---|
1337 | </t> |
---|
1338 | <t> |
---|
1339 | The rules for when a message-body is allowed in a message differ for |
---|
1340 | requests and responses. |
---|
1341 | </t> |
---|
1342 | <t> |
---|
1343 | The presence of a message-body in a request is signaled by the |
---|
1344 | inclusion of a Content-Length or Transfer-Encoding header field in |
---|
1345 | the request's message-headers. |
---|
1346 | When a request message contains both a message-body of non-zero |
---|
1347 | length and a method that does not define any semantics for that |
---|
1348 | request message-body, then an origin server SHOULD either ignore |
---|
1349 | the message-body or respond with an appropriate error message |
---|
1350 | (e.g., 413). A proxy or gateway, when presented the same request, |
---|
1351 | SHOULD either forward the request inbound with the message-body or |
---|
1352 | ignore the message-body when determining a response. |
---|
1353 | </t> |
---|
1354 | <t> |
---|
1355 | For response messages, whether or not a message-body is included with |
---|
1356 | a message is dependent on both the request method and the response |
---|
1357 | status code (<xref target="status.code.and.reason.phrase"/>). All responses to the HEAD request method |
---|
1358 | MUST NOT include a message-body, even though the presence of entity-header |
---|
1359 | fields might lead one to believe they do. All 1xx |
---|
1360 | (informational), 204 (No Content), and 304 (Not Modified) responses |
---|
1361 | MUST NOT include a message-body. All other responses do include a |
---|
1362 | message-body, although it MAY be of zero length. |
---|
1363 | </t> |
---|
1364 | </section> |
---|
1365 | |
---|
1366 | <section title="Message Length" anchor="message.length"> |
---|
1367 | <t> |
---|
1368 | The transfer-length of a message is the length of the message-body as |
---|
1369 | it appears in the message; that is, after any transfer-codings have |
---|
1370 | been applied. When a message-body is included with a message, the |
---|
1371 | transfer-length of that body is determined by one of the following |
---|
1372 | (in order of precedence): |
---|
1373 | </t> |
---|
1374 | <t> |
---|
1375 | <list style="numbers"> |
---|
1376 | <t> |
---|
1377 | Any response message which "MUST NOT" include a message-body (such |
---|
1378 | as the 1xx, 204, and 304 responses and any response to a HEAD |
---|
1379 | request) is always terminated by the first empty line after the |
---|
1380 | header fields, regardless of the entity-header fields present in |
---|
1381 | the message. |
---|
1382 | </t> |
---|
1383 | <t> |
---|
1384 | If a Transfer-Encoding header field (<xref target="header.transfer-encoding"/>) |
---|
1385 | is present and the "chunked" transfer-coding (<xref target="transfer.codings"/>) |
---|
1386 | is used, the transfer-length is defined by the use of this transfer-coding. |
---|
1387 | If a Transfer-Encoding header field is present and the "chunked" transfer-coding |
---|
1388 | is not present, the transfer-length is defined by the sender closing the connection. |
---|
1389 | </t> |
---|
1390 | <t> |
---|
1391 | If a Content-Length header field (<xref target="header.content-length"/>) is present, its |
---|
1392 | value in OCTETs represents both the entity-length and the |
---|
1393 | transfer-length. The Content-Length header field MUST NOT be sent |
---|
1394 | if these two lengths are different (i.e., if a Transfer-Encoding |
---|
1395 | header field is present). If a message is received with both a |
---|
1396 | Transfer-Encoding header field and a Content-Length header field, |
---|
1397 | the latter MUST be ignored. |
---|
1398 | </t> |
---|
1399 | <t> |
---|
1400 | If the message uses the media type "multipart/byteranges", and the |
---|
1401 | transfer-length is not otherwise specified, then this self-delimiting |
---|
1402 | media type defines the transfer-length. This media type |
---|
1403 | MUST NOT be used unless the sender knows that the recipient can parse |
---|
1404 | it; the presence in a request of a Range header with multiple byte-range |
---|
1405 | specifiers from a 1.1 client implies that the client can parse |
---|
1406 | multipart/byteranges responses. |
---|
1407 | <list style="empty"><t> |
---|
1408 | A range header might be forwarded by a 1.0 proxy that does not |
---|
1409 | understand multipart/byteranges; in this case the server MUST |
---|
1410 | delimit the message using methods defined in items 1, 3 or 5 of |
---|
1411 | this section. |
---|
1412 | </t></list> |
---|
1413 | </t> |
---|
1414 | <t> |
---|
1415 | By the server closing the connection. (Closing the connection |
---|
1416 | cannot be used to indicate the end of a request body, since that |
---|
1417 | would leave no possibility for the server to send back a response.) |
---|
1418 | </t> |
---|
1419 | </list> |
---|
1420 | </t> |
---|
1421 | <t> |
---|
1422 | For compatibility with HTTP/1.0 applications, HTTP/1.1 requests |
---|
1423 | containing a message-body MUST include a valid Content-Length header |
---|
1424 | field unless the server is known to be HTTP/1.1 compliant. If a |
---|
1425 | request contains a message-body and a Content-Length is not given, |
---|
1426 | the server SHOULD respond with 400 (Bad Request) if it cannot |
---|
1427 | determine the length of the message, or with 411 (Length Required) if |
---|
1428 | it wishes to insist on receiving a valid Content-Length. |
---|
1429 | </t> |
---|
1430 | <t> |
---|
1431 | All HTTP/1.1 applications that receive entities MUST accept the |
---|
1432 | "chunked" transfer-coding (<xref target="transfer.codings"/>), thus allowing this mechanism |
---|
1433 | to be used for messages when the message length cannot be determined |
---|
1434 | in advance. |
---|
1435 | </t> |
---|
1436 | <t> |
---|
1437 | Messages MUST NOT include both a Content-Length header field and a |
---|
1438 | transfer-coding. If the message does include a |
---|
1439 | transfer-coding, the Content-Length MUST be ignored. |
---|
1440 | </t> |
---|
1441 | <t> |
---|
1442 | When a Content-Length is given in a message where a message-body is |
---|
1443 | allowed, its field value MUST exactly match the number of OCTETs in |
---|
1444 | the message-body. HTTP/1.1 user agents MUST notify the user when an |
---|
1445 | invalid length is received and detected. |
---|
1446 | </t> |
---|
1447 | </section> |
---|
1448 | |
---|
1449 | <section title="General Header Fields" anchor="general.header.fields"> |
---|
1450 | |
---|
1451 | <t> |
---|
1452 | There are a few header fields which have general applicability for |
---|
1453 | both request and response messages, but which do not apply to the |
---|
1454 | entity being transferred. These header fields apply only to the |
---|
1455 | message being transmitted. |
---|
1456 | </t> |
---|
1457 | <figure><iref primary="true" item="Grammar" subitem="general-header"/><artwork type="abnf2616"><![CDATA[ |
---|
1458 | general-header = Cache-Control ; [Part6], Section 3.2 |
---|
1459 | / Connection ; Section 8.1 |
---|
1460 | / Date ; Section 8.3 |
---|
1461 | / Pragma ; [Part6], Section 3.4 |
---|
1462 | / Trailer ; Section 8.6 |
---|
1463 | / Transfer-Encoding ; Section 8.7 |
---|
1464 | / Upgrade ; Section 8.8 |
---|
1465 | / Via ; Section 8.9 |
---|
1466 | / Warning ; [Part6], Section 3.6 |
---|
1467 | ]]></artwork></figure> |
---|
1468 | <t> |
---|
1469 | General-header field names can be extended reliably only in |
---|
1470 | combination with a change in the protocol version. However, new or |
---|
1471 | experimental header fields may be given the semantics of general |
---|
1472 | header fields if all parties in the communication recognize them to |
---|
1473 | be general-header fields. Unrecognized header fields are treated as |
---|
1474 | entity-header fields. |
---|
1475 | </t> |
---|
1476 | </section> |
---|
1477 | </section> |
---|
1478 | |
---|
1479 | <section title="Request" anchor="request"> |
---|
1480 | |
---|
1481 | <t> |
---|
1482 | A request message from a client to a server includes, within the |
---|
1483 | first line of that message, the method to be applied to the resource, |
---|
1484 | the identifier of the resource, and the protocol version in use. |
---|
1485 | </t> |
---|
1486 | <!-- Host ; should be moved here eventually --> |
---|
1487 | <figure><iref primary="true" item="Grammar" subitem="Request"/><artwork type="abnf2616"><![CDATA[ |
---|
1488 | Request = Request-Line ; Section 5.1 |
---|
1489 | *(( general-header ; Section 4.5 |
---|
1490 | / request-header ; [Part2], Section 3 |
---|
1491 | / entity-header ) CRLF ) ; [Part3], Section 3.1 |
---|
1492 | CRLF |
---|
1493 | [ message-body ] ; Section 4.3 |
---|
1494 | ]]></artwork></figure> |
---|
1495 | |
---|
1496 | <section title="Request-Line" anchor="request-line"> |
---|
1497 | |
---|
1498 | <t> |
---|
1499 | The Request-Line begins with a method token, followed by the |
---|
1500 | request-target and the protocol version, and ending with CRLF. The |
---|
1501 | elements are separated by SP characters. No CR or LF is allowed |
---|
1502 | except in the final CRLF sequence. |
---|
1503 | </t> |
---|
1504 | <figure><iref primary="true" item="Grammar" subitem="Request-Line"/><artwork type="abnf2616"><![CDATA[ |
---|
1505 | Request-Line = Method SP request-target SP HTTP-Version CRLF |
---|
1506 | ]]></artwork></figure> |
---|
1507 | |
---|
1508 | <section title="Method" anchor="method"> |
---|
1509 | |
---|
1510 | <t> |
---|
1511 | The Method token indicates the method to be performed on the |
---|
1512 | resource identified by the request-target. The method is case-sensitive. |
---|
1513 | </t> |
---|
1514 | <figure><iref primary="true" item="Grammar" subitem="Method"/><iref primary="true" item="Grammar" subitem="extension-method"/><artwork type="abnf2616"><![CDATA[ |
---|
1515 | Method = token |
---|
1516 | ]]></artwork></figure> |
---|
1517 | </section> |
---|
1518 | |
---|
1519 | <section title="request-target" anchor="request-target"> |
---|
1520 | |
---|
1521 | <t> |
---|
1522 | The request-target |
---|
1523 | identifies the resource upon which to apply the request. |
---|
1524 | </t> |
---|
1525 | <figure><iref primary="true" item="Grammar" subitem="request-target"/><artwork type="abnf2616"><![CDATA[ |
---|
1526 | request-target = "*" |
---|
1527 | / absolute-URI |
---|
1528 | / ( path-absolute [ "?" query ] ) |
---|
1529 | / authority |
---|
1530 | ]]></artwork></figure> |
---|
1531 | <t> |
---|
1532 | The four options for request-target are dependent on the nature of the |
---|
1533 | request. The asterisk "*" means that the request does not apply to a |
---|
1534 | particular resource, but to the server itself, and is only allowed |
---|
1535 | when the method used does not necessarily apply to a resource. One |
---|
1536 | example would be |
---|
1537 | </t> |
---|
1538 | <figure><artwork type="example"><![CDATA[ |
---|
1539 | OPTIONS * HTTP/1.1 |
---|
1540 | ]]></artwork></figure> |
---|
1541 | <t> |
---|
1542 | The absolute-URI form is REQUIRED when the request is being made to a |
---|
1543 | proxy. The proxy is requested to forward the request or service it |
---|
1544 | from a valid cache, and return the response. Note that the proxy MAY |
---|
1545 | forward the request on to another proxy or directly to the server |
---|
1546 | specified by the absolute-URI. In order to avoid request loops, a |
---|
1547 | proxy MUST be able to recognize all of its server names, including |
---|
1548 | any aliases, local variations, and the numeric IP address. An example |
---|
1549 | Request-Line would be: |
---|
1550 | </t> |
---|
1551 | <figure><artwork type="example"><![CDATA[ |
---|
1552 | GET http://www.example.org/pub/WWW/TheProject.html HTTP/1.1 |
---|
1553 | ]]></artwork></figure> |
---|
1554 | <t> |
---|
1555 | To allow for transition to absolute-URIs in all requests in future |
---|
1556 | versions of HTTP, all HTTP/1.1 servers MUST accept the absolute-URI |
---|
1557 | form in requests, even though HTTP/1.1 clients will only generate |
---|
1558 | them in requests to proxies. |
---|
1559 | </t> |
---|
1560 | <t> |
---|
1561 | The authority form is only used by the CONNECT method (Section 7.9 of <xref target="Part2"/>). |
---|
1562 | </t> |
---|
1563 | <t> |
---|
1564 | The most common form of request-target is that used to identify a |
---|
1565 | resource on an origin server or gateway. In this case the absolute |
---|
1566 | path of the URI MUST be transmitted (see <xref target="http.uri"/>, path-absolute) as |
---|
1567 | the request-target, and the network location of the URI (authority) MUST |
---|
1568 | be transmitted in a Host header field. For example, a client wishing |
---|
1569 | to retrieve the resource above directly from the origin server would |
---|
1570 | create a TCP connection to port 80 of the host "www.example.org" and send |
---|
1571 | the lines: |
---|
1572 | </t> |
---|
1573 | <figure><artwork type="example"><![CDATA[ |
---|
1574 | GET /pub/WWW/TheProject.html HTTP/1.1 |
---|
1575 | Host: www.example.org |
---|
1576 | ]]></artwork></figure> |
---|
1577 | <t> |
---|
1578 | followed by the remainder of the Request. Note that the absolute path |
---|
1579 | cannot be empty; if none is present in the original URI, it MUST be |
---|
1580 | given as "/" (the server root). |
---|
1581 | </t> |
---|
1582 | <t> |
---|
1583 | If a proxy receives a request without any path in the request-target and |
---|
1584 | the method specified is capable of supporting the asterisk form of |
---|
1585 | request-target, then the last proxy on the request chain MUST forward the |
---|
1586 | request with "*" as the final request-target. |
---|
1587 | </t> |
---|
1588 | <figure><preamble> |
---|
1589 | For example, the request |
---|
1590 | </preamble><artwork type="example"><![CDATA[ |
---|
1591 | OPTIONS http://www.example.org:8001 HTTP/1.1 |
---|
1592 | ]]></artwork></figure> |
---|
1593 | <figure><preamble> |
---|
1594 | would be forwarded by the proxy as |
---|
1595 | </preamble><artwork type="example"><![CDATA[ |
---|
1596 | OPTIONS * HTTP/1.1 |
---|
1597 | Host: www.example.org:8001 |
---|
1598 | ]]></artwork> |
---|
1599 | <postamble> |
---|
1600 | after connecting to port 8001 of host "www.example.org". |
---|
1601 | </postamble> |
---|
1602 | </figure> |
---|
1603 | <t> |
---|
1604 | The request-target is transmitted in the format specified in |
---|
1605 | <xref target="http.uri"/>. If the request-target is percent-encoded |
---|
1606 | (<xref target="RFC3986"/>, Section 2.1), the origin server |
---|
1607 | MUST decode the request-target in order to |
---|
1608 | properly interpret the request. Servers SHOULD respond to invalid |
---|
1609 | request-targets with an appropriate status code. |
---|
1610 | </t> |
---|
1611 | <t> |
---|
1612 | A transparent proxy MUST NOT rewrite the "path-absolute" part of the |
---|
1613 | received request-target when forwarding it to the next inbound server, |
---|
1614 | except as noted above to replace a null path-absolute with "/". |
---|
1615 | </t> |
---|
1616 | <t><list> |
---|
1617 | <t> |
---|
1618 | Note: The "no rewrite" rule prevents the proxy from changing the |
---|
1619 | meaning of the request when the origin server is improperly using |
---|
1620 | a non-reserved URI character for a reserved purpose. Implementors |
---|
1621 | should be aware that some pre-HTTP/1.1 proxies have been known to |
---|
1622 | rewrite the request-target. |
---|
1623 | </t> |
---|
1624 | </list></t> |
---|
1625 | <t> |
---|
1626 | HTTP does not place a pre-defined limit on the length of a request-target. |
---|
1627 | A server MUST be prepared to receive URIs of unbounded length and |
---|
1628 | respond with the 414 (URI Too Long) status if the received |
---|
1629 | request-target would be longer than the server wishes to handle |
---|
1630 | (see Section 8.4.15 of <xref target="Part2"/>). |
---|
1631 | </t> |
---|
1632 | <t> |
---|
1633 | Various ad-hoc limitations on request-target length are found in practice. |
---|
1634 | It is RECOMMENDED that all HTTP senders and recipients support |
---|
1635 | request-target lengths of 8000 or more OCTETs. |
---|
1636 | </t> |
---|
1637 | </section> |
---|
1638 | </section> |
---|
1639 | |
---|
1640 | <section title="The Resource Identified by a Request" anchor="the.resource.identified.by.a.request"> |
---|
1641 | <t> |
---|
1642 | The exact resource identified by an Internet request is determined by |
---|
1643 | examining both the request-target and the Host header field. |
---|
1644 | </t> |
---|
1645 | <t> |
---|
1646 | An origin server that does not allow resources to differ by the |
---|
1647 | requested host MAY ignore the Host header field value when |
---|
1648 | determining the resource identified by an HTTP/1.1 request. (But see |
---|
1649 | <xref target="changes.to.simplify.multi-homed.web.servers.and.conserve.ip.addresses"/> |
---|
1650 | for other requirements on Host support in HTTP/1.1.) |
---|
1651 | </t> |
---|
1652 | <t> |
---|
1653 | An origin server that does differentiate resources based on the host |
---|
1654 | requested (sometimes referred to as virtual hosts or vanity host |
---|
1655 | names) MUST use the following rules for determining the requested |
---|
1656 | resource on an HTTP/1.1 request: |
---|
1657 | <list style="numbers"> |
---|
1658 | <t>If request-target is an absolute-URI, the host is part of the |
---|
1659 | request-target. Any Host header field value in the request MUST be |
---|
1660 | ignored.</t> |
---|
1661 | <t>If the request-target is not an absolute-URI, and the request includes |
---|
1662 | a Host header field, the host is determined by the Host header |
---|
1663 | field value.</t> |
---|
1664 | <t>If the host as determined by rule 1 or 2 is not a valid host on |
---|
1665 | the server, the response MUST be a 400 (Bad Request) error message.</t> |
---|
1666 | </list> |
---|
1667 | </t> |
---|
1668 | <t> |
---|
1669 | Recipients of an HTTP/1.0 request that lacks a Host header field MAY |
---|
1670 | attempt to use heuristics (e.g., examination of the URI path for |
---|
1671 | something unique to a particular host) in order to determine what |
---|
1672 | exact resource is being requested. |
---|
1673 | </t> |
---|
1674 | </section> |
---|
1675 | |
---|
1676 | </section> |
---|
1677 | |
---|
1678 | |
---|
1679 | <section title="Response" anchor="response"> |
---|
1680 | |
---|
1681 | <t> |
---|
1682 | After receiving and interpreting a request message, a server responds |
---|
1683 | with an HTTP response message. |
---|
1684 | </t> |
---|
1685 | <figure><iref primary="true" item="Grammar" subitem="Response"/><artwork type="abnf2616"><![CDATA[ |
---|
1686 | Response = Status-Line ; Section 6.1 |
---|
1687 | *(( general-header ; Section 4.5 |
---|
1688 | / response-header ; [Part2], Section 5 |
---|
1689 | / entity-header ) CRLF ) ; [Part3], Section 3.1 |
---|
1690 | CRLF |
---|
1691 | [ message-body ] ; Section 4.3 |
---|
1692 | ]]></artwork></figure> |
---|
1693 | |
---|
1694 | <section title="Status-Line" anchor="status-line"> |
---|
1695 | |
---|
1696 | <t> |
---|
1697 | The first line of a Response message is the Status-Line, consisting |
---|
1698 | of the protocol version followed by a numeric status code and its |
---|
1699 | associated textual phrase, with each element separated by SP |
---|
1700 | characters. No CR or LF is allowed except in the final CRLF sequence. |
---|
1701 | </t> |
---|
1702 | <figure><iref primary="true" item="Grammar" subitem="Status-Line"/><artwork type="abnf2616"><![CDATA[ |
---|
1703 | Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF |
---|
1704 | ]]></artwork></figure> |
---|
1705 | |
---|
1706 | <section title="Status Code and Reason Phrase" anchor="status.code.and.reason.phrase"> |
---|
1707 | |
---|
1708 | |
---|
1709 | <t> |
---|
1710 | The Status-Code element is a 3-digit integer result code of the |
---|
1711 | attempt to understand and satisfy the request. These codes are fully |
---|
1712 | defined in Section 8 of <xref target="Part2"/>. The Reason Phrase exists for the sole |
---|
1713 | purpose of providing a textual description associated with the numeric |
---|
1714 | status code, out of deference to earlier Internet application protocols |
---|
1715 | that were more frequently used with interactive text clients. |
---|
1716 | A client SHOULD ignore the content of the Reason Phrase. |
---|
1717 | </t> |
---|
1718 | <t> |
---|
1719 | The first digit of the Status-Code defines the class of response. The |
---|
1720 | last two digits do not have any categorization role. There are 5 |
---|
1721 | values for the first digit: |
---|
1722 | <list style="symbols"> |
---|
1723 | <t> |
---|
1724 | 1xx: Informational - Request received, continuing process |
---|
1725 | </t> |
---|
1726 | <t> |
---|
1727 | 2xx: Success - The action was successfully received, |
---|
1728 | understood, and accepted |
---|
1729 | </t> |
---|
1730 | <t> |
---|
1731 | 3xx: Redirection - Further action must be taken in order to |
---|
1732 | complete the request |
---|
1733 | </t> |
---|
1734 | <t> |
---|
1735 | 4xx: Client Error - The request contains bad syntax or cannot |
---|
1736 | be fulfilled |
---|
1737 | </t> |
---|
1738 | <t> |
---|
1739 | 5xx: Server Error - The server failed to fulfill an apparently |
---|
1740 | valid request |
---|
1741 | </t> |
---|
1742 | </list> |
---|
1743 | </t> |
---|
1744 | <figure><iref primary="true" item="Grammar" subitem="Status-Code"/><iref primary="true" item="Grammar" subitem="extension-code"/><iref primary="true" item="Grammar" subitem="Reason-Phrase"/><artwork type="abnf2616"><![CDATA[ |
---|
1745 | Status-Code = 3DIGIT |
---|
1746 | Reason-Phrase = *( WSP / VCHAR / obs-text ) |
---|
1747 | ]]></artwork></figure> |
---|
1748 | </section> |
---|
1749 | </section> |
---|
1750 | |
---|
1751 | </section> |
---|
1752 | |
---|
1753 | |
---|
1754 | <section title="Connections" anchor="connections"> |
---|
1755 | |
---|
1756 | <section title="Persistent Connections" anchor="persistent.connections"> |
---|
1757 | |
---|
1758 | <section title="Purpose" anchor="persistent.purpose"> |
---|
1759 | <t> |
---|
1760 | Prior to persistent connections, a separate TCP connection was |
---|
1761 | established to fetch each URL, increasing the load on HTTP servers |
---|
1762 | and causing congestion on the Internet. The use of inline images and |
---|
1763 | other associated data often require a client to make multiple |
---|
1764 | requests of the same server in a short amount of time. Analysis of |
---|
1765 | these performance problems and results from a prototype |
---|
1766 | implementation are available <xref target="Pad1995"/> <xref target="Spe"/>. Implementation experience and |
---|
1767 | measurements of actual HTTP/1.1 implementations show good |
---|
1768 | results <xref target="Nie1997"/>. Alternatives have also been explored, for example, |
---|
1769 | T/TCP <xref target="Tou1998"/>. |
---|
1770 | </t> |
---|
1771 | <t> |
---|
1772 | Persistent HTTP connections have a number of advantages: |
---|
1773 | <list style="symbols"> |
---|
1774 | <t> |
---|
1775 | By opening and closing fewer TCP connections, CPU time is saved |
---|
1776 | in routers and hosts (clients, servers, proxies, gateways, |
---|
1777 | tunnels, or caches), and memory used for TCP protocol control |
---|
1778 | blocks can be saved in hosts. |
---|
1779 | </t> |
---|
1780 | <t> |
---|
1781 | HTTP requests and responses can be pipelined on a connection. |
---|
1782 | Pipelining allows a client to make multiple requests without |
---|
1783 | waiting for each response, allowing a single TCP connection to |
---|
1784 | be used much more efficiently, with much lower elapsed time. |
---|
1785 | </t> |
---|
1786 | <t> |
---|
1787 | Network congestion is reduced by reducing the number of packets |
---|
1788 | caused by TCP opens, and by allowing TCP sufficient time to |
---|
1789 | determine the congestion state of the network. |
---|
1790 | </t> |
---|
1791 | <t> |
---|
1792 | Latency on subsequent requests is reduced since there is no time |
---|
1793 | spent in TCP's connection opening handshake. |
---|
1794 | </t> |
---|
1795 | <t> |
---|
1796 | HTTP can evolve more gracefully, since errors can be reported |
---|
1797 | without the penalty of closing the TCP connection. Clients using |
---|
1798 | future versions of HTTP might optimistically try a new feature, |
---|
1799 | but if communicating with an older server, retry with old |
---|
1800 | semantics after an error is reported. |
---|
1801 | </t> |
---|
1802 | </list> |
---|
1803 | </t> |
---|
1804 | <t> |
---|
1805 | HTTP implementations SHOULD implement persistent connections. |
---|
1806 | </t> |
---|
1807 | </section> |
---|
1808 | |
---|
1809 | <section title="Overall Operation" anchor="persistent.overall"> |
---|
1810 | <t> |
---|
1811 | A significant difference between HTTP/1.1 and earlier versions of |
---|
1812 | HTTP is that persistent connections are the default behavior of any |
---|
1813 | HTTP connection. That is, unless otherwise indicated, the client |
---|
1814 | SHOULD assume that the server will maintain a persistent connection, |
---|
1815 | even after error responses from the server. |
---|
1816 | </t> |
---|
1817 | <t> |
---|
1818 | Persistent connections provide a mechanism by which a client and a |
---|
1819 | server can signal the close of a TCP connection. This signaling takes |
---|
1820 | place using the Connection header field (<xref target="header.connection"/>). Once a close |
---|
1821 | has been signaled, the client MUST NOT send any more requests on that |
---|
1822 | connection. |
---|
1823 | </t> |
---|
1824 | |
---|
1825 | <section title="Negotiation" anchor="persistent.negotiation"> |
---|
1826 | <t> |
---|
1827 | An HTTP/1.1 server MAY assume that a HTTP/1.1 client intends to |
---|
1828 | maintain a persistent connection unless a Connection header including |
---|
1829 | the connection-token "close" was sent in the request. If the server |
---|
1830 | chooses to close the connection immediately after sending the |
---|
1831 | response, it SHOULD send a Connection header including the |
---|
1832 | connection-token close. |
---|
1833 | </t> |
---|
1834 | <t> |
---|
1835 | An HTTP/1.1 client MAY expect a connection to remain open, but would |
---|
1836 | decide to keep it open based on whether the response from a server |
---|
1837 | contains a Connection header with the connection-token close. In case |
---|
1838 | the client does not want to maintain a connection for more than that |
---|
1839 | request, it SHOULD send a Connection header including the |
---|
1840 | connection-token close. |
---|
1841 | </t> |
---|
1842 | <t> |
---|
1843 | If either the client or the server sends the close token in the |
---|
1844 | Connection header, that request becomes the last one for the |
---|
1845 | connection. |
---|
1846 | </t> |
---|
1847 | <t> |
---|
1848 | Clients and servers SHOULD NOT assume that a persistent connection is |
---|
1849 | maintained for HTTP versions less than 1.1 unless it is explicitly |
---|
1850 | signaled. See <xref target="compatibility.with.http.1.0.persistent.connections"/> for more information on backward |
---|
1851 | compatibility with HTTP/1.0 clients. |
---|
1852 | </t> |
---|
1853 | <t> |
---|
1854 | In order to remain persistent, all messages on the connection MUST |
---|
1855 | have a self-defined message length (i.e., one not defined by closure |
---|
1856 | of the connection), as described in <xref target="message.length"/>. |
---|
1857 | </t> |
---|
1858 | </section> |
---|
1859 | |
---|
1860 | <section title="Pipelining" anchor="pipelining"> |
---|
1861 | <t> |
---|
1862 | A client that supports persistent connections MAY "pipeline" its |
---|
1863 | requests (i.e., send multiple requests without waiting for each |
---|
1864 | response). A server MUST send its responses to those requests in the |
---|
1865 | same order that the requests were received. |
---|
1866 | </t> |
---|
1867 | <t> |
---|
1868 | Clients which assume persistent connections and pipeline immediately |
---|
1869 | after connection establishment SHOULD be prepared to retry their |
---|
1870 | connection if the first pipelined attempt fails. If a client does |
---|
1871 | such a retry, it MUST NOT pipeline before it knows the connection is |
---|
1872 | persistent. Clients MUST also be prepared to resend their requests if |
---|
1873 | the server closes the connection before sending all of the |
---|
1874 | corresponding responses. |
---|
1875 | </t> |
---|
1876 | <t> |
---|
1877 | Clients SHOULD NOT pipeline requests using non-idempotent methods or |
---|
1878 | non-idempotent sequences of methods (see Section 7.1.2 of <xref target="Part2"/>). Otherwise, a |
---|
1879 | premature termination of the transport connection could lead to |
---|
1880 | indeterminate results. A client wishing to send a non-idempotent |
---|
1881 | request SHOULD wait to send that request until it has received the |
---|
1882 | response status for the previous request. |
---|
1883 | </t> |
---|
1884 | </section> |
---|
1885 | </section> |
---|
1886 | |
---|
1887 | <section title="Proxy Servers" anchor="persistent.proxy"> |
---|
1888 | <t> |
---|
1889 | It is especially important that proxies correctly implement the |
---|
1890 | properties of the Connection header field as specified in <xref target="header.connection"/>. |
---|
1891 | </t> |
---|
1892 | <t> |
---|
1893 | The proxy server MUST signal persistent connections separately with |
---|
1894 | its clients and the origin servers (or other proxy servers) that it |
---|
1895 | connects to. Each persistent connection applies to only one transport |
---|
1896 | link. |
---|
1897 | </t> |
---|
1898 | <t> |
---|
1899 | A proxy server MUST NOT establish a HTTP/1.1 persistent connection |
---|
1900 | with an HTTP/1.0 client (but see Section 19.7.1 of <xref target="RFC2068"/> |
---|
1901 | for information and discussion of the problems with the Keep-Alive header |
---|
1902 | implemented by many HTTP/1.0 clients). |
---|
1903 | </t> |
---|
1904 | </section> |
---|
1905 | |
---|
1906 | <section title="Practical Considerations" anchor="persistent.practical"> |
---|
1907 | <t> |
---|
1908 | Servers will usually have some time-out value beyond which they will |
---|
1909 | no longer maintain an inactive connection. Proxy servers might make |
---|
1910 | this a higher value since it is likely that the client will be making |
---|
1911 | more connections through the same server. The use of persistent |
---|
1912 | connections places no requirements on the length (or existence) of |
---|
1913 | this time-out for either the client or the server. |
---|
1914 | </t> |
---|
1915 | <t> |
---|
1916 | When a client or server wishes to time-out it SHOULD issue a graceful |
---|
1917 | close on the transport connection. Clients and servers SHOULD both |
---|
1918 | constantly watch for the other side of the transport close, and |
---|
1919 | respond to it as appropriate. If a client or server does not detect |
---|
1920 | the other side's close promptly it could cause unnecessary resource |
---|
1921 | drain on the network. |
---|
1922 | </t> |
---|
1923 | <t> |
---|
1924 | A client, server, or proxy MAY close the transport connection at any |
---|
1925 | time. For example, a client might have started to send a new request |
---|
1926 | at the same time that the server has decided to close the "idle" |
---|
1927 | connection. From the server's point of view, the connection is being |
---|
1928 | closed while it was idle, but from the client's point of view, a |
---|
1929 | request is in progress. |
---|
1930 | </t> |
---|
1931 | <t> |
---|
1932 | This means that clients, servers, and proxies MUST be able to recover |
---|
1933 | from asynchronous close events. Client software SHOULD reopen the |
---|
1934 | transport connection and retransmit the aborted sequence of requests |
---|
1935 | without user interaction so long as the request sequence is |
---|
1936 | idempotent (see Section 7.1.2 of <xref target="Part2"/>). Non-idempotent methods or sequences |
---|
1937 | MUST NOT be automatically retried, although user agents MAY offer a |
---|
1938 | human operator the choice of retrying the request(s). Confirmation by |
---|
1939 | user-agent software with semantic understanding of the application |
---|
1940 | MAY substitute for user confirmation. The automatic retry SHOULD NOT |
---|
1941 | be repeated if the second sequence of requests fails. |
---|
1942 | </t> |
---|
1943 | <t> |
---|
1944 | Servers SHOULD always respond to at least one request per connection, |
---|
1945 | if at all possible. Servers SHOULD NOT close a connection in the |
---|
1946 | middle of transmitting a response, unless a network or client failure |
---|
1947 | is suspected. |
---|
1948 | </t> |
---|
1949 | <t> |
---|
1950 | Clients that use persistent connections SHOULD limit the number of |
---|
1951 | simultaneous connections that they maintain to a given server. A |
---|
1952 | single-user client SHOULD NOT maintain more than 2 connections with |
---|
1953 | any server or proxy. A proxy SHOULD use up to 2*N connections to |
---|
1954 | another server or proxy, where N is the number of simultaneously |
---|
1955 | active users. These guidelines are intended to improve HTTP response |
---|
1956 | times and avoid congestion. |
---|
1957 | </t> |
---|
1958 | </section> |
---|
1959 | </section> |
---|
1960 | |
---|
1961 | <section title="Message Transmission Requirements" anchor="message.transmission.requirements"> |
---|
1962 | |
---|
1963 | <section title="Persistent Connections and Flow Control" anchor="persistent.flow"> |
---|
1964 | <t> |
---|
1965 | HTTP/1.1 servers SHOULD maintain persistent connections and use TCP's |
---|
1966 | flow control mechanisms to resolve temporary overloads, rather than |
---|
1967 | terminating connections with the expectation that clients will retry. |
---|
1968 | The latter technique can exacerbate network congestion. |
---|
1969 | </t> |
---|
1970 | </section> |
---|
1971 | |
---|
1972 | <section title="Monitoring Connections for Error Status Messages" anchor="persistent.monitor"> |
---|
1973 | <t> |
---|
1974 | An HTTP/1.1 (or later) client sending a message-body SHOULD monitor |
---|
1975 | the network connection for an error status while it is transmitting |
---|
1976 | the request. If the client sees an error status, it SHOULD |
---|
1977 | immediately cease transmitting the body. If the body is being sent |
---|
1978 | using a "chunked" encoding (<xref target="transfer.codings"/>), a zero length chunk and |
---|
1979 | empty trailer MAY be used to prematurely mark the end of the message. |
---|
1980 | If the body was preceded by a Content-Length header, the client MUST |
---|
1981 | close the connection. |
---|
1982 | </t> |
---|
1983 | </section> |
---|
1984 | |
---|
1985 | <section title="Use of the 100 (Continue) Status" anchor="use.of.the.100.status"> |
---|
1986 | <t> |
---|
1987 | The purpose of the 100 (Continue) status (see Section 8.1.1 of <xref target="Part2"/>) is to |
---|
1988 | allow a client that is sending a request message with a request body |
---|
1989 | to determine if the origin server is willing to accept the request |
---|
1990 | (based on the request headers) before the client sends the request |
---|
1991 | body. In some cases, it might either be inappropriate or highly |
---|
1992 | inefficient for the client to send the body if the server will reject |
---|
1993 | the message without looking at the body. |
---|
1994 | </t> |
---|
1995 | <t> |
---|
1996 | Requirements for HTTP/1.1 clients: |
---|
1997 | <list style="symbols"> |
---|
1998 | <t> |
---|
1999 | If a client will wait for a 100 (Continue) response before |
---|
2000 | sending the request body, it MUST send an Expect request-header |
---|
2001 | field (Section 9.2 of <xref target="Part2"/>) with the "100-continue" expectation. |
---|
2002 | </t> |
---|
2003 | <t> |
---|
2004 | A client MUST NOT send an Expect request-header field (Section 9.2 of <xref target="Part2"/>) |
---|
2005 | with the "100-continue" expectation if it does not intend |
---|
2006 | to send a request body. |
---|
2007 | </t> |
---|
2008 | </list> |
---|
2009 | </t> |
---|
2010 | <t> |
---|
2011 | Because of the presence of older implementations, the protocol allows |
---|
2012 | ambiguous situations in which a client may send "Expect: 100-continue" |
---|
2013 | without receiving either a 417 (Expectation Failed) status |
---|
2014 | or a 100 (Continue) status. Therefore, when a client sends this |
---|
2015 | header field to an origin server (possibly via a proxy) from which it |
---|
2016 | has never seen a 100 (Continue) status, the client SHOULD NOT wait |
---|
2017 | for an indefinite period before sending the request body. |
---|
2018 | </t> |
---|
2019 | <t> |
---|
2020 | Requirements for HTTP/1.1 origin servers: |
---|
2021 | <list style="symbols"> |
---|
2022 | <t> Upon receiving a request which includes an Expect request-header |
---|
2023 | field with the "100-continue" expectation, an origin server MUST |
---|
2024 | either respond with 100 (Continue) status and continue to read |
---|
2025 | from the input stream, or respond with a final status code. The |
---|
2026 | origin server MUST NOT wait for the request body before sending |
---|
2027 | the 100 (Continue) response. If it responds with a final status |
---|
2028 | code, it MAY close the transport connection or it MAY continue |
---|
2029 | to read and discard the rest of the request. It MUST NOT |
---|
2030 | perform the requested method if it returns a final status code. |
---|
2031 | </t> |
---|
2032 | <t> An origin server SHOULD NOT send a 100 (Continue) response if |
---|
2033 | the request message does not include an Expect request-header |
---|
2034 | field with the "100-continue" expectation, and MUST NOT send a |
---|
2035 | 100 (Continue) response if such a request comes from an HTTP/1.0 |
---|
2036 | (or earlier) client. There is an exception to this rule: for |
---|
2037 | compatibility with <xref target="RFC2068"/>, a server MAY send a 100 (Continue) |
---|
2038 | status in response to an HTTP/1.1 PUT or POST request that does |
---|
2039 | not include an Expect request-header field with the "100-continue" |
---|
2040 | expectation. This exception, the purpose of which is |
---|
2041 | to minimize any client processing delays associated with an |
---|
2042 | undeclared wait for 100 (Continue) status, applies only to |
---|
2043 | HTTP/1.1 requests, and not to requests with any other HTTP-version |
---|
2044 | value. |
---|
2045 | </t> |
---|
2046 | <t> An origin server MAY omit a 100 (Continue) response if it has |
---|
2047 | already received some or all of the request body for the |
---|
2048 | corresponding request. |
---|
2049 | </t> |
---|
2050 | <t> An origin server that sends a 100 (Continue) response MUST |
---|
2051 | ultimately send a final status code, once the request body is |
---|
2052 | received and processed, unless it terminates the transport |
---|
2053 | connection prematurely. |
---|
2054 | </t> |
---|
2055 | <t> If an origin server receives a request that does not include an |
---|
2056 | Expect request-header field with the "100-continue" expectation, |
---|
2057 | the request includes a request body, and the server responds |
---|
2058 | with a final status code before reading the entire request body |
---|
2059 | from the transport connection, then the server SHOULD NOT close |
---|
2060 | the transport connection until it has read the entire request, |
---|
2061 | or until the client closes the connection. Otherwise, the client |
---|
2062 | might not reliably receive the response message. However, this |
---|
2063 | requirement is not be construed as preventing a server from |
---|
2064 | defending itself against denial-of-service attacks, or from |
---|
2065 | badly broken client implementations. |
---|
2066 | </t> |
---|
2067 | </list> |
---|
2068 | </t> |
---|
2069 | <t> |
---|
2070 | Requirements for HTTP/1.1 proxies: |
---|
2071 | <list style="symbols"> |
---|
2072 | <t> If a proxy receives a request that includes an Expect request-header |
---|
2073 | field with the "100-continue" expectation, and the proxy |
---|
2074 | either knows that the next-hop server complies with HTTP/1.1 or |
---|
2075 | higher, or does not know the HTTP version of the next-hop |
---|
2076 | server, it MUST forward the request, including the Expect header |
---|
2077 | field. |
---|
2078 | </t> |
---|
2079 | <t> If the proxy knows that the version of the next-hop server is |
---|
2080 | HTTP/1.0 or lower, it MUST NOT forward the request, and it MUST |
---|
2081 | respond with a 417 (Expectation Failed) status. |
---|
2082 | </t> |
---|
2083 | <t> Proxies SHOULD maintain a cache recording the HTTP version |
---|
2084 | numbers received from recently-referenced next-hop servers. |
---|
2085 | </t> |
---|
2086 | <t> A proxy MUST NOT forward a 100 (Continue) response if the |
---|
2087 | request message was received from an HTTP/1.0 (or earlier) |
---|
2088 | client and did not include an Expect request-header field with |
---|
2089 | the "100-continue" expectation. This requirement overrides the |
---|
2090 | general rule for forwarding of 1xx responses (see Section 8.1 of <xref target="Part2"/>). |
---|
2091 | </t> |
---|
2092 | </list> |
---|
2093 | </t> |
---|
2094 | </section> |
---|
2095 | |
---|
2096 | <section title="Client Behavior if Server Prematurely Closes Connection" anchor="connection.premature"> |
---|
2097 | <t> |
---|
2098 | If an HTTP/1.1 client sends a request which includes a request body, |
---|
2099 | but which does not include an Expect request-header field with the |
---|
2100 | "100-continue" expectation, and if the client is not directly |
---|
2101 | connected to an HTTP/1.1 origin server, and if the client sees the |
---|
2102 | connection close before receiving any status from the server, the |
---|
2103 | client SHOULD retry the request. If the client does retry this |
---|
2104 | request, it MAY use the following "binary exponential backoff" |
---|
2105 | algorithm to be assured of obtaining a reliable response: |
---|
2106 | <list style="numbers"> |
---|
2107 | <t> |
---|
2108 | Initiate a new connection to the server |
---|
2109 | </t> |
---|
2110 | <t> |
---|
2111 | Transmit the request-headers |
---|
2112 | </t> |
---|
2113 | <t> |
---|
2114 | Initialize a variable R to the estimated round-trip time to the |
---|
2115 | server (e.g., based on the time it took to establish the |
---|
2116 | connection), or to a constant value of 5 seconds if the round-trip |
---|
2117 | time is not available. |
---|
2118 | </t> |
---|
2119 | <t> |
---|
2120 | Compute T = R * (2**N), where N is the number of previous |
---|
2121 | retries of this request. |
---|
2122 | </t> |
---|
2123 | <t> |
---|
2124 | Wait either for an error response from the server, or for T |
---|
2125 | seconds (whichever comes first) |
---|
2126 | </t> |
---|
2127 | <t> |
---|
2128 | If no error response is received, after T seconds transmit the |
---|
2129 | body of the request. |
---|
2130 | </t> |
---|
2131 | <t> |
---|
2132 | If client sees that the connection is closed prematurely, |
---|
2133 | repeat from step 1 until the request is accepted, an error |
---|
2134 | response is received, or the user becomes impatient and |
---|
2135 | terminates the retry process. |
---|
2136 | </t> |
---|
2137 | </list> |
---|
2138 | </t> |
---|
2139 | <t> |
---|
2140 | If at any point an error status is received, the client |
---|
2141 | <list style="symbols"> |
---|
2142 | <t>SHOULD NOT continue and</t> |
---|
2143 | |
---|
2144 | <t>SHOULD close the connection if it has not completed sending the |
---|
2145 | request message.</t> |
---|
2146 | </list> |
---|
2147 | </t> |
---|
2148 | </section> |
---|
2149 | </section> |
---|
2150 | </section> |
---|
2151 | |
---|
2152 | |
---|
2153 | <section title="Header Field Definitions" anchor="header.fields"> |
---|
2154 | <t> |
---|
2155 | This section defines the syntax and semantics of HTTP/1.1 header fields |
---|
2156 | related to message framing and transport protocols. |
---|
2157 | </t> |
---|
2158 | <t> |
---|
2159 | For entity-header fields, both sender and recipient refer to either the |
---|
2160 | client or the server, depending on who sends and who receives the entity. |
---|
2161 | </t> |
---|
2162 | |
---|
2163 | <section title="Connection" anchor="header.connection"> |
---|
2164 | <iref primary="true" item="Connection header"/> |
---|
2165 | <iref primary="true" item="Headers" subitem="Connection"/> |
---|
2166 | |
---|
2167 | |
---|
2168 | |
---|
2169 | <t> |
---|
2170 | The general-header field "Connection" allows the sender to specify |
---|
2171 | options that are desired for that particular connection and MUST NOT |
---|
2172 | be communicated by proxies over further connections. |
---|
2173 | </t> |
---|
2174 | <t> |
---|
2175 | The Connection header's value has the following grammar: |
---|
2176 | </t> |
---|
2177 | <figure><iref primary="true" item="Grammar" subitem="Connection"/><iref primary="true" item="Grammar" subitem="Connection-v"/><iref primary="true" item="Grammar" subitem="connection-token"/><artwork type="abnf2616"><![CDATA[ |
---|
2178 | Connection = "Connection" ":" OWS Connection-v |
---|
2179 | Connection-v = 1#connection-token |
---|
2180 | connection-token = token |
---|
2181 | ]]></artwork></figure> |
---|
2182 | <t> |
---|
2183 | HTTP/1.1 proxies MUST parse the Connection header field before a |
---|
2184 | message is forwarded and, for each connection-token in this field, |
---|
2185 | remove any header field(s) from the message with the same name as the |
---|
2186 | connection-token. Connection options are signaled by the presence of |
---|
2187 | a connection-token in the Connection header field, not by any |
---|
2188 | corresponding additional header field(s), since the additional header |
---|
2189 | field may not be sent if there are no parameters associated with that |
---|
2190 | connection option. |
---|
2191 | </t> |
---|
2192 | <t> |
---|
2193 | Message headers listed in the Connection header MUST NOT include |
---|
2194 | end-to-end headers, such as Cache-Control. |
---|
2195 | </t> |
---|
2196 | <t> |
---|
2197 | HTTP/1.1 defines the "close" connection option for the sender to |
---|
2198 | signal that the connection will be closed after completion of the |
---|
2199 | response. For example, |
---|
2200 | </t> |
---|
2201 | <figure><artwork type="example"><![CDATA[ |
---|
2202 | Connection: close |
---|
2203 | ]]></artwork></figure> |
---|
2204 | <t> |
---|
2205 | in either the request or the response header fields indicates that |
---|
2206 | the connection SHOULD NOT be considered `persistent' (<xref target="persistent.connections"/>) |
---|
2207 | after the current request/response is complete. |
---|
2208 | </t> |
---|
2209 | <t> |
---|
2210 | An HTTP/1.1 client that does not support persistent connections MUST |
---|
2211 | include the "close" connection option in every request message. |
---|
2212 | </t> |
---|
2213 | <t> |
---|
2214 | An HTTP/1.1 server that does not support persistent connections MUST |
---|
2215 | include the "close" connection option in every response message that |
---|
2216 | does not have a 1xx (informational) status code. |
---|
2217 | </t> |
---|
2218 | <t> |
---|
2219 | A system receiving an HTTP/1.0 (or lower-version) message that |
---|
2220 | includes a Connection header MUST, for each connection-token in this |
---|
2221 | field, remove and ignore any header field(s) from the message with |
---|
2222 | the same name as the connection-token. This protects against mistaken |
---|
2223 | forwarding of such header fields by pre-HTTP/1.1 proxies. See <xref target="compatibility.with.http.1.0.persistent.connections"/>. |
---|
2224 | </t> |
---|
2225 | </section> |
---|
2226 | |
---|
2227 | <section title="Content-Length" anchor="header.content-length"> |
---|
2228 | <iref primary="true" item="Content-Length header"/> |
---|
2229 | <iref primary="true" item="Headers" subitem="Content-Length"/> |
---|
2230 | |
---|
2231 | |
---|
2232 | <t> |
---|
2233 | The entity-header field "Content-Length" indicates the size of the |
---|
2234 | entity-body, in number of OCTETs, sent to the recipient or, |
---|
2235 | in the case of the HEAD method, the size of the entity-body that |
---|
2236 | would have been sent had the request been a GET. |
---|
2237 | </t> |
---|
2238 | <figure><iref primary="true" item="Grammar" subitem="Content-Length"/><iref primary="true" item="Grammar" subitem="Content-Length-v"/><artwork type="abnf2616"><![CDATA[ |
---|
2239 | Content-Length = "Content-Length" ":" OWS 1*Content-Length-v |
---|
2240 | Content-Length-v = 1*DIGIT |
---|
2241 | ]]></artwork></figure> |
---|
2242 | <t> |
---|
2243 | An example is |
---|
2244 | </t> |
---|
2245 | <figure><artwork type="example"><![CDATA[ |
---|
2246 | Content-Length: 3495 |
---|
2247 | ]]></artwork></figure> |
---|
2248 | <t> |
---|
2249 | Applications SHOULD use this field to indicate the transfer-length of |
---|
2250 | the message-body, unless this is prohibited by the rules in <xref target="message.length"/>. |
---|
2251 | </t> |
---|
2252 | <t> |
---|
2253 | Any Content-Length greater than or equal to zero is a valid value. |
---|
2254 | <xref target="message.length"/> describes how to determine the length of a message-body |
---|
2255 | if a Content-Length is not given. |
---|
2256 | </t> |
---|
2257 | <t> |
---|
2258 | Note that the meaning of this field is significantly different from |
---|
2259 | the corresponding definition in MIME, where it is an optional field |
---|
2260 | used within the "message/external-body" content-type. In HTTP, it |
---|
2261 | SHOULD be sent whenever the message's length can be determined prior |
---|
2262 | to being transferred, unless this is prohibited by the rules in |
---|
2263 | <xref target="message.length"/>. |
---|
2264 | </t> |
---|
2265 | </section> |
---|
2266 | |
---|
2267 | <section title="Date" anchor="header.date"> |
---|
2268 | <iref primary="true" item="Date header"/> |
---|
2269 | <iref primary="true" item="Headers" subitem="Date"/> |
---|
2270 | |
---|
2271 | |
---|
2272 | <t> |
---|
2273 | The general-header field "Date" represents the date and time at which |
---|
2274 | the message was originated, having the same semantics as orig-date in |
---|
2275 | Section 3.6.1 of <xref target="RFC5322"/>. The field value is an |
---|
2276 | HTTP-date, as described in <xref target="date.time.formats.full.date"/>; |
---|
2277 | it MUST be sent in rfc1123-date format. |
---|
2278 | </t> |
---|
2279 | <figure><iref primary="true" item="Grammar" subitem="Date"/><iref primary="true" item="Grammar" subitem="Date-v"/><artwork type="abnf2616"><![CDATA[ |
---|
2280 | Date = "Date" ":" OWS Date-v |
---|
2281 | Date-v = HTTP-date |
---|
2282 | ]]></artwork></figure> |
---|
2283 | <t> |
---|
2284 | An example is |
---|
2285 | </t> |
---|
2286 | <figure><artwork type="example"><![CDATA[ |
---|
2287 | Date: Tue, 15 Nov 1994 08:12:31 GMT |
---|
2288 | ]]></artwork></figure> |
---|
2289 | <t> |
---|
2290 | Origin servers MUST include a Date header field in all responses, |
---|
2291 | except in these cases: |
---|
2292 | <list style="numbers"> |
---|
2293 | <t>If the response status code is 100 (Continue) or 101 (Switching |
---|
2294 | Protocols), the response MAY include a Date header field, at |
---|
2295 | the server's option.</t> |
---|
2296 | |
---|
2297 | <t>If the response status code conveys a server error, e.g. 500 |
---|
2298 | (Internal Server Error) or 503 (Service Unavailable), and it is |
---|
2299 | inconvenient or impossible to generate a valid Date.</t> |
---|
2300 | |
---|
2301 | <t>If the server does not have a clock that can provide a |
---|
2302 | reasonable approximation of the current time, its responses |
---|
2303 | MUST NOT include a Date header field. In this case, the rules |
---|
2304 | in <xref target="clockless.origin.server.operation"/> MUST be followed.</t> |
---|
2305 | </list> |
---|
2306 | </t> |
---|
2307 | <t> |
---|
2308 | A received message that does not have a Date header field MUST be |
---|
2309 | assigned one by the recipient if the message will be cached by that |
---|
2310 | recipient or gatewayed via a protocol which requires a Date. An HTTP |
---|
2311 | implementation without a clock MUST NOT cache responses without |
---|
2312 | revalidating them on every use. An HTTP cache, especially a shared |
---|
2313 | cache, SHOULD use a mechanism, such as NTP <xref target="RFC1305"/>, to synchronize its |
---|
2314 | clock with a reliable external standard. |
---|
2315 | </t> |
---|
2316 | <t> |
---|
2317 | Clients SHOULD only send a Date header field in messages that include |
---|
2318 | an entity-body, as in the case of the PUT and POST requests, and even |
---|
2319 | then it is optional. A client without a clock MUST NOT send a Date |
---|
2320 | header field in a request. |
---|
2321 | </t> |
---|
2322 | <t> |
---|
2323 | The HTTP-date sent in a Date header SHOULD NOT represent a date and |
---|
2324 | time subsequent to the generation of the message. It SHOULD represent |
---|
2325 | the best available approximation of the date and time of message |
---|
2326 | generation, unless the implementation has no means of generating a |
---|
2327 | reasonably accurate date and time. In theory, the date ought to |
---|
2328 | represent the moment just before the entity is generated. In |
---|
2329 | practice, the date can be generated at any time during the message |
---|
2330 | origination without affecting its semantic value. |
---|
2331 | </t> |
---|
2332 | |
---|
2333 | <section title="Clockless Origin Server Operation" anchor="clockless.origin.server.operation"> |
---|
2334 | <t> |
---|
2335 | Some origin server implementations might not have a clock available. |
---|
2336 | An origin server without a clock MUST NOT assign Expires or Last-Modified |
---|
2337 | values to a response, unless these values were associated |
---|
2338 | with the resource by a system or user with a reliable clock. It MAY |
---|
2339 | assign an Expires value that is known, at or before server |
---|
2340 | configuration time, to be in the past (this allows "pre-expiration" |
---|
2341 | of responses without storing separate Expires values for each |
---|
2342 | resource). |
---|
2343 | </t> |
---|
2344 | </section> |
---|
2345 | </section> |
---|
2346 | |
---|
2347 | <section title="Host" anchor="header.host"> |
---|
2348 | <iref primary="true" item="Host header"/> |
---|
2349 | <iref primary="true" item="Headers" subitem="Host"/> |
---|
2350 | |
---|
2351 | |
---|
2352 | <t> |
---|
2353 | The request-header field "Host" specifies the Internet host and port |
---|
2354 | number of the resource being requested, as obtained from the original |
---|
2355 | URI given by the user or referring resource (generally an http URI, |
---|
2356 | as described in <xref target="http.uri"/>). The Host field value MUST represent |
---|
2357 | the naming authority of the origin server or gateway given by the |
---|
2358 | original URL. This allows the origin server or gateway to |
---|
2359 | differentiate between internally-ambiguous URLs, such as the root "/" |
---|
2360 | URL of a server for multiple host names on a single IP address. |
---|
2361 | </t> |
---|
2362 | <figure><iref primary="true" item="Grammar" subitem="Host"/><iref primary="true" item="Grammar" subitem="Host-v"/><artwork type="abnf2616"><![CDATA[ |
---|
2363 | Host = "Host" ":" OWS Host-v |
---|
2364 | Host-v = uri-host [ ":" port ] ; Section 2.1.1 |
---|
2365 | ]]></artwork></figure> |
---|
2366 | <t> |
---|
2367 | A "host" without any trailing port information implies the default |
---|
2368 | port for the service requested (e.g., "80" for an HTTP URL). For |
---|
2369 | example, a request on the origin server for |
---|
2370 | <http://www.example.org/pub/WWW/> would properly include: |
---|
2371 | </t> |
---|
2372 | <figure><artwork type="example"><![CDATA[ |
---|
2373 | GET /pub/WWW/ HTTP/1.1 |
---|
2374 | Host: www.example.org |
---|
2375 | ]]></artwork></figure> |
---|
2376 | <t> |
---|
2377 | A client MUST include a Host header field in all HTTP/1.1 request |
---|
2378 | messages. If the requested URI does not include an Internet host |
---|
2379 | name for the service being requested, then the Host header field MUST |
---|
2380 | be given with an empty value. An HTTP/1.1 proxy MUST ensure that any |
---|
2381 | request message it forwards does contain an appropriate Host header |
---|
2382 | field that identifies the service being requested by the proxy. All |
---|
2383 | Internet-based HTTP/1.1 servers MUST respond with a 400 (Bad Request) |
---|
2384 | status code to any HTTP/1.1 request message which lacks a Host header |
---|
2385 | field. |
---|
2386 | </t> |
---|
2387 | <t> |
---|
2388 | See Sections <xref target="the.resource.identified.by.a.request" format="counter"/> |
---|
2389 | and <xref target="changes.to.simplify.multi-homed.web.servers.and.conserve.ip.addresses" format="counter"/> |
---|
2390 | for other requirements relating to Host. |
---|
2391 | </t> |
---|
2392 | </section> |
---|
2393 | |
---|
2394 | <section title="TE" anchor="header.te"> |
---|
2395 | <iref primary="true" item="TE header"/> |
---|
2396 | <iref primary="true" item="Headers" subitem="TE"/> |
---|
2397 | |
---|
2398 | |
---|
2399 | |
---|
2400 | |
---|
2401 | |
---|
2402 | <t> |
---|
2403 | The request-header field "TE" indicates what extension transfer-codings |
---|
2404 | it is willing to accept in the response and whether or not it is |
---|
2405 | willing to accept trailer fields in a chunked transfer-coding. Its |
---|
2406 | value may consist of the keyword "trailers" and/or a comma-separated |
---|
2407 | list of extension transfer-coding names with optional accept |
---|
2408 | parameters (as described in <xref target="transfer.codings"/>). |
---|
2409 | </t> |
---|
2410 | <figure><iref primary="true" item="Grammar" subitem="TE"/><iref primary="true" item="Grammar" subitem="TE-v"/><iref primary="true" item="Grammar" subitem="t-codings"/><iref primary="true" item="Grammar" subitem="te-params"/><iref primary="true" item="Grammar" subitem="te-ext"/><artwork type="abnf2616"><![CDATA[ |
---|
2411 | TE = "TE" ":" OWS TE-v |
---|
2412 | TE-v = #t-codings |
---|
2413 | t-codings = "trailers" / ( transfer-extension [ te-params ] ) |
---|
2414 | te-params = OWS ";" OWS "q=" qvalue *( te-ext ) |
---|
2415 | te-ext = OWS ";" OWS token [ "=" ( token / quoted-string ) ] |
---|
2416 | ]]></artwork></figure> |
---|
2417 | <t> |
---|
2418 | The presence of the keyword "trailers" indicates that the client is |
---|
2419 | willing to accept trailer fields in a chunked transfer-coding, as |
---|
2420 | defined in <xref target="chunked.transfer.encoding"/>. This keyword is reserved for use with |
---|
2421 | transfer-coding values even though it does not itself represent a |
---|
2422 | transfer-coding. |
---|
2423 | </t> |
---|
2424 | <t> |
---|
2425 | Examples of its use are: |
---|
2426 | </t> |
---|
2427 | <figure><artwork type="example"><![CDATA[ |
---|
2428 | TE: deflate |
---|
2429 | TE: |
---|
2430 | TE: trailers, deflate;q=0.5 |
---|
2431 | ]]></artwork></figure> |
---|
2432 | <t> |
---|
2433 | The TE header field only applies to the immediate connection. |
---|
2434 | Therefore, the keyword MUST be supplied within a Connection header |
---|
2435 | field (<xref target="header.connection"/>) whenever TE is present in an HTTP/1.1 message. |
---|
2436 | </t> |
---|
2437 | <t> |
---|
2438 | A server tests whether a transfer-coding is acceptable, according to |
---|
2439 | a TE field, using these rules: |
---|
2440 | <list style="numbers"> |
---|
2441 | <t>The "chunked" transfer-coding is always acceptable. If the |
---|
2442 | keyword "trailers" is listed, the client indicates that it is |
---|
2443 | willing to accept trailer fields in the chunked response on |
---|
2444 | behalf of itself and any downstream clients. The implication is |
---|
2445 | that, if given, the client is stating that either all |
---|
2446 | downstream clients are willing to accept trailer fields in the |
---|
2447 | forwarded response, or that it will attempt to buffer the |
---|
2448 | response on behalf of downstream recipients. |
---|
2449 | <vspace blankLines="1"/> |
---|
2450 | Note: HTTP/1.1 does not define any means to limit the size of a |
---|
2451 | chunked response such that a client can be assured of buffering |
---|
2452 | the entire response.</t> |
---|
2453 | <t>If the transfer-coding being tested is one of the transfer-codings |
---|
2454 | listed in the TE field, then it is acceptable unless it |
---|
2455 | is accompanied by a qvalue of 0. (As defined in <xref target="quality.values"/>, a |
---|
2456 | qvalue of 0 means "not acceptable.")</t> |
---|
2457 | <t>If multiple transfer-codings are acceptable, then the |
---|
2458 | acceptable transfer-coding with the highest non-zero qvalue is |
---|
2459 | preferred. The "chunked" transfer-coding always has a qvalue |
---|
2460 | of 1.</t> |
---|
2461 | </list> |
---|
2462 | </t> |
---|
2463 | <t> |
---|
2464 | If the TE field-value is empty or if no TE field is present, the only |
---|
2465 | transfer-coding is "chunked". A message with no transfer-coding is |
---|
2466 | always acceptable. |
---|
2467 | </t> |
---|
2468 | </section> |
---|
2469 | |
---|
2470 | <section title="Trailer" anchor="header.trailer"> |
---|
2471 | <iref primary="true" item="Trailer header"/> |
---|
2472 | <iref primary="true" item="Headers" subitem="Trailer"/> |
---|
2473 | |
---|
2474 | |
---|
2475 | <t> |
---|
2476 | The general field "Trailer" indicates that the given set of |
---|
2477 | header fields is present in the trailer of a message encoded with |
---|
2478 | chunked transfer-coding. |
---|
2479 | </t> |
---|
2480 | <figure><iref primary="true" item="Grammar" subitem="Trailer"/><iref primary="true" item="Grammar" subitem="Trailer-v"/><artwork type="abnf2616"><![CDATA[ |
---|
2481 | Trailer = "Trailer" ":" OWS Trailer-v |
---|
2482 | Trailer-v = 1#field-name |
---|
2483 | ]]></artwork></figure> |
---|
2484 | <t> |
---|
2485 | An HTTP/1.1 message SHOULD include a Trailer header field in a |
---|
2486 | message using chunked transfer-coding with a non-empty trailer. Doing |
---|
2487 | so allows the recipient to know which header fields to expect in the |
---|
2488 | trailer. |
---|
2489 | </t> |
---|
2490 | <t> |
---|
2491 | If no Trailer header field is present, the trailer SHOULD NOT include |
---|
2492 | any header fields. See <xref target="chunked.transfer.encoding"/> for restrictions on the use of |
---|
2493 | trailer fields in a "chunked" transfer-coding. |
---|
2494 | </t> |
---|
2495 | <t> |
---|
2496 | Message header fields listed in the Trailer header field MUST NOT |
---|
2497 | include the following header fields: |
---|
2498 | <list style="symbols"> |
---|
2499 | <t>Transfer-Encoding</t> |
---|
2500 | <t>Content-Length</t> |
---|
2501 | <t>Trailer</t> |
---|
2502 | </list> |
---|
2503 | </t> |
---|
2504 | </section> |
---|
2505 | |
---|
2506 | <section title="Transfer-Encoding" anchor="header.transfer-encoding"> |
---|
2507 | <iref primary="true" item="Transfer-Encoding header"/> |
---|
2508 | <iref primary="true" item="Headers" subitem="Transfer-Encoding"/> |
---|
2509 | |
---|
2510 | |
---|
2511 | <t> |
---|
2512 | The general-header "Transfer-Encoding" field indicates what (if any) |
---|
2513 | type of transformation has been applied to the message body in order |
---|
2514 | to safely transfer it between the sender and the recipient. This |
---|
2515 | differs from the content-coding in that the transfer-coding is a |
---|
2516 | property of the message, not of the entity. |
---|
2517 | </t> |
---|
2518 | <figure><iref primary="true" item="Grammar" subitem="Transfer-Encoding"/><iref primary="true" item="Grammar" subitem="Transfer-Encoding-v"/><artwork type="abnf2616"><![CDATA[ |
---|
2519 | Transfer-Encoding = "Transfer-Encoding" ":" OWS |
---|
2520 | Transfer-Encoding-v |
---|
2521 | Transfer-Encoding-v = 1#transfer-coding |
---|
2522 | ]]></artwork></figure> |
---|
2523 | <t> |
---|
2524 | Transfer-codings are defined in <xref target="transfer.codings"/>. An example is: |
---|
2525 | </t> |
---|
2526 | <figure><artwork type="example"><![CDATA[ |
---|
2527 | Transfer-Encoding: chunked |
---|
2528 | ]]></artwork></figure> |
---|
2529 | <t> |
---|
2530 | If multiple encodings have been applied to an entity, the transfer-codings |
---|
2531 | MUST be listed in the order in which they were applied. |
---|
2532 | Additional information about the encoding parameters MAY be provided |
---|
2533 | by other entity-header fields not defined by this specification. |
---|
2534 | </t> |
---|
2535 | <t> |
---|
2536 | Many older HTTP/1.0 applications do not understand the Transfer-Encoding |
---|
2537 | header. |
---|
2538 | </t> |
---|
2539 | </section> |
---|
2540 | |
---|
2541 | <section title="Upgrade" anchor="header.upgrade"> |
---|
2542 | <iref primary="true" item="Upgrade header"/> |
---|
2543 | <iref primary="true" item="Headers" subitem="Upgrade"/> |
---|
2544 | |
---|
2545 | |
---|
2546 | <t> |
---|
2547 | The general-header "Upgrade" allows the client to specify what |
---|
2548 | additional communication protocols it supports and would like to use |
---|
2549 | if the server finds it appropriate to switch protocols. The server |
---|
2550 | MUST use the Upgrade header field within a 101 (Switching Protocols) |
---|
2551 | response to indicate which protocol(s) are being switched. |
---|
2552 | </t> |
---|
2553 | <figure><iref primary="true" item="Grammar" subitem="Upgrade"/><iref primary="true" item="Grammar" subitem="Upgrade-v"/><artwork type="abnf2616"><![CDATA[ |
---|
2554 | Upgrade = "Upgrade" ":" OWS Upgrade-v |
---|
2555 | Upgrade-v = 1#product |
---|
2556 | ]]></artwork></figure> |
---|
2557 | <t> |
---|
2558 | For example, |
---|
2559 | </t> |
---|
2560 | <figure><artwork type="example"><![CDATA[ |
---|
2561 | Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11 |
---|
2562 | ]]></artwork></figure> |
---|
2563 | <t> |
---|
2564 | The Upgrade header field is intended to provide a simple mechanism |
---|
2565 | for transition from HTTP/1.1 to some other, incompatible protocol. It |
---|
2566 | does so by allowing the client to advertise its desire to use another |
---|
2567 | protocol, such as a later version of HTTP with a higher major version |
---|
2568 | number, even though the current request has been made using HTTP/1.1. |
---|
2569 | This eases the difficult transition between incompatible protocols by |
---|
2570 | allowing the client to initiate a request in the more commonly |
---|
2571 | supported protocol while indicating to the server that it would like |
---|
2572 | to use a "better" protocol if available (where "better" is determined |
---|
2573 | by the server, possibly according to the nature of the method and/or |
---|
2574 | resource being requested). |
---|
2575 | </t> |
---|
2576 | <t> |
---|
2577 | The Upgrade header field only applies to switching application-layer |
---|
2578 | protocols upon the existing transport-layer connection. Upgrade |
---|
2579 | cannot be used to insist on a protocol change; its acceptance and use |
---|
2580 | by the server is optional. The capabilities and nature of the |
---|
2581 | application-layer communication after the protocol change is entirely |
---|
2582 | dependent upon the new protocol chosen, although the first action |
---|
2583 | after changing the protocol MUST be a response to the initial HTTP |
---|
2584 | request containing the Upgrade header field. |
---|
2585 | </t> |
---|
2586 | <t> |
---|
2587 | The Upgrade header field only applies to the immediate connection. |
---|
2588 | Therefore, the upgrade keyword MUST be supplied within a Connection |
---|
2589 | header field (<xref target="header.connection"/>) whenever Upgrade is present in an |
---|
2590 | HTTP/1.1 message. |
---|
2591 | </t> |
---|
2592 | <t> |
---|
2593 | The Upgrade header field cannot be used to indicate a switch to a |
---|
2594 | protocol on a different connection. For that purpose, it is more |
---|
2595 | appropriate to use a 301, 302, 303, or 305 redirection response. |
---|
2596 | </t> |
---|
2597 | <t> |
---|
2598 | This specification only defines the protocol name "HTTP" for use by |
---|
2599 | the family of Hypertext Transfer Protocols, as defined by the HTTP |
---|
2600 | version rules of <xref target="http.version"/> and future updates to this |
---|
2601 | specification. Any token can be used as a protocol name; however, it |
---|
2602 | will only be useful if both the client and server associate the name |
---|
2603 | with the same protocol. |
---|
2604 | </t> |
---|
2605 | </section> |
---|
2606 | |
---|
2607 | <section title="Via" anchor="header.via"> |
---|
2608 | <iref primary="true" item="Via header"/> |
---|
2609 | <iref primary="true" item="Headers" subitem="Via"/> |
---|
2610 | |
---|
2611 | |
---|
2612 | |
---|
2613 | |
---|
2614 | |
---|
2615 | |
---|
2616 | |
---|
2617 | <t> |
---|
2618 | The general-header field "Via" MUST be used by gateways and proxies to |
---|
2619 | indicate the intermediate protocols and recipients between the user |
---|
2620 | agent and the server on requests, and between the origin server and |
---|
2621 | the client on responses. It is analogous to the "Received" field defined in |
---|
2622 | Section 3.6.7 of <xref target="RFC5322"/> and is intended to be used for tracking message forwards, |
---|
2623 | avoiding request loops, and identifying the protocol capabilities of |
---|
2624 | all senders along the request/response chain. |
---|
2625 | </t> |
---|
2626 | <figure><iref primary="true" item="Grammar" subitem="Via"/><iref primary="true" item="Grammar" subitem="Via-v"/><iref primary="true" item="Grammar" subitem="received-protocol"/><iref primary="true" item="Grammar" subitem="protocol-name"/><iref primary="true" item="Grammar" subitem="protocol-version"/><iref primary="true" item="Grammar" subitem="received-by"/><iref primary="true" item="Grammar" subitem="pseudonym"/><artwork type="abnf2616"><![CDATA[ |
---|
2627 | Via = "Via" ":" OWS Via-v |
---|
2628 | Via-v = 1#( received-protocol RWS received-by |
---|
2629 | [ RWS comment ] ) |
---|
2630 | received-protocol = [ protocol-name "/" ] protocol-version |
---|
2631 | protocol-name = token |
---|
2632 | protocol-version = token |
---|
2633 | received-by = ( uri-host [ ":" port ] ) / pseudonym |
---|
2634 | pseudonym = token |
---|
2635 | ]]></artwork></figure> |
---|
2636 | <t> |
---|
2637 | The received-protocol indicates the protocol version of the message |
---|
2638 | received by the server or client along each segment of the |
---|
2639 | request/response chain. The received-protocol version is appended to |
---|
2640 | the Via field value when the message is forwarded so that information |
---|
2641 | about the protocol capabilities of upstream applications remains |
---|
2642 | visible to all recipients. |
---|
2643 | </t> |
---|
2644 | <t> |
---|
2645 | The protocol-name is optional if and only if it would be "HTTP". The |
---|
2646 | received-by field is normally the host and optional port number of a |
---|
2647 | recipient server or client that subsequently forwarded the message. |
---|
2648 | However, if the real host is considered to be sensitive information, |
---|
2649 | it MAY be replaced by a pseudonym. If the port is not given, it MAY |
---|
2650 | be assumed to be the default port of the received-protocol. |
---|
2651 | </t> |
---|
2652 | <t> |
---|
2653 | Multiple Via field values represents each proxy or gateway that has |
---|
2654 | forwarded the message. Each recipient MUST append its information |
---|
2655 | such that the end result is ordered according to the sequence of |
---|
2656 | forwarding applications. |
---|
2657 | </t> |
---|
2658 | <t> |
---|
2659 | Comments MAY be used in the Via header field to identify the software |
---|
2660 | of the recipient proxy or gateway, analogous to the User-Agent and |
---|
2661 | Server header fields. However, all comments in the Via field are |
---|
2662 | optional and MAY be removed by any recipient prior to forwarding the |
---|
2663 | message. |
---|
2664 | </t> |
---|
2665 | <t> |
---|
2666 | For example, a request message could be sent from an HTTP/1.0 user |
---|
2667 | agent to an internal proxy code-named "fred", which uses HTTP/1.1 to |
---|
2668 | forward the request to a public proxy at p.example.net, which completes |
---|
2669 | the request by forwarding it to the origin server at www.example.com. |
---|
2670 | The request received by www.example.com would then have the following |
---|
2671 | Via header field: |
---|
2672 | </t> |
---|
2673 | <figure><artwork type="example"><![CDATA[ |
---|
2674 | Via: 1.0 fred, 1.1 p.example.net (Apache/1.1) |
---|
2675 | ]]></artwork></figure> |
---|
2676 | <t> |
---|
2677 | Proxies and gateways used as a portal through a network firewall |
---|
2678 | SHOULD NOT, by default, forward the names and ports of hosts within |
---|
2679 | the firewall region. This information SHOULD only be propagated if |
---|
2680 | explicitly enabled. If not enabled, the received-by host of any host |
---|
2681 | behind the firewall SHOULD be replaced by an appropriate pseudonym |
---|
2682 | for that host. |
---|
2683 | </t> |
---|
2684 | <t> |
---|
2685 | For organizations that have strong privacy requirements for hiding |
---|
2686 | internal structures, a proxy MAY combine an ordered subsequence of |
---|
2687 | Via header field entries with identical received-protocol values into |
---|
2688 | a single such entry. For example, |
---|
2689 | </t> |
---|
2690 | <figure><artwork type="example"><![CDATA[ |
---|
2691 | Via: 1.0 ricky, 1.1 ethel, 1.1 fred, 1.0 lucy |
---|
2692 | ]]></artwork></figure> |
---|
2693 | <t> |
---|
2694 | could be collapsed to |
---|
2695 | </t> |
---|
2696 | <figure><artwork type="example"><![CDATA[ |
---|
2697 | Via: 1.0 ricky, 1.1 mertz, 1.0 lucy |
---|
2698 | ]]></artwork></figure> |
---|
2699 | <t> |
---|
2700 | Applications SHOULD NOT combine multiple entries unless they are all |
---|
2701 | under the same organizational control and the hosts have already been |
---|
2702 | replaced by pseudonyms. Applications MUST NOT combine entries which |
---|
2703 | have different received-protocol values. |
---|
2704 | </t> |
---|
2705 | </section> |
---|
2706 | |
---|
2707 | </section> |
---|
2708 | |
---|
2709 | <section title="IANA Considerations" anchor="IANA.considerations"> |
---|
2710 | <section title="Message Header Registration" anchor="message.header.registration"> |
---|
2711 | <t> |
---|
2712 | The Message Header Registry located at <eref target="http://www.iana.org/assignments/message-headers/message-header-index.html"/> should be updated |
---|
2713 | with the permanent registrations below (see <xref target="RFC3864"/>): |
---|
2714 | </t> |
---|
2715 | <!--AUTOGENERATED FROM extract-header-defs.xslt, do not edit manually--> |
---|
2716 | <texttable align="left" suppress-title="true" anchor="iana.header.registration.table"> |
---|
2717 | <ttcol>Header Field Name</ttcol> |
---|
2718 | <ttcol>Protocol</ttcol> |
---|
2719 | <ttcol>Status</ttcol> |
---|
2720 | <ttcol>Reference</ttcol> |
---|
2721 | |
---|
2722 | <c>Connection</c> |
---|
2723 | <c>http</c> |
---|
2724 | <c>standard</c> |
---|
2725 | <c> |
---|
2726 | <xref target="header.connection"/> |
---|
2727 | </c> |
---|
2728 | <c>Content-Length</c> |
---|
2729 | <c>http</c> |
---|
2730 | <c>standard</c> |
---|
2731 | <c> |
---|
2732 | <xref target="header.content-length"/> |
---|
2733 | </c> |
---|
2734 | <c>Date</c> |
---|
2735 | <c>http</c> |
---|
2736 | <c>standard</c> |
---|
2737 | <c> |
---|
2738 | <xref target="header.date"/> |
---|
2739 | </c> |
---|
2740 | <c>Host</c> |
---|
2741 | <c>http</c> |
---|
2742 | <c>standard</c> |
---|
2743 | <c> |
---|
2744 | <xref target="header.host"/> |
---|
2745 | </c> |
---|
2746 | <c>TE</c> |
---|
2747 | <c>http</c> |
---|
2748 | <c>standard</c> |
---|
2749 | <c> |
---|
2750 | <xref target="header.te"/> |
---|
2751 | </c> |
---|
2752 | <c>Trailer</c> |
---|
2753 | <c>http</c> |
---|
2754 | <c>standard</c> |
---|
2755 | <c> |
---|
2756 | <xref target="header.trailer"/> |
---|
2757 | </c> |
---|
2758 | <c>Transfer-Encoding</c> |
---|
2759 | <c>http</c> |
---|
2760 | <c>standard</c> |
---|
2761 | <c> |
---|
2762 | <xref target="header.transfer-encoding"/> |
---|
2763 | </c> |
---|
2764 | <c>Upgrade</c> |
---|
2765 | <c>http</c> |
---|
2766 | <c>standard</c> |
---|
2767 | <c> |
---|
2768 | <xref target="header.upgrade"/> |
---|
2769 | </c> |
---|
2770 | <c>Via</c> |
---|
2771 | <c>http</c> |
---|
2772 | <c>standard</c> |
---|
2773 | <c> |
---|
2774 | <xref target="header.via"/> |
---|
2775 | </c> |
---|
2776 | </texttable> |
---|
2777 | <!--(END)--> |
---|
2778 | <t> |
---|
2779 | The change controller is: "IETF (iesg@ietf.org) - Internet Engineering Task Force". |
---|
2780 | </t> |
---|
2781 | </section> |
---|
2782 | |
---|
2783 | <section title="URI Scheme Registration" anchor="uri.scheme.registration"> |
---|
2784 | <t> |
---|
2785 | The entry for the "http" URI Scheme in the registry located at |
---|
2786 | <eref target="http://www.iana.org/assignments/uri-schemes.html"/> |
---|
2787 | should be updated to point to <xref target="http.uri"/> of this document |
---|
2788 | (see <xref target="RFC4395"/>). |
---|
2789 | </t> |
---|
2790 | </section> |
---|
2791 | |
---|
2792 | <section title="Internet Media Type Registrations" anchor="internet.media.type.http"> |
---|
2793 | <t> |
---|
2794 | This document serves as the specification for the Internet media types |
---|
2795 | "message/http" and "application/http". The following is to be registered with |
---|
2796 | IANA (see <xref target="RFC4288"/>). |
---|
2797 | </t> |
---|
2798 | <section title="Internet Media Type message/http" anchor="internet.media.type.message.http"> |
---|
2799 | <iref item="Media Type" subitem="message/http" primary="true"/> |
---|
2800 | <iref item="message/http Media Type" primary="true"/> |
---|
2801 | <t> |
---|
2802 | The message/http type can be used to enclose a single HTTP request or |
---|
2803 | response message, provided that it obeys the MIME restrictions for all |
---|
2804 | "message" types regarding line length and encodings. |
---|
2805 | </t> |
---|
2806 | <t> |
---|
2807 | <list style="hanging"> |
---|
2808 | <t hangText="Type name:"> |
---|
2809 | message |
---|
2810 | </t> |
---|
2811 | <t hangText="Subtype name:"> |
---|
2812 | http |
---|
2813 | </t> |
---|
2814 | <t hangText="Required parameters:"> |
---|
2815 | none |
---|
2816 | </t> |
---|
2817 | <t hangText="Optional parameters:"> |
---|
2818 | version, msgtype |
---|
2819 | <list style="hanging"> |
---|
2820 | <t hangText="version:"> |
---|
2821 | The HTTP-Version number of the enclosed message |
---|
2822 | (e.g., "1.1"). If not present, the version can be |
---|
2823 | determined from the first line of the body. |
---|
2824 | </t> |
---|
2825 | <t hangText="msgtype:"> |
---|
2826 | The message type -- "request" or "response". If not |
---|
2827 | present, the type can be determined from the first |
---|
2828 | line of the body. |
---|
2829 | </t> |
---|
2830 | </list> |
---|
2831 | </t> |
---|
2832 | <t hangText="Encoding considerations:"> |
---|
2833 | only "7bit", "8bit", or "binary" are permitted |
---|
2834 | </t> |
---|
2835 | <t hangText="Security considerations:"> |
---|
2836 | none |
---|
2837 | </t> |
---|
2838 | <t hangText="Interoperability considerations:"> |
---|
2839 | none |
---|
2840 | </t> |
---|
2841 | <t hangText="Published specification:"> |
---|
2842 | This specification (see <xref target="internet.media.type.message.http"/>). |
---|
2843 | </t> |
---|
2844 | <t hangText="Applications that use this media type:"> |
---|
2845 | </t> |
---|
2846 | <t hangText="Additional information:"> |
---|
2847 | <list style="hanging"> |
---|
2848 | <t hangText="Magic number(s):">none</t> |
---|
2849 | <t hangText="File extension(s):">none</t> |
---|
2850 | <t hangText="Macintosh file type code(s):">none</t> |
---|
2851 | </list> |
---|
2852 | </t> |
---|
2853 | <t hangText="Person and email address to contact for further information:"> |
---|
2854 | See Authors Section. |
---|
2855 | </t> |
---|
2856 | <t hangText="Intended usage:"> |
---|
2857 | COMMON |
---|
2858 | </t> |
---|
2859 | <t hangText="Restrictions on usage:"> |
---|
2860 | none |
---|
2861 | </t> |
---|
2862 | <t hangText="Author/Change controller:"> |
---|
2863 | IESG |
---|
2864 | </t> |
---|
2865 | </list> |
---|
2866 | </t> |
---|
2867 | </section> |
---|
2868 | <section title="Internet Media Type application/http" anchor="internet.media.type.application.http"> |
---|
2869 | <iref item="Media Type" subitem="application/http" primary="true"/> |
---|
2870 | <iref item="application/http Media Type" primary="true"/> |
---|
2871 | <t> |
---|
2872 | The application/http type can be used to enclose a pipeline of one or more |
---|
2873 | HTTP request or response messages (not intermixed). |
---|
2874 | </t> |
---|
2875 | <t> |
---|
2876 | <list style="hanging"> |
---|
2877 | <t hangText="Type name:"> |
---|
2878 | application |
---|
2879 | </t> |
---|
2880 | <t hangText="Subtype name:"> |
---|
2881 | http |
---|
2882 | </t> |
---|
2883 | <t hangText="Required parameters:"> |
---|
2884 | none |
---|
2885 | </t> |
---|
2886 | <t hangText="Optional parameters:"> |
---|
2887 | version, msgtype |
---|
2888 | <list style="hanging"> |
---|
2889 | <t hangText="version:"> |
---|
2890 | The HTTP-Version number of the enclosed messages |
---|
2891 | (e.g., "1.1"). If not present, the version can be |
---|
2892 | determined from the first line of the body. |
---|
2893 | </t> |
---|
2894 | <t hangText="msgtype:"> |
---|
2895 | The message type -- "request" or "response". If not |
---|
2896 | present, the type can be determined from the first |
---|
2897 | line of the body. |
---|
2898 | </t> |
---|
2899 | </list> |
---|
2900 | </t> |
---|
2901 | <t hangText="Encoding considerations:"> |
---|
2902 | HTTP messages enclosed by this type |
---|
2903 | are in "binary" format; use of an appropriate |
---|
2904 | Content-Transfer-Encoding is required when |
---|
2905 | transmitted via E-mail. |
---|
2906 | </t> |
---|
2907 | <t hangText="Security considerations:"> |
---|
2908 | none |
---|
2909 | </t> |
---|
2910 | <t hangText="Interoperability considerations:"> |
---|
2911 | none |
---|
2912 | </t> |
---|
2913 | <t hangText="Published specification:"> |
---|
2914 | This specification (see <xref target="internet.media.type.application.http"/>). |
---|
2915 | </t> |
---|
2916 | <t hangText="Applications that use this media type:"> |
---|
2917 | </t> |
---|
2918 | <t hangText="Additional information:"> |
---|
2919 | <list style="hanging"> |
---|
2920 | <t hangText="Magic number(s):">none</t> |
---|
2921 | <t hangText="File extension(s):">none</t> |
---|
2922 | <t hangText="Macintosh file type code(s):">none</t> |
---|
2923 | </list> |
---|
2924 | </t> |
---|
2925 | <t hangText="Person and email address to contact for further information:"> |
---|
2926 | See Authors Section. |
---|
2927 | </t> |
---|
2928 | <t hangText="Intended usage:"> |
---|
2929 | COMMON |
---|
2930 | </t> |
---|
2931 | <t hangText="Restrictions on usage:"> |
---|
2932 | none |
---|
2933 | </t> |
---|
2934 | <t hangText="Author/Change controller:"> |
---|
2935 | IESG |
---|
2936 | </t> |
---|
2937 | </list> |
---|
2938 | </t> |
---|
2939 | </section> |
---|
2940 | </section> |
---|
2941 | |
---|
2942 | </section> |
---|
2943 | |
---|
2944 | <section title="Security Considerations" anchor="security.considerations"> |
---|
2945 | <t> |
---|
2946 | This section is meant to inform application developers, information |
---|
2947 | providers, and users of the security limitations in HTTP/1.1 as |
---|
2948 | described by this document. The discussion does not include |
---|
2949 | definitive solutions to the problems revealed, though it does make |
---|
2950 | some suggestions for reducing security risks. |
---|
2951 | </t> |
---|
2952 | |
---|
2953 | <section title="Personal Information" anchor="personal.information"> |
---|
2954 | <t> |
---|
2955 | HTTP clients are often privy to large amounts of personal information |
---|
2956 | (e.g. the user's name, location, mail address, passwords, encryption |
---|
2957 | keys, etc.), and SHOULD be very careful to prevent unintentional |
---|
2958 | leakage of this information. |
---|
2959 | We very strongly recommend that a convenient interface be provided |
---|
2960 | for the user to control dissemination of such information, and that |
---|
2961 | designers and implementors be particularly careful in this area. |
---|
2962 | History shows that errors in this area often create serious security |
---|
2963 | and/or privacy problems and generate highly adverse publicity for the |
---|
2964 | implementor's company. |
---|
2965 | </t> |
---|
2966 | </section> |
---|
2967 | |
---|
2968 | <section title="Abuse of Server Log Information" anchor="abuse.of.server.log.information"> |
---|
2969 | <t> |
---|
2970 | A server is in the position to save personal data about a user's |
---|
2971 | requests which might identify their reading patterns or subjects of |
---|
2972 | interest. This information is clearly confidential in nature and its |
---|
2973 | handling can be constrained by law in certain countries. People using |
---|
2974 | HTTP to provide data are responsible for ensuring that |
---|
2975 | such material is not distributed without the permission of any |
---|
2976 | individuals that are identifiable by the published results. |
---|
2977 | </t> |
---|
2978 | </section> |
---|
2979 | |
---|
2980 | <section title="Attacks Based On File and Path Names" anchor="attack.pathname"> |
---|
2981 | <t> |
---|
2982 | Implementations of HTTP origin servers SHOULD be careful to restrict |
---|
2983 | the documents returned by HTTP requests to be only those that were |
---|
2984 | intended by the server administrators. If an HTTP server translates |
---|
2985 | HTTP URIs directly into file system calls, the server MUST take |
---|
2986 | special care not to serve files that were not intended to be |
---|
2987 | delivered to HTTP clients. For example, UNIX, Microsoft Windows, and |
---|
2988 | other operating systems use ".." as a path component to indicate a |
---|
2989 | directory level above the current one. On such a system, an HTTP |
---|
2990 | server MUST disallow any such construct in the request-target if it |
---|
2991 | would otherwise allow access to a resource outside those intended to |
---|
2992 | be accessible via the HTTP server. Similarly, files intended for |
---|
2993 | reference only internally to the server (such as access control |
---|
2994 | files, configuration files, and script code) MUST be protected from |
---|
2995 | inappropriate retrieval, since they might contain sensitive |
---|
2996 | information. Experience has shown that minor bugs in such HTTP server |
---|
2997 | implementations have turned into security risks. |
---|
2998 | </t> |
---|
2999 | </section> |
---|
3000 | |
---|
3001 | <section title="DNS Spoofing" anchor="dns.spoofing"> |
---|
3002 | <t> |
---|
3003 | Clients using HTTP rely heavily on the Domain Name Service, and are |
---|
3004 | thus generally prone to security attacks based on the deliberate |
---|
3005 | mis-association of IP addresses and DNS names. Clients need to be |
---|
3006 | cautious in assuming the continuing validity of an IP number/DNS name |
---|
3007 | association. |
---|
3008 | </t> |
---|
3009 | <t> |
---|
3010 | In particular, HTTP clients SHOULD rely on their name resolver for |
---|
3011 | confirmation of an IP number/DNS name association, rather than |
---|
3012 | caching the result of previous host name lookups. Many platforms |
---|
3013 | already can cache host name lookups locally when appropriate, and |
---|
3014 | they SHOULD be configured to do so. It is proper for these lookups to |
---|
3015 | be cached, however, only when the TTL (Time To Live) information |
---|
3016 | reported by the name server makes it likely that the cached |
---|
3017 | information will remain useful. |
---|
3018 | </t> |
---|
3019 | <t> |
---|
3020 | If HTTP clients cache the results of host name lookups in order to |
---|
3021 | achieve a performance improvement, they MUST observe the TTL |
---|
3022 | information reported by DNS. |
---|
3023 | </t> |
---|
3024 | <t> |
---|
3025 | If HTTP clients do not observe this rule, they could be spoofed when |
---|
3026 | a previously-accessed server's IP address changes. As network |
---|
3027 | renumbering is expected to become increasingly common <xref target="RFC1900"/>, the |
---|
3028 | possibility of this form of attack will grow. Observing this |
---|
3029 | requirement thus reduces this potential security vulnerability. |
---|
3030 | </t> |
---|
3031 | <t> |
---|
3032 | This requirement also improves the load-balancing behavior of clients |
---|
3033 | for replicated servers using the same DNS name and reduces the |
---|
3034 | likelihood of a user's experiencing failure in accessing sites which |
---|
3035 | use that strategy. |
---|
3036 | </t> |
---|
3037 | </section> |
---|
3038 | |
---|
3039 | <section title="Proxies and Caching" anchor="attack.proxies"> |
---|
3040 | <t> |
---|
3041 | By their very nature, HTTP proxies are men-in-the-middle, and |
---|
3042 | represent an opportunity for man-in-the-middle attacks. Compromise of |
---|
3043 | the systems on which the proxies run can result in serious security |
---|
3044 | and privacy problems. Proxies have access to security-related |
---|
3045 | information, personal information about individual users and |
---|
3046 | organizations, and proprietary information belonging to users and |
---|
3047 | content providers. A compromised proxy, or a proxy implemented or |
---|
3048 | configured without regard to security and privacy considerations, |
---|
3049 | might be used in the commission of a wide range of potential attacks. |
---|
3050 | </t> |
---|
3051 | <t> |
---|
3052 | Proxy operators should protect the systems on which proxies run as |
---|
3053 | they would protect any system that contains or transports sensitive |
---|
3054 | information. In particular, log information gathered at proxies often |
---|
3055 | contains highly sensitive personal information, and/or information |
---|
3056 | about organizations. Log information should be carefully guarded, and |
---|
3057 | appropriate guidelines for use developed and followed. (<xref target="abuse.of.server.log.information"/>). |
---|
3058 | </t> |
---|
3059 | <t> |
---|
3060 | Proxy implementors should consider the privacy and security |
---|
3061 | implications of their design and coding decisions, and of the |
---|
3062 | configuration options they provide to proxy operators (especially the |
---|
3063 | default configuration). |
---|
3064 | </t> |
---|
3065 | <t> |
---|
3066 | Users of a proxy need to be aware that they are no trustworthier than |
---|
3067 | the people who run the proxy; HTTP itself cannot solve this problem. |
---|
3068 | </t> |
---|
3069 | <t> |
---|
3070 | The judicious use of cryptography, when appropriate, may suffice to |
---|
3071 | protect against a broad range of security and privacy attacks. Such |
---|
3072 | cryptography is beyond the scope of the HTTP/1.1 specification. |
---|
3073 | </t> |
---|
3074 | </section> |
---|
3075 | |
---|
3076 | <section title="Denial of Service Attacks on Proxies" anchor="attack.DoS"> |
---|
3077 | <t> |
---|
3078 | They exist. They are hard to defend against. Research continues. |
---|
3079 | Beware. |
---|
3080 | </t> |
---|
3081 | </section> |
---|
3082 | </section> |
---|
3083 | |
---|
3084 | <section title="Acknowledgments" anchor="ack"> |
---|
3085 | <t> |
---|
3086 | HTTP has evolved considerably over the years. It has |
---|
3087 | benefited from a large and active developer community--the many |
---|
3088 | people who have participated on the www-talk mailing list--and it is |
---|
3089 | that community which has been most responsible for the success of |
---|
3090 | HTTP and of the World-Wide Web in general. Marc Andreessen, Robert |
---|
3091 | Cailliau, Daniel W. Connolly, Bob Denny, John Franks, Jean-Francois |
---|
3092 | Groff, Phillip M. Hallam-Baker, Hakon W. Lie, Ari Luotonen, Rob |
---|
3093 | McCool, Lou Montulli, Dave Raggett, Tony Sanders, and Marc |
---|
3094 | VanHeyningen deserve special recognition for their efforts in |
---|
3095 | defining early aspects of the protocol. |
---|
3096 | </t> |
---|
3097 | <t> |
---|
3098 | This document has benefited greatly from the comments of all those |
---|
3099 | participating in the HTTP-WG. In addition to those already mentioned, |
---|
3100 | the following individuals have contributed to this specification: |
---|
3101 | </t> |
---|
3102 | <t> |
---|
3103 | Gary Adams, Harald Tveit Alvestrand, Keith Ball, Brian Behlendorf, |
---|
3104 | Paul Burchard, Maurizio Codogno, Mike Cowlishaw, Roman Czyborra, |
---|
3105 | Michael A. Dolan, Daniel DuBois, David J. Fiander, Alan Freier, Marc Hedlund, Greg Herlihy, |
---|
3106 | Koen Holtman, Alex Hopmann, Bob Jernigan, Shel Kaphan, Rohit Khare, |
---|
3107 | John Klensin, Martijn Koster, Alexei Kosut, David M. Kristol, |
---|
3108 | Daniel LaLiberte, Ben Laurie, Paul J. Leach, Albert Lunde, |
---|
3109 | John C. Mallery, Jean-Philippe Martin-Flatin, Mitra, David Morris, |
---|
3110 | Gavin Nicol, Ross Patterson, Bill Perry, Jeffrey Perry, Scott Powers, Owen Rees, |
---|
3111 | Luigi Rizzo, David Robinson, Marc Salomon, Rich Salz, |
---|
3112 | Allan M. Schiffman, Jim Seidman, Chuck Shotton, Eric W. Sink, |
---|
3113 | Simon E. Spero, Richard N. Taylor, Robert S. Thau, |
---|
3114 | Bill (BearHeart) Weinman, Francois Yergeau, Mary Ellen Zurko, |
---|
3115 | Josh Cohen. |
---|
3116 | </t> |
---|
3117 | <t> |
---|
3118 | Thanks to the "cave men" of Palo Alto. You know who you are. |
---|
3119 | </t> |
---|
3120 | <t> |
---|
3121 | Jim Gettys (the editor of <xref target="RFC2616"/>) wishes particularly |
---|
3122 | to thank Roy Fielding, the editor of <xref target="RFC2068"/>, along |
---|
3123 | with John Klensin, Jeff Mogul, Paul Leach, Dave Kristol, Koen |
---|
3124 | Holtman, John Franks, Josh Cohen, Alex Hopmann, Scott Lawrence, and |
---|
3125 | Larry Masinter for their help. And thanks go particularly to Jeff |
---|
3126 | Mogul and Scott Lawrence for performing the "MUST/MAY/SHOULD" audit. |
---|
3127 | </t> |
---|
3128 | <t> |
---|
3129 | The Apache Group, Anselm Baird-Smith, author of Jigsaw, and Henrik |
---|
3130 | Frystyk implemented RFC 2068 early, and we wish to thank them for the |
---|
3131 | discovery of many of the problems that this document attempts to |
---|
3132 | rectify. |
---|
3133 | </t> |
---|
3134 | <t> |
---|
3135 | This specification makes heavy use of the augmented BNF and generic |
---|
3136 | constructs defined by David H. Crocker for <xref target="RFC5234"/>. Similarly, it |
---|
3137 | reuses many of the definitions provided by Nathaniel Borenstein and |
---|
3138 | Ned Freed for MIME <xref target="RFC2045"/>. We hope that their inclusion in this |
---|
3139 | specification will help reduce past confusion over the relationship |
---|
3140 | between HTTP and Internet mail message formats. |
---|
3141 | </t> |
---|
3142 | </section> |
---|
3143 | |
---|
3144 | </middle> |
---|
3145 | <back> |
---|
3146 | |
---|
3147 | <references title="Normative References"> |
---|
3148 | |
---|
3149 | <reference anchor="ISO-8859-1"> |
---|
3150 | <front> |
---|
3151 | <title> |
---|
3152 | Information technology -- 8-bit single-byte coded graphic character sets -- Part 1: Latin alphabet No. 1 |
---|
3153 | </title> |
---|
3154 | <author> |
---|
3155 | <organization>International Organization for Standardization</organization> |
---|
3156 | </author> |
---|
3157 | <date year="1998"/> |
---|
3158 | </front> |
---|
3159 | <seriesInfo name="ISO/IEC" value="8859-1:1998"/> |
---|
3160 | </reference> |
---|
3161 | |
---|
3162 | <reference anchor="Part2"> |
---|
3163 | <front> |
---|
3164 | <title abbrev="HTTP/1.1">HTTP/1.1, part 2: Message Semantics</title> |
---|
3165 | <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor"> |
---|
3166 | <organization abbrev="Day Software">Day Software</organization> |
---|
3167 | <address><email>fielding@gbiv.com</email></address> |
---|
3168 | </author> |
---|
3169 | <author initials="J." surname="Gettys" fullname="Jim Gettys"> |
---|
3170 | <organization>One Laptop per Child</organization> |
---|
3171 | <address><email>jg@laptop.org</email></address> |
---|
3172 | </author> |
---|
3173 | <author initials="J." surname="Mogul" fullname="Jeffrey C. Mogul"> |
---|
3174 | <organization abbrev="HP">Hewlett-Packard Company</organization> |
---|
3175 | <address><email>JeffMogul@acm.org</email></address> |
---|
3176 | </author> |
---|
3177 | <author initials="H." surname="Frystyk" fullname="Henrik Frystyk Nielsen"> |
---|
3178 | <organization abbrev="Microsoft">Microsoft Corporation</organization> |
---|
3179 | <address><email>henrikn@microsoft.com</email></address> |
---|
3180 | </author> |
---|
3181 | <author initials="L." surname="Masinter" fullname="Larry Masinter"> |
---|
3182 | <organization abbrev="Adobe Systems">Adobe Systems, Incorporated</organization> |
---|
3183 | <address><email>LMM@acm.org</email></address> |
---|
3184 | </author> |
---|
3185 | <author initials="P." surname="Leach" fullname="Paul J. Leach"> |
---|
3186 | <organization abbrev="Microsoft">Microsoft Corporation</organization> |
---|
3187 | <address><email>paulle@microsoft.com</email></address> |
---|
3188 | </author> |
---|
3189 | <author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee"> |
---|
3190 | <organization abbrev="W3C/MIT">World Wide Web Consortium</organization> |
---|
3191 | <address><email>timbl@w3.org</email></address> |
---|
3192 | </author> |
---|
3193 | <author initials="Y." surname="Lafon" fullname="Yves Lafon" role="editor"> |
---|
3194 | <organization abbrev="W3C">World Wide Web Consortium</organization> |
---|
3195 | <address><email>ylafon@w3.org</email></address> |
---|
3196 | </author> |
---|
3197 | <author initials="J. F." surname="Reschke" fullname="Julian F. Reschke" role="editor"> |
---|
3198 | <organization abbrev="greenbytes">greenbytes GmbH</organization> |
---|
3199 | <address><email>julian.reschke@greenbytes.de</email></address> |
---|
3200 | </author> |
---|
3201 | <date month="July" year="2009"/> |
---|
3202 | </front> |
---|
3203 | <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p2-semantics-07"/> |
---|
3204 | |
---|
3205 | </reference> |
---|
3206 | |
---|
3207 | <reference anchor="Part3"> |
---|
3208 | <front> |
---|
3209 | <title abbrev="HTTP/1.1">HTTP/1.1, part 3: Message Payload and Content Negotiation</title> |
---|
3210 | <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor"> |
---|
3211 | <organization abbrev="Day Software">Day Software</organization> |
---|
3212 | <address><email>fielding@gbiv.com</email></address> |
---|
3213 | </author> |
---|
3214 | <author initials="J." surname="Gettys" fullname="Jim Gettys"> |
---|
3215 | <organization>One Laptop per Child</organization> |
---|
3216 | <address><email>jg@laptop.org</email></address> |
---|
3217 | </author> |
---|
3218 | <author initials="J." surname="Mogul" fullname="Jeffrey C. Mogul"> |
---|
3219 | <organization abbrev="HP">Hewlett-Packard Company</organization> |
---|
3220 | <address><email>JeffMogul@acm.org</email></address> |
---|
3221 | </author> |
---|
3222 | <author initials="H." surname="Frystyk" fullname="Henrik Frystyk Nielsen"> |
---|
3223 | <organization abbrev="Microsoft">Microsoft Corporation</organization> |
---|
3224 | <address><email>henrikn@microsoft.com</email></address> |
---|
3225 | </author> |
---|
3226 | <author initials="L." surname="Masinter" fullname="Larry Masinter"> |
---|
3227 | <organization abbrev="Adobe Systems">Adobe Systems, Incorporated</organization> |
---|
3228 | <address><email>LMM@acm.org</email></address> |
---|
3229 | </author> |
---|
3230 | <author initials="P." surname="Leach" fullname="Paul J. Leach"> |
---|
3231 | <organization abbrev="Microsoft">Microsoft Corporation</organization> |
---|
3232 | <address><email>paulle@microsoft.com</email></address> |
---|
3233 | </author> |
---|
3234 | <author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee"> |
---|
3235 | <organization abbrev="W3C/MIT">World Wide Web Consortium</organization> |
---|
3236 | <address><email>timbl@w3.org</email></address> |
---|
3237 | </author> |
---|
3238 | <author initials="Y." surname="Lafon" fullname="Yves Lafon" role="editor"> |
---|
3239 | <organization abbrev="W3C">World Wide Web Consortium</organization> |
---|
3240 | <address><email>ylafon@w3.org</email></address> |
---|
3241 | </author> |
---|
3242 | <author initials="J. F." surname="Reschke" fullname="Julian F. Reschke" role="editor"> |
---|
3243 | <organization abbrev="greenbytes">greenbytes GmbH</organization> |
---|
3244 | <address><email>julian.reschke@greenbytes.de</email></address> |
---|
3245 | </author> |
---|
3246 | <date month="July" year="2009"/> |
---|
3247 | </front> |
---|
3248 | <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p3-payload-07"/> |
---|
3249 | |
---|
3250 | </reference> |
---|
3251 | |
---|
3252 | <reference anchor="Part5"> |
---|
3253 | <front> |
---|
3254 | <title abbrev="HTTP/1.1">HTTP/1.1, part 5: Range Requests and Partial Responses</title> |
---|
3255 | <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor"> |
---|
3256 | <organization abbrev="Day Software">Day Software</organization> |
---|
3257 | <address><email>fielding@gbiv.com</email></address> |
---|
3258 | </author> |
---|
3259 | <author initials="J." surname="Gettys" fullname="Jim Gettys"> |
---|
3260 | <organization>One Laptop per Child</organization> |
---|
3261 | <address><email>jg@laptop.org</email></address> |
---|
3262 | </author> |
---|
3263 | <author initials="J." surname="Mogul" fullname="Jeffrey C. Mogul"> |
---|
3264 | <organization abbrev="HP">Hewlett-Packard Company</organization> |
---|
3265 | <address><email>JeffMogul@acm.org</email></address> |
---|
3266 | </author> |
---|
3267 | <author initials="H." surname="Frystyk" fullname="Henrik Frystyk Nielsen"> |
---|
3268 | <organization abbrev="Microsoft">Microsoft Corporation</organization> |
---|
3269 | <address><email>henrikn@microsoft.com</email></address> |
---|
3270 | </author> |
---|
3271 | <author initials="L." surname="Masinter" fullname="Larry Masinter"> |
---|
3272 | <organization abbrev="Adobe Systems">Adobe Systems, Incorporated</organization> |
---|
3273 | <address><email>LMM@acm.org</email></address> |
---|
3274 | </author> |
---|
3275 | <author initials="P." surname="Leach" fullname="Paul J. Leach"> |
---|
3276 | <organization abbrev="Microsoft">Microsoft Corporation</organization> |
---|
3277 | <address><email>paulle@microsoft.com</email></address> |
---|
3278 | </author> |
---|
3279 | <author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee"> |
---|
3280 | <organization abbrev="W3C/MIT">World Wide Web Consortium</organization> |
---|
3281 | <address><email>timbl@w3.org</email></address> |
---|
3282 | </author> |
---|
3283 | <author initials="Y." surname="Lafon" fullname="Yves Lafon" role="editor"> |
---|
3284 | <organization abbrev="W3C">World Wide Web Consortium</organization> |
---|
3285 | <address><email>ylafon@w3.org</email></address> |
---|
3286 | </author> |
---|
3287 | <author initials="J. F." surname="Reschke" fullname="Julian F. Reschke" role="editor"> |
---|
3288 | <organization abbrev="greenbytes">greenbytes GmbH</organization> |
---|
3289 | <address><email>julian.reschke@greenbytes.de</email></address> |
---|
3290 | </author> |
---|
3291 | <date month="July" year="2009"/> |
---|
3292 | </front> |
---|
3293 | <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p5-range-07"/> |
---|
3294 | |
---|
3295 | </reference> |
---|
3296 | |
---|
3297 | <reference anchor="Part6"> |
---|
3298 | <front> |
---|
3299 | <title abbrev="HTTP/1.1">HTTP/1.1, part 6: Caching</title> |
---|
3300 | <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor"> |
---|
3301 | <organization abbrev="Day Software">Day Software</organization> |
---|
3302 | <address><email>fielding@gbiv.com</email></address> |
---|
3303 | </author> |
---|
3304 | <author initials="J." surname="Gettys" fullname="Jim Gettys"> |
---|
3305 | <organization>One Laptop per Child</organization> |
---|
3306 | <address><email>jg@laptop.org</email></address> |
---|
3307 | </author> |
---|
3308 | <author initials="J." surname="Mogul" fullname="Jeffrey C. Mogul"> |
---|
3309 | <organization abbrev="HP">Hewlett-Packard Company</organization> |
---|
3310 | <address><email>JeffMogul@acm.org</email></address> |
---|
3311 | </author> |
---|
3312 | <author initials="H." surname="Frystyk" fullname="Henrik Frystyk Nielsen"> |
---|
3313 | <organization abbrev="Microsoft">Microsoft Corporation</organization> |
---|
3314 | <address><email>henrikn@microsoft.com</email></address> |
---|
3315 | </author> |
---|
3316 | <author initials="L." surname="Masinter" fullname="Larry Masinter"> |
---|
3317 | <organization abbrev="Adobe Systems">Adobe Systems, Incorporated</organization> |
---|
3318 | <address><email>LMM@acm.org</email></address> |
---|
3319 | </author> |
---|
3320 | <author initials="P." surname="Leach" fullname="Paul J. Leach"> |
---|
3321 | <organization abbrev="Microsoft">Microsoft Corporation</organization> |
---|
3322 | <address><email>paulle@microsoft.com</email></address> |
---|
3323 | </author> |
---|
3324 | <author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee"> |
---|
3325 | <organization abbrev="W3C/MIT">World Wide Web Consortium</organization> |
---|
3326 | <address><email>timbl@w3.org</email></address> |
---|
3327 | </author> |
---|
3328 | <author initials="Y." surname="Lafon" fullname="Yves Lafon" role="editor"> |
---|
3329 | <organization abbrev="W3C">World Wide Web Consortium</organization> |
---|
3330 | <address><email>ylafon@w3.org</email></address> |
---|
3331 | </author> |
---|
3332 | <author initials="M." surname="Nottingham" fullname="Mark Nottingham" role="editor"> |
---|
3333 | <organization/> |
---|
3334 | <address><email>mnot@mnot.net</email></address> |
---|
3335 | </author> |
---|
3336 | <author initials="J. F." surname="Reschke" fullname="Julian F. Reschke" role="editor"> |
---|
3337 | <organization abbrev="greenbytes">greenbytes GmbH</organization> |
---|
3338 | <address><email>julian.reschke@greenbytes.de</email></address> |
---|
3339 | </author> |
---|
3340 | <date month="July" year="2009"/> |
---|
3341 | </front> |
---|
3342 | <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p6-cache-07"/> |
---|
3343 | |
---|
3344 | </reference> |
---|
3345 | |
---|
3346 | <reference anchor="RFC5234"> |
---|
3347 | <front> |
---|
3348 | <title abbrev="ABNF for Syntax Specifications">Augmented BNF for Syntax Specifications: ABNF</title> |
---|
3349 | <author initials="D." surname="Crocker" fullname="Dave Crocker" role="editor"> |
---|
3350 | <organization>Brandenburg InternetWorking</organization> |
---|
3351 | <address> |
---|
3352 | <postal> |
---|
3353 | <street>675 Spruce Dr.</street> |
---|
3354 | <city>Sunnyvale</city> |
---|
3355 | <region>CA</region> |
---|
3356 | <code>94086</code> |
---|
3357 | <country>US</country></postal> |
---|
3358 | <phone>+1.408.246.8253</phone> |
---|
3359 | <email>dcrocker@bbiw.net</email></address> |
---|
3360 | </author> |
---|
3361 | <author initials="P." surname="Overell" fullname="Paul Overell"> |
---|
3362 | <organization>THUS plc.</organization> |
---|
3363 | <address> |
---|
3364 | <postal> |
---|
3365 | <street>1/2 Berkeley Square</street> |
---|
3366 | <street>99 Berkely Street</street> |
---|
3367 | <city>Glasgow</city> |
---|
3368 | <code>G3 7HR</code> |
---|
3369 | <country>UK</country></postal> |
---|
3370 | <email>paul.overell@thus.net</email></address> |
---|
3371 | </author> |
---|
3372 | <date month="January" year="2008"/> |
---|
3373 | </front> |
---|
3374 | <seriesInfo name="STD" value="68"/> |
---|
3375 | <seriesInfo name="RFC" value="5234"/> |
---|
3376 | </reference> |
---|
3377 | |
---|
3378 | <reference anchor="RFC2119"> |
---|
3379 | <front> |
---|
3380 | <title>Key words for use in RFCs to Indicate Requirement Levels</title> |
---|
3381 | <author initials="S." surname="Bradner" fullname="Scott Bradner"> |
---|
3382 | <organization>Harvard University</organization> |
---|
3383 | <address><email>sob@harvard.edu</email></address> |
---|
3384 | </author> |
---|
3385 | <date month="March" year="1997"/> |
---|
3386 | </front> |
---|
3387 | <seriesInfo name="BCP" value="14"/> |
---|
3388 | <seriesInfo name="RFC" value="2119"/> |
---|
3389 | </reference> |
---|
3390 | |
---|
3391 | <reference anchor="RFC3986"> |
---|
3392 | <front> |
---|
3393 | <title abbrev="URI Generic Syntax">Uniform Resource Identifier (URI): Generic Syntax</title> |
---|
3394 | <author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee"> |
---|
3395 | <organization abbrev="W3C/MIT">World Wide Web Consortium</organization> |
---|
3396 | <address> |
---|
3397 | <email>timbl@w3.org</email> |
---|
3398 | <uri>http://www.w3.org/People/Berners-Lee/</uri> |
---|
3399 | </address> |
---|
3400 | </author> |
---|
3401 | <author initials="R." surname="Fielding" fullname="Roy T. Fielding"> |
---|
3402 | <organization abbrev="Day Software">Day Software</organization> |
---|
3403 | <address> |
---|
3404 | <email>fielding@gbiv.com</email> |
---|
3405 | <uri>http://roy.gbiv.com/</uri> |
---|
3406 | </address> |
---|
3407 | </author> |
---|
3408 | <author initials="L." surname="Masinter" fullname="Larry Masinter"> |
---|
3409 | <organization abbrev="Adobe Systems">Adobe Systems Incorporated</organization> |
---|
3410 | <address> |
---|
3411 | <email>LMM@acm.org</email> |
---|
3412 | <uri>http://larry.masinter.net/</uri> |
---|
3413 | </address> |
---|
3414 | </author> |
---|
3415 | <date month="January" year="2005"/> |
---|
3416 | </front> |
---|
3417 | <seriesInfo name="RFC" value="3986"/> |
---|
3418 | <seriesInfo name="STD" value="66"/> |
---|
3419 | </reference> |
---|
3420 | |
---|
3421 | <reference anchor="USASCII"> |
---|
3422 | <front> |
---|
3423 | <title>Coded Character Set -- 7-bit American Standard Code for Information Interchange</title> |
---|
3424 | <author> |
---|
3425 | <organization>American National Standards Institute</organization> |
---|
3426 | </author> |
---|
3427 | <date year="1986"/> |
---|
3428 | </front> |
---|
3429 | <seriesInfo name="ANSI" value="X3.4"/> |
---|
3430 | </reference> |
---|
3431 | |
---|
3432 | </references> |
---|
3433 | |
---|
3434 | <references title="Informative References"> |
---|
3435 | |
---|
3436 | <reference anchor="Nie1997" target="http://doi.acm.org/10.1145/263105.263157"> |
---|
3437 | <front> |
---|
3438 | <title>Network Performance Effects of HTTP/1.1, CSS1, and PNG</title> |
---|
3439 | <author initials="H.F.." surname="Nielsen" fullname="H.F. Nielsen"> |
---|
3440 | <organization/> |
---|
3441 | </author> |
---|
3442 | <author initials="J." surname="Gettys" fullname="J. Gettys"> |
---|
3443 | <organization/> |
---|
3444 | </author> |
---|
3445 | <author initials="E." surname="Prud'hommeaux" fullname="E. Prud'hommeaux"> |
---|
3446 | <organization/> |
---|
3447 | </author> |
---|
3448 | <author initials="H." surname="Lie" fullname="H. Lie"> |
---|
3449 | <organization/> |
---|
3450 | </author> |
---|
3451 | <author initials="C." surname="Lilley" fullname="C. Lilley"> |
---|
3452 | <organization/> |
---|
3453 | </author> |
---|
3454 | <date year="1997" month="September"/> |
---|
3455 | </front> |
---|
3456 | <seriesInfo name="ACM" value="Proceedings of the ACM SIGCOMM '97 conference on Applications, technologies, architectures, and protocols for computer communication SIGCOMM '97"/> |
---|
3457 | </reference> |
---|
3458 | |
---|
3459 | <reference anchor="Pad1995" target="http://portal.acm.org/citation.cfm?id=219094"> |
---|
3460 | <front> |
---|
3461 | <title>Improving HTTP Latency</title> |
---|
3462 | <author initials="V.N." surname="Padmanabhan" fullname="Venkata N. Padmanabhan"> |
---|
3463 | <organization/> |
---|
3464 | </author> |
---|
3465 | <author initials="J.C." surname="Mogul" fullname="Jeffrey C. Mogul"> |
---|
3466 | <organization/> |
---|
3467 | </author> |
---|
3468 | <date year="1995" month="December"/> |
---|
3469 | </front> |
---|
3470 | <seriesInfo name="Computer Networks and ISDN Systems" value="v. 28, pp. 25-35"/> |
---|
3471 | </reference> |
---|
3472 | |
---|
3473 | <reference anchor="RFC1123"> |
---|
3474 | <front> |
---|
3475 | <title>Requirements for Internet Hosts - Application and Support</title> |
---|
3476 | <author initials="R." surname="Braden" fullname="Robert Braden"> |
---|
3477 | <organization>University of Southern California (USC), Information Sciences Institute</organization> |
---|
3478 | <address><email>Braden@ISI.EDU</email></address> |
---|
3479 | </author> |
---|
3480 | <date month="October" year="1989"/> |
---|
3481 | </front> |
---|
3482 | <seriesInfo name="STD" value="3"/> |
---|
3483 | <seriesInfo name="RFC" value="1123"/> |
---|
3484 | </reference> |
---|
3485 | |
---|
3486 | <reference anchor="RFC1305"> |
---|
3487 | <front> |
---|
3488 | <title>Network Time Protocol (Version 3) Specification, Implementation</title> |
---|
3489 | <author initials="D." surname="Mills" fullname="David L. Mills"> |
---|
3490 | <organization>University of Delaware, Electrical Engineering Department</organization> |
---|
3491 | <address><email>mills@udel.edu</email></address> |
---|
3492 | </author> |
---|
3493 | <date month="March" year="1992"/> |
---|
3494 | </front> |
---|
3495 | <seriesInfo name="RFC" value="1305"/> |
---|
3496 | </reference> |
---|
3497 | |
---|
3498 | <reference anchor="RFC1900"> |
---|
3499 | <front> |
---|
3500 | <title>Renumbering Needs Work</title> |
---|
3501 | <author initials="B." surname="Carpenter" fullname="Brian E. Carpenter"> |
---|
3502 | <organization>CERN, Computing and Networks Division</organization> |
---|
3503 | <address><email>brian@dxcoms.cern.ch</email></address> |
---|
3504 | </author> |
---|
3505 | <author initials="Y." surname="Rekhter" fullname="Yakov Rekhter"> |
---|
3506 | <organization>cisco Systems</organization> |
---|
3507 | <address><email>yakov@cisco.com</email></address> |
---|
3508 | </author> |
---|
3509 | <date month="February" year="1996"/> |
---|
3510 | </front> |
---|
3511 | <seriesInfo name="RFC" value="1900"/> |
---|
3512 | </reference> |
---|
3513 | |
---|
3514 | <reference anchor="RFC1945"> |
---|
3515 | <front> |
---|
3516 | <title abbrev="HTTP/1.0">Hypertext Transfer Protocol -- HTTP/1.0</title> |
---|
3517 | <author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee"> |
---|
3518 | <organization>MIT, Laboratory for Computer Science</organization> |
---|
3519 | <address><email>timbl@w3.org</email></address> |
---|
3520 | </author> |
---|
3521 | <author initials="R.T." surname="Fielding" fullname="Roy T. Fielding"> |
---|
3522 | <organization>University of California, Irvine, Department of Information and Computer Science</organization> |
---|
3523 | <address><email>fielding@ics.uci.edu</email></address> |
---|
3524 | </author> |
---|
3525 | <author initials="H.F." surname="Nielsen" fullname="Henrik Frystyk Nielsen"> |
---|
3526 | <organization>W3 Consortium, MIT Laboratory for Computer Science</organization> |
---|
3527 | <address><email>frystyk@w3.org</email></address> |
---|
3528 | </author> |
---|
3529 | <date month="May" year="1996"/> |
---|
3530 | </front> |
---|
3531 | <seriesInfo name="RFC" value="1945"/> |
---|
3532 | </reference> |
---|
3533 | |
---|
3534 | <reference anchor="RFC2045"> |
---|
3535 | <front> |
---|
3536 | <title abbrev="Internet Message Bodies">Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies</title> |
---|
3537 | <author initials="N." surname="Freed" fullname="Ned Freed"> |
---|
3538 | <organization>Innosoft International, Inc.</organization> |
---|
3539 | <address><email>ned@innosoft.com</email></address> |
---|
3540 | </author> |
---|
3541 | <author initials="N.S." surname="Borenstein" fullname="Nathaniel S. Borenstein"> |
---|
3542 | <organization>First Virtual Holdings</organization> |
---|
3543 | <address><email>nsb@nsb.fv.com</email></address> |
---|
3544 | </author> |
---|
3545 | <date month="November" year="1996"/> |
---|
3546 | </front> |
---|
3547 | <seriesInfo name="RFC" value="2045"/> |
---|
3548 | </reference> |
---|
3549 | |
---|
3550 | <reference anchor="RFC2047"> |
---|
3551 | <front> |
---|
3552 | <title abbrev="Message Header Extensions">MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text</title> |
---|
3553 | <author initials="K." surname="Moore" fullname="Keith Moore"> |
---|
3554 | <organization>University of Tennessee</organization> |
---|
3555 | <address><email>moore@cs.utk.edu</email></address> |
---|
3556 | </author> |
---|
3557 | <date month="November" year="1996"/> |
---|
3558 | </front> |
---|
3559 | <seriesInfo name="RFC" value="2047"/> |
---|
3560 | </reference> |
---|
3561 | |
---|
3562 | <reference anchor="RFC2068"> |
---|
3563 | <front> |
---|
3564 | <title abbrev="HTTP/1.1">Hypertext Transfer Protocol -- HTTP/1.1</title> |
---|
3565 | <author initials="R." surname="Fielding" fullname="Roy T. Fielding"> |
---|
3566 | <organization>University of California, Irvine, Department of Information and Computer Science</organization> |
---|
3567 | <address><email>fielding@ics.uci.edu</email></address> |
---|
3568 | </author> |
---|
3569 | <author initials="J." surname="Gettys" fullname="Jim Gettys"> |
---|
3570 | <organization>MIT Laboratory for Computer Science</organization> |
---|
3571 | <address><email>jg@w3.org</email></address> |
---|
3572 | </author> |
---|
3573 | <author initials="J." surname="Mogul" fullname="Jeffrey C. Mogul"> |
---|
3574 | <organization>Digital Equipment Corporation, Western Research Laboratory</organization> |
---|
3575 | <address><email>mogul@wrl.dec.com</email></address> |
---|
3576 | </author> |
---|
3577 | <author initials="H." surname="Nielsen" fullname="Henrik Frystyk Nielsen"> |
---|
3578 | <organization>MIT Laboratory for Computer Science</organization> |
---|
3579 | <address><email>frystyk@w3.org</email></address> |
---|
3580 | </author> |
---|
3581 | <author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee"> |
---|
3582 | <organization>MIT Laboratory for Computer Science</organization> |
---|
3583 | <address><email>timbl@w3.org</email></address> |
---|
3584 | </author> |
---|
3585 | <date month="January" year="1997"/> |
---|
3586 | </front> |
---|
3587 | <seriesInfo name="RFC" value="2068"/> |
---|
3588 | </reference> |
---|
3589 | |
---|
3590 | <reference anchor="RFC2109"> |
---|
3591 | <front> |
---|
3592 | <title>HTTP State Management Mechanism</title> |
---|
3593 | <author initials="D.M." surname="Kristol" fullname="David M. Kristol"> |
---|
3594 | <organization>Bell Laboratories, Lucent Technologies</organization> |
---|
3595 | <address><email>dmk@bell-labs.com</email></address> |
---|
3596 | </author> |
---|
3597 | <author initials="L." surname="Montulli" fullname="Lou Montulli"> |
---|
3598 | <organization>Netscape Communications Corp.</organization> |
---|
3599 | <address><email>montulli@netscape.com</email></address> |
---|
3600 | </author> |
---|
3601 | <date year="1997" month="February"/> |
---|
3602 | </front> |
---|
3603 | <seriesInfo name="RFC" value="2109"/> |
---|
3604 | </reference> |
---|
3605 | |
---|
3606 | <reference anchor="RFC2145"> |
---|
3607 | <front> |
---|
3608 | <title abbrev="HTTP Version Numbers">Use and Interpretation of HTTP Version Numbers</title> |
---|
3609 | <author initials="J.C." surname="Mogul" fullname="Jeffrey C. Mogul"> |
---|
3610 | <organization>Western Research Laboratory</organization> |
---|
3611 | <address><email>mogul@wrl.dec.com</email></address> |
---|
3612 | </author> |
---|
3613 | <author initials="R.T." surname="Fielding" fullname="Roy T. Fielding"> |
---|
3614 | <organization>Department of Information and Computer Science</organization> |
---|
3615 | <address><email>fielding@ics.uci.edu</email></address> |
---|
3616 | </author> |
---|
3617 | <author initials="J." surname="Gettys" fullname="Jim Gettys"> |
---|
3618 | <organization>MIT Laboratory for Computer Science</organization> |
---|
3619 | <address><email>jg@w3.org</email></address> |
---|
3620 | </author> |
---|
3621 | <author initials="H.F." surname="Nielsen" fullname="Henrik Frystyk Nielsen"> |
---|
3622 | <organization>W3 Consortium</organization> |
---|
3623 | <address><email>frystyk@w3.org</email></address> |
---|
3624 | </author> |
---|
3625 | <date month="May" year="1997"/> |
---|
3626 | </front> |
---|
3627 | <seriesInfo name="RFC" value="2145"/> |
---|
3628 | </reference> |
---|
3629 | |
---|
3630 | <reference anchor="RFC2616"> |
---|
3631 | <front> |
---|
3632 | <title>Hypertext Transfer Protocol -- HTTP/1.1</title> |
---|
3633 | <author initials="R." surname="Fielding" fullname="R. Fielding"> |
---|
3634 | <organization>University of California, Irvine</organization> |
---|
3635 | <address><email>fielding@ics.uci.edu</email></address> |
---|
3636 | </author> |
---|
3637 | <author initials="J." surname="Gettys" fullname="J. Gettys"> |
---|
3638 | <organization>W3C</organization> |
---|
3639 | <address><email>jg@w3.org</email></address> |
---|
3640 | </author> |
---|
3641 | <author initials="J." surname="Mogul" fullname="J. Mogul"> |
---|
3642 | <organization>Compaq Computer Corporation</organization> |
---|
3643 | <address><email>mogul@wrl.dec.com</email></address> |
---|
3644 | </author> |
---|
3645 | <author initials="H." surname="Frystyk" fullname="H. Frystyk"> |
---|
3646 | <organization>MIT Laboratory for Computer Science</organization> |
---|
3647 | <address><email>frystyk@w3.org</email></address> |
---|
3648 | </author> |
---|
3649 | <author initials="L." surname="Masinter" fullname="L. Masinter"> |
---|
3650 | <organization>Xerox Corporation</organization> |
---|
3651 | <address><email>masinter@parc.xerox.com</email></address> |
---|
3652 | </author> |
---|
3653 | <author initials="P." surname="Leach" fullname="P. Leach"> |
---|
3654 | <organization>Microsoft Corporation</organization> |
---|
3655 | <address><email>paulle@microsoft.com</email></address> |
---|
3656 | </author> |
---|
3657 | <author initials="T." surname="Berners-Lee" fullname="T. Berners-Lee"> |
---|
3658 | <organization>W3C</organization> |
---|
3659 | <address><email>timbl@w3.org</email></address> |
---|
3660 | </author> |
---|
3661 | <date month="June" year="1999"/> |
---|
3662 | </front> |
---|
3663 | <seriesInfo name="RFC" value="2616"/> |
---|
3664 | </reference> |
---|
3665 | |
---|
3666 | <reference anchor="RFC2818"> |
---|
3667 | <front> |
---|
3668 | <title>HTTP Over TLS</title> |
---|
3669 | <author initials="E." surname="Rescorla" fullname="Eric Rescorla"> |
---|
3670 | <organization>RTFM, Inc.</organization> |
---|
3671 | <address><email>ekr@rtfm.com</email></address> |
---|
3672 | </author> |
---|
3673 | <date year="2000" month="May"/> |
---|
3674 | </front> |
---|
3675 | <seriesInfo name="RFC" value="2818"/> |
---|
3676 | </reference> |
---|
3677 | |
---|
3678 | <reference anchor="RFC2965"> |
---|
3679 | <front> |
---|
3680 | <title>HTTP State Management Mechanism</title> |
---|
3681 | <author initials="D. M." surname="Kristol" fullname="David M. Kristol"> |
---|
3682 | <organization>Bell Laboratories, Lucent Technologies</organization> |
---|
3683 | <address><email>dmk@bell-labs.com</email></address> |
---|
3684 | </author> |
---|
3685 | <author initials="L." surname="Montulli" fullname="Lou Montulli"> |
---|
3686 | <organization>Epinions.com, Inc.</organization> |
---|
3687 | <address><email>lou@montulli.org</email></address> |
---|
3688 | </author> |
---|
3689 | <date year="2000" month="October"/> |
---|
3690 | </front> |
---|
3691 | <seriesInfo name="RFC" value="2965"/> |
---|
3692 | </reference> |
---|
3693 | |
---|
3694 | <reference anchor="RFC3864"> |
---|
3695 | <front> |
---|
3696 | <title>Registration Procedures for Message Header Fields</title> |
---|
3697 | <author initials="G." surname="Klyne" fullname="G. Klyne"> |
---|
3698 | <organization>Nine by Nine</organization> |
---|
3699 | <address><email>GK-IETF@ninebynine.org</email></address> |
---|
3700 | </author> |
---|
3701 | <author initials="M." surname="Nottingham" fullname="M. Nottingham"> |
---|
3702 | <organization>BEA Systems</organization> |
---|
3703 | <address><email>mnot@pobox.com</email></address> |
---|
3704 | </author> |
---|
3705 | <author initials="J." surname="Mogul" fullname="J. Mogul"> |
---|
3706 | <organization>HP Labs</organization> |
---|
3707 | <address><email>JeffMogul@acm.org</email></address> |
---|
3708 | </author> |
---|
3709 | <date year="2004" month="September"/> |
---|
3710 | </front> |
---|
3711 | <seriesInfo name="BCP" value="90"/> |
---|
3712 | <seriesInfo name="RFC" value="3864"/> |
---|
3713 | </reference> |
---|
3714 | |
---|
3715 | <reference anchor="RFC4288"> |
---|
3716 | <front> |
---|
3717 | <title>Media Type Specifications and Registration Procedures</title> |
---|
3718 | <author initials="N." surname="Freed" fullname="N. Freed"> |
---|
3719 | <organization>Sun Microsystems</organization> |
---|
3720 | <address> |
---|
3721 | <email>ned.freed@mrochek.com</email> |
---|
3722 | </address> |
---|
3723 | </author> |
---|
3724 | <author initials="J." surname="Klensin" fullname="J. Klensin"> |
---|
3725 | <organization/> |
---|
3726 | <address> |
---|
3727 | <email>klensin+ietf@jck.com</email> |
---|
3728 | </address> |
---|
3729 | </author> |
---|
3730 | <date year="2005" month="December"/> |
---|
3731 | </front> |
---|
3732 | <seriesInfo name="BCP" value="13"/> |
---|
3733 | <seriesInfo name="RFC" value="4288"/> |
---|
3734 | </reference> |
---|
3735 | |
---|
3736 | <reference anchor="RFC4395"> |
---|
3737 | <front> |
---|
3738 | <title>Guidelines and Registration Procedures for New URI Schemes</title> |
---|
3739 | <author initials="T." surname="Hansen" fullname="T. Hansen"> |
---|
3740 | <organization>AT&T Laboratories</organization> |
---|
3741 | <address> |
---|
3742 | <email>tony+urireg@maillennium.att.com</email> |
---|
3743 | </address> |
---|
3744 | </author> |
---|
3745 | <author initials="T." surname="Hardie" fullname="T. Hardie"> |
---|
3746 | <organization>Qualcomm, Inc.</organization> |
---|
3747 | <address> |
---|
3748 | <email>hardie@qualcomm.com</email> |
---|
3749 | </address> |
---|
3750 | </author> |
---|
3751 | <author initials="L." surname="Masinter" fullname="L. Masinter"> |
---|
3752 | <organization>Adobe Systems</organization> |
---|
3753 | <address> |
---|
3754 | <email>LMM@acm.org</email> |
---|
3755 | </address> |
---|
3756 | </author> |
---|
3757 | <date year="2006" month="February"/> |
---|
3758 | </front> |
---|
3759 | <seriesInfo name="BCP" value="115"/> |
---|
3760 | <seriesInfo name="RFC" value="4395"/> |
---|
3761 | </reference> |
---|
3762 | |
---|
3763 | <reference anchor="RFC5322"> |
---|
3764 | <front> |
---|
3765 | <title>Internet Message Format</title> |
---|
3766 | <author initials="P." surname="Resnick" fullname="P. Resnick"> |
---|
3767 | <organization>Qualcomm Incorporated</organization> |
---|
3768 | </author> |
---|
3769 | <date year="2008" month="October"/> |
---|
3770 | </front> |
---|
3771 | <seriesInfo name="RFC" value="5322"/> |
---|
3772 | </reference> |
---|
3773 | |
---|
3774 | <reference anchor="Kri2001" target="http://arxiv.org/abs/cs.SE/0105018"> |
---|
3775 | <front> |
---|
3776 | <title>HTTP Cookies: Standards, Privacy, and Politics</title> |
---|
3777 | <author initials="D." surname="Kristol" fullname="David M. Kristol"> |
---|
3778 | <organization/> |
---|
3779 | </author> |
---|
3780 | <date year="2001" month="November"/> |
---|
3781 | </front> |
---|
3782 | <seriesInfo name="ACM Transactions on Internet Technology" value="Vol. 1, #2"/> |
---|
3783 | </reference> |
---|
3784 | |
---|
3785 | <reference anchor="Spe" target="http://sunsite.unc.edu/mdma-release/http-prob.html"> |
---|
3786 | <front> |
---|
3787 | <title>Analysis of HTTP Performance Problems</title> |
---|
3788 | <author initials="S." surname="Spero" fullname="Simon E. Spero"> |
---|
3789 | <organization/> |
---|
3790 | </author> |
---|
3791 | <date/> |
---|
3792 | </front> |
---|
3793 | </reference> |
---|
3794 | |
---|
3795 | <reference anchor="Tou1998" target="http://www.isi.edu/touch/pubs/http-perf96/"> |
---|
3796 | <front> |
---|
3797 | <title>Analysis of HTTP Performance</title> |
---|
3798 | <author initials="J." surname="Touch" fullname="Joe Touch"> |
---|
3799 | <organization>USC/Information Sciences Institute</organization> |
---|
3800 | <address><email>touch@isi.edu</email></address> |
---|
3801 | </author> |
---|
3802 | <author initials="J." surname="Heidemann" fullname="John Heidemann"> |
---|
3803 | <organization>USC/Information Sciences Institute</organization> |
---|
3804 | <address><email>johnh@isi.edu</email></address> |
---|
3805 | </author> |
---|
3806 | <author initials="K." surname="Obraczka" fullname="Katia Obraczka"> |
---|
3807 | <organization>USC/Information Sciences Institute</organization> |
---|
3808 | <address><email>katia@isi.edu</email></address> |
---|
3809 | </author> |
---|
3810 | <date year="1998" month="Aug"/> |
---|
3811 | </front> |
---|
3812 | <seriesInfo name="ISI Research Report" value="ISI/RR-98-463"/> |
---|
3813 | <annotation>(original report dated Aug. 1996)</annotation> |
---|
3814 | </reference> |
---|
3815 | |
---|
3816 | </references> |
---|
3817 | |
---|
3818 | |
---|
3819 | <section title="Tolerant Applications" anchor="tolerant.applications"> |
---|
3820 | <t> |
---|
3821 | Although this document specifies the requirements for the generation |
---|
3822 | of HTTP/1.1 messages, not all applications will be correct in their |
---|
3823 | implementation. We therefore recommend that operational applications |
---|
3824 | be tolerant of deviations whenever those deviations can be |
---|
3825 | interpreted unambiguously. |
---|
3826 | </t> |
---|
3827 | <t> |
---|
3828 | Clients SHOULD be tolerant in parsing the Status-Line and servers |
---|
3829 | tolerant when parsing the Request-Line. In particular, they SHOULD |
---|
3830 | accept any amount of WSP characters between fields, even though |
---|
3831 | only a single SP is required. |
---|
3832 | </t> |
---|
3833 | <t> |
---|
3834 | The line terminator for message-header fields is the sequence CRLF. |
---|
3835 | However, we recommend that applications, when parsing such headers, |
---|
3836 | recognize a single LF as a line terminator and ignore the leading CR. |
---|
3837 | </t> |
---|
3838 | <t> |
---|
3839 | The character set of an entity-body SHOULD be labeled as the lowest |
---|
3840 | common denominator of the character codes used within that body, with |
---|
3841 | the exception that not labeling the entity is preferred over labeling |
---|
3842 | the entity with the labels US-ASCII or ISO-8859-1. See <xref target="Part3"/>. |
---|
3843 | </t> |
---|
3844 | <t> |
---|
3845 | Additional rules for requirements on parsing and encoding of dates |
---|
3846 | and other potential problems with date encodings include: |
---|
3847 | </t> |
---|
3848 | <t> |
---|
3849 | <list style="symbols"> |
---|
3850 | <t>HTTP/1.1 clients and caches SHOULD assume that an RFC-850 date |
---|
3851 | which appears to be more than 50 years in the future is in fact |
---|
3852 | in the past (this helps solve the "year 2000" problem).</t> |
---|
3853 | |
---|
3854 | <t>An HTTP/1.1 implementation MAY internally represent a parsed |
---|
3855 | Expires date as earlier than the proper value, but MUST NOT |
---|
3856 | internally represent a parsed Expires date as later than the |
---|
3857 | proper value.</t> |
---|
3858 | |
---|
3859 | <t>All expiration-related calculations MUST be done in GMT. The |
---|
3860 | local time zone MUST NOT influence the calculation or comparison |
---|
3861 | of an age or expiration time.</t> |
---|
3862 | |
---|
3863 | <t>If an HTTP header incorrectly carries a date value with a time |
---|
3864 | zone other than GMT, it MUST be converted into GMT using the |
---|
3865 | most conservative possible conversion.</t> |
---|
3866 | </list> |
---|
3867 | </t> |
---|
3868 | </section> |
---|
3869 | |
---|
3870 | <section title="Compatibility with Previous Versions" anchor="compatibility"> |
---|
3871 | <t> |
---|
3872 | HTTP has been in use by the World-Wide Web global information initiative |
---|
3873 | since 1990. The first version of HTTP, later referred to as HTTP/0.9, |
---|
3874 | was a simple protocol for hypertext data transfer across the Internet |
---|
3875 | with only a single method and no metadata. |
---|
3876 | HTTP/1.0, as defined by <xref target="RFC1945"/>, added a range of request |
---|
3877 | methods and MIME-like messaging that could include metadata about the data |
---|
3878 | transferred and modifiers on the request/response semantics. However, |
---|
3879 | HTTP/1.0 did not sufficiently take into consideration the effects of |
---|
3880 | hierarchical proxies, caching, the need for persistent connections, or |
---|
3881 | name-based virtual hosts. The proliferation of incompletely-implemented |
---|
3882 | applications calling themselves "HTTP/1.0" further necessitated a |
---|
3883 | protocol version change in order for two communicating applications |
---|
3884 | to determine each other's true capabilities. |
---|
3885 | </t> |
---|
3886 | <t> |
---|
3887 | HTTP/1.1 remains compatible with HTTP/1.0 by including more stringent |
---|
3888 | requirements that enable reliable implementations, adding only |
---|
3889 | those new features that will either be safely ignored by an HTTP/1.0 |
---|
3890 | recipient or only sent when communicating with a party advertising |
---|
3891 | compliance with HTTP/1.1. |
---|
3892 | </t> |
---|
3893 | <t> |
---|
3894 | It is beyond the scope of a protocol specification to mandate |
---|
3895 | compliance with previous versions. HTTP/1.1 was deliberately |
---|
3896 | designed, however, to make supporting previous versions easy. It is |
---|
3897 | worth noting that, at the time of composing this specification |
---|
3898 | (1996), we would expect commercial HTTP/1.1 servers to: |
---|
3899 | <list style="symbols"> |
---|
3900 | <t>recognize the format of the Request-Line for HTTP/0.9, 1.0, and |
---|
3901 | 1.1 requests;</t> |
---|
3902 | |
---|
3903 | <t>understand any valid request in the format of HTTP/0.9, 1.0, or |
---|
3904 | 1.1;</t> |
---|
3905 | |
---|
3906 | <t>respond appropriately with a message in the same major version |
---|
3907 | used by the client.</t> |
---|
3908 | </list> |
---|
3909 | </t> |
---|
3910 | <t> |
---|
3911 | And we would expect HTTP/1.1 clients to: |
---|
3912 | <list style="symbols"> |
---|
3913 | <t>recognize the format of the Status-Line for HTTP/1.0 and 1.1 |
---|
3914 | responses;</t> |
---|
3915 | |
---|
3916 | <t>understand any valid response in the format of HTTP/0.9, 1.0, or |
---|
3917 | 1.1.</t> |
---|
3918 | </list> |
---|
3919 | </t> |
---|
3920 | <t> |
---|
3921 | For most implementations of HTTP/1.0, each connection is established |
---|
3922 | by the client prior to the request and closed by the server after |
---|
3923 | sending the response. Some implementations implement the Keep-Alive |
---|
3924 | version of persistent connections described in Section 19.7.1 of <xref target="RFC2068"/>. |
---|
3925 | </t> |
---|
3926 | |
---|
3927 | <section title="Changes from HTTP/1.0" anchor="changes.from.1.0"> |
---|
3928 | <t> |
---|
3929 | This section summarizes major differences between versions HTTP/1.0 |
---|
3930 | and HTTP/1.1. |
---|
3931 | </t> |
---|
3932 | |
---|
3933 | <section title="Changes to Simplify Multi-homed Web Servers and Conserve IP Addresses" anchor="changes.to.simplify.multi-homed.web.servers.and.conserve.ip.addresses"> |
---|
3934 | <t> |
---|
3935 | The requirements that clients and servers support the Host request-header, |
---|
3936 | report an error if the Host request-header (<xref target="header.host"/>) is |
---|
3937 | missing from an HTTP/1.1 request, and accept absolute URIs (<xref target="request-target"/>) |
---|
3938 | are among the most important changes defined by this |
---|
3939 | specification. |
---|
3940 | </t> |
---|
3941 | <t> |
---|
3942 | Older HTTP/1.0 clients assumed a one-to-one relationship of IP |
---|
3943 | addresses and servers; there was no other established mechanism for |
---|
3944 | distinguishing the intended server of a request than the IP address |
---|
3945 | to which that request was directed. The changes outlined above will |
---|
3946 | allow the Internet, once older HTTP clients are no longer common, to |
---|
3947 | support multiple Web sites from a single IP address, greatly |
---|
3948 | simplifying large operational Web servers, where allocation of many |
---|
3949 | IP addresses to a single host has created serious problems. The |
---|
3950 | Internet will also be able to recover the IP addresses that have been |
---|
3951 | allocated for the sole purpose of allowing special-purpose domain |
---|
3952 | names to be used in root-level HTTP URLs. Given the rate of growth of |
---|
3953 | the Web, and the number of servers already deployed, it is extremely |
---|
3954 | important that all implementations of HTTP (including updates to |
---|
3955 | existing HTTP/1.0 applications) correctly implement these |
---|
3956 | requirements: |
---|
3957 | <list style="symbols"> |
---|
3958 | <t>Both clients and servers MUST support the Host request-header.</t> |
---|
3959 | |
---|
3960 | <t>A client that sends an HTTP/1.1 request MUST send a Host header.</t> |
---|
3961 | |
---|
3962 | <t>Servers MUST report a 400 (Bad Request) error if an HTTP/1.1 |
---|
3963 | request does not include a Host request-header.</t> |
---|
3964 | |
---|
3965 | <t>Servers MUST accept absolute URIs.</t> |
---|
3966 | </list> |
---|
3967 | </t> |
---|
3968 | </section> |
---|
3969 | </section> |
---|
3970 | |
---|
3971 | <section title="Compatibility with HTTP/1.0 Persistent Connections" anchor="compatibility.with.http.1.0.persistent.connections"> |
---|
3972 | <t> |
---|
3973 | Some clients and servers might wish to be compatible with some |
---|
3974 | previous implementations of persistent connections in HTTP/1.0 |
---|
3975 | clients and servers. Persistent connections in HTTP/1.0 are |
---|
3976 | explicitly negotiated as they are not the default behavior. HTTP/1.0 |
---|
3977 | experimental implementations of persistent connections are faulty, |
---|
3978 | and the new facilities in HTTP/1.1 are designed to rectify these |
---|
3979 | problems. The problem was that some existing 1.0 clients may be |
---|
3980 | sending Keep-Alive to a proxy server that doesn't understand |
---|
3981 | Connection, which would then erroneously forward it to the next |
---|
3982 | inbound server, which would establish the Keep-Alive connection and |
---|
3983 | result in a hung HTTP/1.0 proxy waiting for the close on the |
---|
3984 | response. The result is that HTTP/1.0 clients must be prevented from |
---|
3985 | using Keep-Alive when talking to proxies. |
---|
3986 | </t> |
---|
3987 | <t> |
---|
3988 | However, talking to proxies is the most important use of persistent |
---|
3989 | connections, so that prohibition is clearly unacceptable. Therefore, |
---|
3990 | we need some other mechanism for indicating a persistent connection |
---|
3991 | is desired, which is safe to use even when talking to an old proxy |
---|
3992 | that ignores Connection. Persistent connections are the default for |
---|
3993 | HTTP/1.1 messages; we introduce a new keyword (Connection: close) for |
---|
3994 | declaring non-persistence. See <xref target="header.connection"/>. |
---|
3995 | </t> |
---|
3996 | <t> |
---|
3997 | The original HTTP/1.0 form of persistent connections (the Connection: |
---|
3998 | Keep-Alive and Keep-Alive header) is documented in Section 19.7.1 of <xref target="RFC2068"/>. |
---|
3999 | </t> |
---|
4000 | </section> |
---|
4001 | |
---|
4002 | <section title="Changes from RFC 2068" anchor="changes.from.rfc.2068"> |
---|
4003 | <t> |
---|
4004 | This specification has been carefully audited to correct and |
---|
4005 | disambiguate key word usage; RFC 2068 had many problems in respect to |
---|
4006 | the conventions laid out in <xref target="RFC2119"/>. |
---|
4007 | </t> |
---|
4008 | <t> |
---|
4009 | Transfer-coding and message lengths all interact in ways that |
---|
4010 | required fixing exactly when chunked encoding is used (to allow for |
---|
4011 | transfer encoding that may not be self delimiting); it was important |
---|
4012 | to straighten out exactly how message lengths are computed. (Sections |
---|
4013 | <xref target="transfer.codings" format="counter"/>, <xref target="message.length" format="counter"/>, |
---|
4014 | <xref target="header.content-length" format="counter"/>, |
---|
4015 | see also <xref target="Part3"/>, <xref target="Part5"/> and <xref target="Part6"/>) |
---|
4016 | </t> |
---|
4017 | <t> |
---|
4018 | The use and interpretation of HTTP version numbers has been clarified |
---|
4019 | by <xref target="RFC2145"/>. Require proxies to upgrade requests to highest protocol |
---|
4020 | version they support to deal with problems discovered in HTTP/1.0 |
---|
4021 | implementations (<xref target="http.version"/>) |
---|
4022 | </t> |
---|
4023 | <t> |
---|
4024 | Quality Values of zero should indicate that "I don't want something" |
---|
4025 | to allow clients to refuse a representation. (<xref target="quality.values"/>) |
---|
4026 | </t> |
---|
4027 | <t> |
---|
4028 | Transfer-coding had significant problems, particularly with |
---|
4029 | interactions with chunked encoding. The solution is that transfer-codings |
---|
4030 | become as full fledged as content-codings. This involves |
---|
4031 | adding an IANA registry for transfer-codings (separate from content |
---|
4032 | codings), a new header field (TE) and enabling trailer headers in the |
---|
4033 | future. Transfer encoding is a major performance benefit, so it was |
---|
4034 | worth fixing <xref target="Nie1997"/>. TE also solves another, obscure, downward |
---|
4035 | interoperability problem that could have occurred due to interactions |
---|
4036 | between authentication trailers, chunked encoding and HTTP/1.0 |
---|
4037 | clients.(Section <xref target="transfer.codings" format="counter"/>, <xref target="chunked.transfer.encoding" format="counter"/>, |
---|
4038 | and <xref target="header.te" format="counter"/>) |
---|
4039 | </t> |
---|
4040 | </section> |
---|
4041 | |
---|
4042 | <section title="Changes from RFC 2616" anchor="changes.from.rfc.2616"> |
---|
4043 | <t> |
---|
4044 | Empty list elements in list productions have been deprecated. |
---|
4045 | (<xref target="notation.abnf"/>) |
---|
4046 | </t> |
---|
4047 | <t> |
---|
4048 | Rules about implicit linear whitespace between certain grammar productions |
---|
4049 | have been removed; now it's only allowed when specifically pointed out |
---|
4050 | in the ABNF. The NUL character is no longer allowed in comment and quoted-string |
---|
4051 | text. The quoted-pair rule no longer allows escaping NUL, CR or LF. |
---|
4052 | Non-ASCII content in header fields and reason phrase has been obsoleted and |
---|
4053 | made opaque (the TEXT rule was removed) |
---|
4054 | (<xref target="basic.rules"/>) |
---|
4055 | </t> |
---|
4056 | <t> |
---|
4057 | Clarify that HTTP-Version is case sensitive. |
---|
4058 | (<xref target="http.version"/>) |
---|
4059 | </t> |
---|
4060 | <t> |
---|
4061 | Remove reference to non-existant identity transfer-coding value tokens. |
---|
4062 | (Sections <xref format="counter" target="transfer.codings"/> and |
---|
4063 | <xref format="counter" target="message.length"/>) |
---|
4064 | </t> |
---|
4065 | <t> |
---|
4066 | Clarification that the chunk length does not include |
---|
4067 | the count of the octets in the chunk header and trailer. |
---|
4068 | (<xref target="chunked.transfer.encoding"/>) |
---|
4069 | </t> |
---|
4070 | <t> |
---|
4071 | Require that invalid whitespace around field-names be rejected. |
---|
4072 | (<xref target="message.headers"/>) |
---|
4073 | </t> |
---|
4074 | <t> |
---|
4075 | Update use of abs_path production from RFC1808 to the path-absolute + query |
---|
4076 | components of RFC3986. |
---|
4077 | (<xref target="request-target"/>) |
---|
4078 | </t> |
---|
4079 | <t> |
---|
4080 | Clarify exactly when close connection options must be sent. |
---|
4081 | (<xref target="header.connection"/>) |
---|
4082 | </t> |
---|
4083 | </section> |
---|
4084 | </section> |
---|
4085 | |
---|
4086 | <section title="Terminology" anchor="terminology"> |
---|
4087 | <t> |
---|
4088 | This specification uses a number of terms to refer to the roles |
---|
4089 | played by participants in, and objects of, the HTTP communication. |
---|
4090 | </t> |
---|
4091 | <t> |
---|
4092 | <iref item="cache"/> |
---|
4093 | <?rfc needLines="4"?>cache |
---|
4094 | <list> |
---|
4095 | <t> |
---|
4096 | A program's local store of response messages and the subsystem |
---|
4097 | that controls its message storage, retrieval, and deletion. A |
---|
4098 | cache stores cacheable responses in order to reduce the response |
---|
4099 | time and network bandwidth consumption on future, equivalent |
---|
4100 | requests. Any client or server may include a cache, though a cache |
---|
4101 | cannot be used by a server that is acting as a tunnel. |
---|
4102 | </t> |
---|
4103 | </list> |
---|
4104 | </t> |
---|
4105 | <t> |
---|
4106 | <iref item="cacheable"/> |
---|
4107 | <?rfc needLines="4"?>cacheable |
---|
4108 | <list> |
---|
4109 | <t> |
---|
4110 | A response is cacheable if a cache is allowed to store a copy of |
---|
4111 | the response message for use in answering subsequent requests. The |
---|
4112 | rules for determining the cacheability of HTTP responses are |
---|
4113 | defined in Section 1 of <xref target="Part6"/>. Even if a resource is cacheable, there may |
---|
4114 | be additional constraints on whether a cache can use the cached |
---|
4115 | copy for a particular request. |
---|
4116 | </t> |
---|
4117 | </list> |
---|
4118 | </t> |
---|
4119 | <t> |
---|
4120 | <iref item="client"/> |
---|
4121 | <?rfc needLines="4"?>client |
---|
4122 | <list> |
---|
4123 | <t> |
---|
4124 | A program that establishes connections for the purpose of sending |
---|
4125 | requests. |
---|
4126 | </t> |
---|
4127 | </list> |
---|
4128 | </t> |
---|
4129 | <t> |
---|
4130 | <iref item="connection"/> |
---|
4131 | <?rfc needLines="4"?>connection |
---|
4132 | <list> |
---|
4133 | <t> |
---|
4134 | A transport layer virtual circuit established between two programs |
---|
4135 | for the purpose of communication. |
---|
4136 | </t> |
---|
4137 | </list> |
---|
4138 | </t> |
---|
4139 | <t> |
---|
4140 | <iref item="content negotiation"/> |
---|
4141 | <?rfc needLines="4"?>content negotiation |
---|
4142 | <list> |
---|
4143 | <t> |
---|
4144 | The mechanism for selecting the appropriate representation when |
---|
4145 | servicing a request, as described in Section 4 of <xref target="Part3"/>. The |
---|
4146 | representation of entities in any response can be negotiated |
---|
4147 | (including error responses). |
---|
4148 | </t> |
---|
4149 | </list> |
---|
4150 | </t> |
---|
4151 | <t> |
---|
4152 | <iref item="entity"/> |
---|
4153 | <?rfc needLines="4"?>entity |
---|
4154 | <list> |
---|
4155 | <t> |
---|
4156 | The information transferred as the payload of a request or |
---|
4157 | response. An entity consists of metainformation in the form of |
---|
4158 | entity-header fields and content in the form of an entity-body, as |
---|
4159 | described in Section 3 of <xref target="Part3"/>. |
---|
4160 | </t> |
---|
4161 | </list> |
---|
4162 | </t> |
---|
4163 | <t> |
---|
4164 | <iref item="gateway"/> |
---|
4165 | <?rfc needLines="4"?>gateway |
---|
4166 | <list> |
---|
4167 | <t> |
---|
4168 | A server which acts as an intermediary for some other server. |
---|
4169 | Unlike a proxy, a gateway receives requests as if it were the |
---|
4170 | origin server for the requested resource; the requesting client |
---|
4171 | may not be aware that it is communicating with a gateway. |
---|
4172 | </t> |
---|
4173 | </list> |
---|
4174 | </t> |
---|
4175 | <t> |
---|
4176 | <iref item="inbound"/> |
---|
4177 | <iref item="outbound"/> |
---|
4178 | <?rfc needLines="4"?>inbound/outbound |
---|
4179 | <list> |
---|
4180 | <t> |
---|
4181 | Inbound and outbound refer to the request and response paths for |
---|
4182 | messages: "inbound" means "traveling toward the origin server", |
---|
4183 | and "outbound" means "traveling toward the user agent" |
---|
4184 | </t> |
---|
4185 | </list> |
---|
4186 | </t> |
---|
4187 | <t> |
---|
4188 | <iref item="message"/> |
---|
4189 | <?rfc needLines="4"?>message |
---|
4190 | <list> |
---|
4191 | <t> |
---|
4192 | The basic unit of HTTP communication, consisting of a structured |
---|
4193 | sequence of octets matching the syntax defined in <xref target="http.message"/> and |
---|
4194 | transmitted via the connection. |
---|
4195 | </t> |
---|
4196 | </list> |
---|
4197 | </t> |
---|
4198 | <t> |
---|
4199 | <iref item="origin server"/> |
---|
4200 | <?rfc needLines="4"?>origin server |
---|
4201 | <list> |
---|
4202 | <t> |
---|
4203 | The server on which a given resource resides or is to be created. |
---|
4204 | </t> |
---|
4205 | </list> |
---|
4206 | </t> |
---|
4207 | <t> |
---|
4208 | <iref item="proxy"/> |
---|
4209 | <?rfc needLines="4"?>proxy |
---|
4210 | <list> |
---|
4211 | <t> |
---|
4212 | An intermediary program which acts as both a server and a client |
---|
4213 | for the purpose of making requests on behalf of other clients. |
---|
4214 | Requests are serviced internally or by passing them on, with |
---|
4215 | possible translation, to other servers. A proxy MUST implement |
---|
4216 | both the client and server requirements of this specification. A |
---|
4217 | "transparent proxy" is a proxy that does not modify the request or |
---|
4218 | response beyond what is required for proxy authentication and |
---|
4219 | identification. A "non-transparent proxy" is a proxy that modifies |
---|
4220 | the request or response in order to provide some added service to |
---|
4221 | the user agent, such as group annotation services, media type |
---|
4222 | transformation, protocol reduction, or anonymity filtering. Except |
---|
4223 | where either transparent or non-transparent behavior is explicitly |
---|
4224 | stated, the HTTP proxy requirements apply to both types of |
---|
4225 | proxies. |
---|
4226 | </t> |
---|
4227 | </list> |
---|
4228 | </t> |
---|
4229 | <t> |
---|
4230 | <iref item="request"/> |
---|
4231 | <?rfc needLines="4"?>request |
---|
4232 | <list> |
---|
4233 | <t> |
---|
4234 | An HTTP request message, as defined in <xref target="request"/>. |
---|
4235 | </t> |
---|
4236 | </list> |
---|
4237 | </t> |
---|
4238 | <t> |
---|
4239 | <iref item="resource"/> |
---|
4240 | <?rfc needLines="4"?>resource |
---|
4241 | <list> |
---|
4242 | <t> |
---|
4243 | A network data object or service that can be identified by a URI, |
---|
4244 | as defined in <xref target="uri"/>. Resources may be available in multiple |
---|
4245 | representations (e.g. multiple languages, data formats, size, and |
---|
4246 | resolutions) or vary in other ways. |
---|
4247 | </t> |
---|
4248 | </list> |
---|
4249 | </t> |
---|
4250 | <t> |
---|
4251 | <iref item="response"/> |
---|
4252 | <?rfc needLines="4"?>response |
---|
4253 | <list> |
---|
4254 | <t> |
---|
4255 | An HTTP response message, as defined in <xref target="response"/>. |
---|
4256 | </t> |
---|
4257 | </list> |
---|
4258 | </t> |
---|
4259 | <t> |
---|
4260 | <iref item="representation"/> |
---|
4261 | <?rfc needLines="4"?>representation |
---|
4262 | <list> |
---|
4263 | <t> |
---|
4264 | An entity included with a response that is subject to content |
---|
4265 | negotiation, as described in Section 4 of <xref target="Part3"/>. There may exist multiple |
---|
4266 | representations associated with a particular response status. |
---|
4267 | </t> |
---|
4268 | </list> |
---|
4269 | </t> |
---|
4270 | <t> |
---|
4271 | <iref item="server"/> |
---|
4272 | <?rfc needLines="4"?>server |
---|
4273 | <list> |
---|
4274 | <t> |
---|
4275 | An application program that accepts connections in order to |
---|
4276 | service requests by sending back responses. Any given program may |
---|
4277 | be capable of being both a client and a server; our use of these |
---|
4278 | terms refers only to the role being performed by the program for a |
---|
4279 | particular connection, rather than to the program's capabilities |
---|
4280 | in general. Likewise, any server may act as an origin server, |
---|
4281 | proxy, gateway, or tunnel, switching behavior based on the nature |
---|
4282 | of each request. |
---|
4283 | </t> |
---|
4284 | </list> |
---|
4285 | </t> |
---|
4286 | <t> |
---|
4287 | <iref item="tunnel"/> |
---|
4288 | <?rfc needLines="4"?>tunnel |
---|
4289 | <list> |
---|
4290 | <t> |
---|
4291 | An intermediary program which is acting as a blind relay between |
---|
4292 | two connections. Once active, a tunnel is not considered a party |
---|
4293 | to the HTTP communication, though the tunnel may have been |
---|
4294 | initiated by an HTTP request. The tunnel ceases to exist when both |
---|
4295 | ends of the relayed connections are closed. |
---|
4296 | </t> |
---|
4297 | </list> |
---|
4298 | </t> |
---|
4299 | <t> |
---|
4300 | <iref item="upstream"/> |
---|
4301 | <iref item="downstream"/> |
---|
4302 | <?rfc needLines="4"?>upstream/downstream |
---|
4303 | <list> |
---|
4304 | <t> |
---|
4305 | Upstream and downstream describe the flow of a message: all |
---|
4306 | messages flow from upstream to downstream. |
---|
4307 | </t> |
---|
4308 | </list> |
---|
4309 | </t> |
---|
4310 | <t> |
---|
4311 | <iref item="user agent"/> |
---|
4312 | <?rfc needLines="4"?>user agent |
---|
4313 | <list> |
---|
4314 | <t> |
---|
4315 | The client which initiates a request. These are often browsers, |
---|
4316 | editors, spiders (web-traversing robots), or other end user tools. |
---|
4317 | </t> |
---|
4318 | </list> |
---|
4319 | </t> |
---|
4320 | <t> |
---|
4321 | <iref item="variant"/> |
---|
4322 | <?rfc needLines="4"?>variant |
---|
4323 | <list> |
---|
4324 | <t> |
---|
4325 | A resource may have one, or more than one, representation(s) |
---|
4326 | associated with it at any given instant. Each of these |
---|
4327 | representations is termed a `variant'. Use of the term `variant' |
---|
4328 | does not necessarily imply that the resource is subject to content |
---|
4329 | negotiation. |
---|
4330 | </t> |
---|
4331 | </list> |
---|
4332 | </t> |
---|
4333 | </section> |
---|
4334 | |
---|
4335 | <section title="Collected ABNF" anchor="collected.abnf"> |
---|
4336 | <figure> |
---|
4337 | <artwork type="abnf" name="p1-messaging.parsed-abnf"><![CDATA[ |
---|
4338 | BWS = OWS |
---|
4339 | |
---|
4340 | Cache-Control = <Cache-Control, defined in [Part6], Section 3.4> |
---|
4341 | Chunked-Body = *chunk last-chunk trailer-part CRLF |
---|
4342 | Connection = "Connection:" OWS Connection-v |
---|
4343 | Connection-v = *( "," OWS ) connection-token *( OWS "," [ OWS |
---|
4344 | connection-token ] ) |
---|
4345 | Content-Length = "Content-Length:" OWS 1*Content-Length-v |
---|
4346 | Content-Length-v = 1*DIGIT |
---|
4347 | |
---|
4348 | Date = "Date:" OWS Date-v |
---|
4349 | Date-v = HTTP-date |
---|
4350 | |
---|
4351 | GMT = %x47.4D.54 ; GMT |
---|
4352 | |
---|
4353 | HTTP-Prot-Name = %x48.54.54.50 ; HTTP |
---|
4354 | HTTP-Version = HTTP-Prot-Name "/" 1*DIGIT "." 1*DIGIT |
---|
4355 | HTTP-date = rfc1123-date / obs-date |
---|
4356 | HTTP-message = Request / Response |
---|
4357 | Host = "Host:" OWS Host-v |
---|
4358 | Host-v = uri-host [ ":" port ] |
---|
4359 | |
---|
4360 | Method = token |
---|
4361 | |
---|
4362 | OWS = *( [ obs-fold ] WSP ) |
---|
4363 | |
---|
4364 | Pragma = <Pragma, defined in [Part6], Section 3.4> |
---|
4365 | |
---|
4366 | RWS = 1*( [ obs-fold ] WSP ) |
---|
4367 | Reason-Phrase = *( WSP / VCHAR / obs-text ) |
---|
4368 | Request = Request-Line *( ( general-header / request-header / |
---|
4369 | entity-header ) CRLF ) CRLF [ message-body ] |
---|
4370 | Request-Line = Method SP request-target SP HTTP-Version CRLF |
---|
4371 | Response = Status-Line *( ( general-header / response-header / |
---|
4372 | entity-header ) CRLF ) CRLF [ message-body ] |
---|
4373 | |
---|
4374 | Status-Code = 3DIGIT |
---|
4375 | Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF |
---|
4376 | |
---|
4377 | TE = "TE:" OWS TE-v |
---|
4378 | TE-v = [ ( "," / t-codings ) *( OWS "," [ OWS t-codings ] ) ] |
---|
4379 | Trailer = "Trailer:" OWS Trailer-v |
---|
4380 | Trailer-v = *( "," OWS ) field-name *( OWS "," [ OWS field-name ] ) |
---|
4381 | Transfer-Encoding = "Transfer-Encoding:" OWS Transfer-Encoding-v |
---|
4382 | Transfer-Encoding-v = *( "," OWS ) transfer-coding *( OWS "," [ OWS |
---|
4383 | transfer-coding ] ) |
---|
4384 | |
---|
4385 | URI = <URI, defined in [RFC3986], Section 3> |
---|
4386 | URI-reference = <URI-reference, defined in [RFC3986], Section 4.1> |
---|
4387 | Upgrade = "Upgrade:" OWS Upgrade-v |
---|
4388 | Upgrade-v = *( "," OWS ) product *( OWS "," [ OWS product ] ) |
---|
4389 | |
---|
4390 | Via = "Via:" OWS Via-v |
---|
4391 | Via-v = *( "," OWS ) received-protocol RWS received-by [ RWS comment |
---|
4392 | ] *( OWS "," [ OWS received-protocol RWS received-by [ RWS comment ] |
---|
4393 | ] ) |
---|
4394 | |
---|
4395 | Warning = <Warning, defined in [Part6], Section 3.6> |
---|
4396 | |
---|
4397 | absolute-URI = <absolute-URI, defined in [RFC3986], Section 4.3> |
---|
4398 | asctime-date = day-name SP date3 SP time-of-day SP year |
---|
4399 | attribute = token |
---|
4400 | authority = <authority, defined in [RFC3986], Section 3.2> |
---|
4401 | |
---|
4402 | chunk = chunk-size *WSP [ chunk-ext ] CRLF chunk-data CRLF |
---|
4403 | chunk-data = 1*OCTET |
---|
4404 | chunk-ext = *( ";" *WSP chunk-ext-name [ "=" chunk-ext-val ] *WSP ) |
---|
4405 | chunk-ext-name = token |
---|
4406 | chunk-ext-val = token / quoted-string |
---|
4407 | chunk-size = 1*HEXDIG |
---|
4408 | comment = "(" *( ctext / quoted-pair / comment ) ")" |
---|
4409 | connection-token = token |
---|
4410 | ctext = OWS / %x21-27 ; '!'-''' |
---|
4411 | / %x2A-5B ; '*'-'[' |
---|
4412 | / %x5D-7E ; ']'-'~' |
---|
4413 | / obs-text |
---|
4414 | |
---|
4415 | date1 = day SP month SP year |
---|
4416 | date2 = day "-" month "-" 2DIGIT |
---|
4417 | date3 = month SP ( 2DIGIT / ( SP DIGIT ) ) |
---|
4418 | day = 2DIGIT |
---|
4419 | day-name = %x4D.6F.6E ; Mon |
---|
4420 | / %x54.75.65 ; Tue |
---|
4421 | / %x57.65.64 ; Wed |
---|
4422 | / %x54.68.75 ; Thu |
---|
4423 | / %x46.72.69 ; Fri |
---|
4424 | / %x53.61.74 ; Sat |
---|
4425 | / %x53.75.6E ; Sun |
---|
4426 | day-name-l = %x4D.6F.6E.64.61.79 ; Monday |
---|
4427 | / %x54.75.65.73.64.61.79 ; Tuesday |
---|
4428 | / %x57.65.64.6E.65.73.64.61.79 ; Wednesday |
---|
4429 | / %x54.68.75.72.73.64.61.79 ; Thursday |
---|
4430 | / %x46.72.69.64.61.79 ; Friday |
---|
4431 | / %x53.61.74.75.72.64.61.79 ; Saturday |
---|
4432 | / %x53.75.6E.64.61.79 ; Sunday |
---|
4433 | |
---|
4434 | entity-body = <entity-body, defined in [Part3], Section 3.2> |
---|
4435 | entity-header = <entity-header, defined in [Part3], Section 3.1> |
---|
4436 | |
---|
4437 | field-content = *( WSP / VCHAR / obs-text ) |
---|
4438 | field-name = token |
---|
4439 | field-value = *( field-content / OWS ) |
---|
4440 | fragment = <fragment, defined in [RFC3986], Section 3.5> |
---|
4441 | |
---|
4442 | general-header = Cache-Control / Connection / Date / Pragma / Trailer |
---|
4443 | / Transfer-Encoding / Upgrade / Via / Warning |
---|
4444 | generic-message = start-line *( message-header CRLF ) CRLF [ |
---|
4445 | message-body ] |
---|
4446 | |
---|
4447 | hour = 2DIGIT |
---|
4448 | http-URI = "http://" authority path-abempty [ "?" query ] |
---|
4449 | |
---|
4450 | last-chunk = 1*"0" *WSP [ chunk-ext ] CRLF |
---|
4451 | |
---|
4452 | message-body = entity-body / |
---|
4453 | <entity-body encoded as per Transfer-Encoding> |
---|
4454 | message-header = field-name ":" OWS [ field-value ] OWS |
---|
4455 | minute = 2DIGIT |
---|
4456 | month = %x4A.61.6E ; Jan |
---|
4457 | / %x46.65.62 ; Feb |
---|
4458 | / %x4D.61.72 ; Mar |
---|
4459 | / %x41.70.72 ; Apr |
---|
4460 | / %x4D.61.79 ; May |
---|
4461 | / %x4A.75.6E ; Jun |
---|
4462 | / %x4A.75.6C ; Jul |
---|
4463 | / %x41.75.67 ; Aug |
---|
4464 | / %x53.65.70 ; Sep |
---|
4465 | / %x4F.63.74 ; Oct |
---|
4466 | / %x4E.6F.76 ; Nov |
---|
4467 | / %x44.65.63 ; Dec |
---|
4468 | |
---|
4469 | obs-date = rfc850-date / asctime-date |
---|
4470 | obs-fold = CRLF |
---|
4471 | obs-text = %x80-FF |
---|
4472 | |
---|
4473 | partial-URI = relative-part [ "?" query ] |
---|
4474 | path-abempty = <path-abempty, defined in [RFC3986], Section 3.3> |
---|
4475 | path-absolute = <path-absolute, defined in [RFC3986], Section 3.3> |
---|
4476 | port = <port, defined in [RFC3986], Section 3.2.3> |
---|
4477 | product = token [ "/" product-version ] |
---|
4478 | product-version = token |
---|
4479 | protocol-name = token |
---|
4480 | protocol-version = token |
---|
4481 | pseudonym = token |
---|
4482 | |
---|
4483 | qdtext = OWS / "!" / %x23-5B ; '#'-'[' |
---|
4484 | / %x5D-7E ; ']'-'~' |
---|
4485 | / obs-text |
---|
4486 | query = <query, defined in [RFC3986], Section 3.4> |
---|
4487 | quoted-pair = "\" quoted-text |
---|
4488 | quoted-string = DQUOTE *( qdtext / quoted-pair ) DQUOTE |
---|
4489 | quoted-text = %x01-09 / %x0B-0C / %x0E-FF |
---|
4490 | qvalue = ( "0" [ "." *3DIGIT ] ) / ( "1" [ "." *3"0" ] ) |
---|
4491 | |
---|
4492 | received-by = ( uri-host [ ":" port ] ) / pseudonym |
---|
4493 | received-protocol = [ protocol-name "/" ] protocol-version |
---|
4494 | relative-part = <relative-part, defined in [RFC3986], Section 4.2> |
---|
4495 | request-header = <request-header, defined in [Part2], Section 3> |
---|
4496 | request-target = "*" / absolute-URI / ( path-absolute [ "?" query ] ) |
---|
4497 | / authority |
---|
4498 | response-header = <response-header, defined in [Part2], Section 5> |
---|
4499 | rfc1123-date = day-name "," SP date1 SP time-of-day SP GMT |
---|
4500 | rfc850-date = day-name-l "," SP date2 SP time-of-day SP GMT |
---|
4501 | |
---|
4502 | second = 2DIGIT |
---|
4503 | start-line = Request-Line / Status-Line |
---|
4504 | |
---|
4505 | t-codings = "trailers" / ( transfer-extension [ te-params ] ) |
---|
4506 | tchar = "!" / "#" / "$" / "%" / "&" / "'" / "*" / "+" / "-" / "." / |
---|
4507 | "^" / "_" / "`" / "|" / "~" / DIGIT / ALPHA |
---|
4508 | te-ext = OWS ";" OWS token [ "=" ( token / quoted-string ) ] |
---|
4509 | te-params = OWS ";" OWS "q=" qvalue *te-ext |
---|
4510 | time-of-day = hour ":" minute ":" second |
---|
4511 | token = 1*tchar |
---|
4512 | trailer-part = *( entity-header CRLF ) |
---|
4513 | transfer-coding = "chunked" / transfer-extension |
---|
4514 | transfer-extension = token *( OWS ";" OWS transfer-parameter ) |
---|
4515 | transfer-parameter = attribute BWS "=" BWS value |
---|
4516 | |
---|
4517 | uri-host = <host, defined in [RFC3986], Section 3.2.2> |
---|
4518 | |
---|
4519 | value = token / quoted-string |
---|
4520 | |
---|
4521 | year = 4DIGIT |
---|
4522 | ]]></artwork> |
---|
4523 | </figure> |
---|
4524 | <figure><preamble>ABNF diagnostics:</preamble><artwork type="inline"><![CDATA[ |
---|
4525 | ; Chunked-Body defined but not used |
---|
4526 | ; Content-Length defined but not used |
---|
4527 | ; HTTP-message defined but not used |
---|
4528 | ; Host defined but not used |
---|
4529 | ; TE defined but not used |
---|
4530 | ; URI defined but not used |
---|
4531 | ; URI-reference defined but not used |
---|
4532 | ; fragment defined but not used |
---|
4533 | ; generic-message defined but not used |
---|
4534 | ; http-URI defined but not used |
---|
4535 | ; partial-URI defined but not used |
---|
4536 | ]]></artwork></figure></section> |
---|
4537 | |
---|
4538 | <section title="Change Log (to be removed by RFC Editor before publication)" anchor="change.log"> |
---|
4539 | |
---|
4540 | <section title="Since RFC2616"> |
---|
4541 | <t> |
---|
4542 | Extracted relevant partitions from <xref target="RFC2616"/>. |
---|
4543 | </t> |
---|
4544 | </section> |
---|
4545 | |
---|
4546 | <section title="Since draft-ietf-httpbis-p1-messaging-00"> |
---|
4547 | <t> |
---|
4548 | Closed issues: |
---|
4549 | <list style="symbols"> |
---|
4550 | <t> |
---|
4551 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/1"/>: |
---|
4552 | "HTTP Version should be case sensitive" |
---|
4553 | (<eref target="http://purl.org/NET/http-errata#verscase"/>) |
---|
4554 | </t> |
---|
4555 | <t> |
---|
4556 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/2"/>: |
---|
4557 | "'unsafe' characters" |
---|
4558 | (<eref target="http://purl.org/NET/http-errata#unsafe-uri"/>) |
---|
4559 | </t> |
---|
4560 | <t> |
---|
4561 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/3"/>: |
---|
4562 | "Chunk Size Definition" |
---|
4563 | (<eref target="http://purl.org/NET/http-errata#chunk-size"/>) |
---|
4564 | </t> |
---|
4565 | <t> |
---|
4566 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/4"/>: |
---|
4567 | "Message Length" |
---|
4568 | (<eref target="http://purl.org/NET/http-errata#msg-len-chars"/>) |
---|
4569 | </t> |
---|
4570 | <t> |
---|
4571 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/8"/>: |
---|
4572 | "Media Type Registrations" |
---|
4573 | (<eref target="http://purl.org/NET/http-errata#media-reg"/>) |
---|
4574 | </t> |
---|
4575 | <t> |
---|
4576 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/11"/>: |
---|
4577 | "URI includes query" |
---|
4578 | (<eref target="http://purl.org/NET/http-errata#uriquery"/>) |
---|
4579 | </t> |
---|
4580 | <t> |
---|
4581 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/15"/>: |
---|
4582 | "No close on 1xx responses" |
---|
4583 | (<eref target="http://purl.org/NET/http-errata#noclose1xx"/>) |
---|
4584 | </t> |
---|
4585 | <t> |
---|
4586 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/16"/>: |
---|
4587 | "Remove 'identity' token references" |
---|
4588 | (<eref target="http://purl.org/NET/http-errata#identity"/>) |
---|
4589 | </t> |
---|
4590 | <t> |
---|
4591 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/26"/>: |
---|
4592 | "Import query BNF" |
---|
4593 | </t> |
---|
4594 | <t> |
---|
4595 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/31"/>: |
---|
4596 | "qdtext BNF" |
---|
4597 | </t> |
---|
4598 | <t> |
---|
4599 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/35"/>: |
---|
4600 | "Normative and Informative references" |
---|
4601 | </t> |
---|
4602 | <t> |
---|
4603 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/42"/>: |
---|
4604 | "RFC2606 Compliance" |
---|
4605 | </t> |
---|
4606 | <t> |
---|
4607 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/45"/>: |
---|
4608 | "RFC977 reference" |
---|
4609 | </t> |
---|
4610 | <t> |
---|
4611 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/46"/>: |
---|
4612 | "RFC1700 references" |
---|
4613 | </t> |
---|
4614 | <t> |
---|
4615 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/47"/>: |
---|
4616 | "inconsistency in date format explanation" |
---|
4617 | </t> |
---|
4618 | <t> |
---|
4619 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/48"/>: |
---|
4620 | "Date reference typo" |
---|
4621 | </t> |
---|
4622 | <t> |
---|
4623 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/65"/>: |
---|
4624 | "Informative references" |
---|
4625 | </t> |
---|
4626 | <t> |
---|
4627 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/66"/>: |
---|
4628 | "ISO-8859-1 Reference" |
---|
4629 | </t> |
---|
4630 | <t> |
---|
4631 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/86"/>: |
---|
4632 | "Normative up-to-date references" |
---|
4633 | </t> |
---|
4634 | </list> |
---|
4635 | </t> |
---|
4636 | <t> |
---|
4637 | Other changes: |
---|
4638 | <list style="symbols"> |
---|
4639 | <t> |
---|
4640 | Update media type registrations to use RFC4288 template. |
---|
4641 | </t> |
---|
4642 | <t> |
---|
4643 | Use names of RFC4234 core rules DQUOTE and WSP, |
---|
4644 | fix broken ABNF for chunk-data |
---|
4645 | (work in progress on <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/36"/>) |
---|
4646 | </t> |
---|
4647 | </list> |
---|
4648 | </t> |
---|
4649 | </section> |
---|
4650 | |
---|
4651 | <section title="Since draft-ietf-httpbis-p1-messaging-01"> |
---|
4652 | <t> |
---|
4653 | Closed issues: |
---|
4654 | <list style="symbols"> |
---|
4655 | <t> |
---|
4656 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/19"/>: |
---|
4657 | "Bodies on GET (and other) requests" |
---|
4658 | </t> |
---|
4659 | <t> |
---|
4660 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/55"/>: |
---|
4661 | "Updating to RFC4288" |
---|
4662 | </t> |
---|
4663 | <t> |
---|
4664 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/57"/>: |
---|
4665 | "Status Code and Reason Phrase" |
---|
4666 | </t> |
---|
4667 | <t> |
---|
4668 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/82"/>: |
---|
4669 | "rel_path not used" |
---|
4670 | </t> |
---|
4671 | </list> |
---|
4672 | </t> |
---|
4673 | <t> |
---|
4674 | Ongoing work on ABNF conversion (<eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/36"/>): |
---|
4675 | <list style="symbols"> |
---|
4676 | <t> |
---|
4677 | Get rid of duplicate BNF rule names ("host" -> "uri-host", "trailer" -> |
---|
4678 | "trailer-part"). |
---|
4679 | </t> |
---|
4680 | <t> |
---|
4681 | Avoid underscore character in rule names ("http_URL" -> |
---|
4682 | "http-URL", "abs_path" -> "path-absolute"). |
---|
4683 | </t> |
---|
4684 | <t> |
---|
4685 | Add rules for terms imported from URI spec ("absoluteURI", "authority", |
---|
4686 | "path-absolute", "port", "query", "relativeURI", "host) -- these will |
---|
4687 | have to be updated when switching over to RFC3986. |
---|
4688 | </t> |
---|
4689 | <t> |
---|
4690 | Synchronize core rules with RFC5234. |
---|
4691 | </t> |
---|
4692 | <t> |
---|
4693 | Get rid of prose rules that span multiple lines. |
---|
4694 | </t> |
---|
4695 | <t> |
---|
4696 | Get rid of unused rules LOALPHA and UPALPHA. |
---|
4697 | </t> |
---|
4698 | <t> |
---|
4699 | Move "Product Tokens" section (back) into Part 1, as "token" is used |
---|
4700 | in the definition of the Upgrade header. |
---|
4701 | </t> |
---|
4702 | <t> |
---|
4703 | Add explicit references to BNF syntax and rules imported from other parts of the specification. |
---|
4704 | </t> |
---|
4705 | <t> |
---|
4706 | Rewrite prose rule "token" in terms of "tchar", rewrite prose rule "TEXT". |
---|
4707 | </t> |
---|
4708 | </list> |
---|
4709 | </t> |
---|
4710 | </section> |
---|
4711 | |
---|
4712 | <section title="Since draft-ietf-httpbis-p1-messaging-02" anchor="changes.since.02"> |
---|
4713 | <t> |
---|
4714 | Closed issues: |
---|
4715 | <list style="symbols"> |
---|
4716 | <t> |
---|
4717 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/51"/>: |
---|
4718 | "HTTP-date vs. rfc1123-date" |
---|
4719 | </t> |
---|
4720 | <t> |
---|
4721 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/64"/>: |
---|
4722 | "WS in quoted-pair" |
---|
4723 | </t> |
---|
4724 | </list> |
---|
4725 | </t> |
---|
4726 | <t> |
---|
4727 | Ongoing work on IANA Message Header Registration (<eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/40"/>): |
---|
4728 | <list style="symbols"> |
---|
4729 | <t> |
---|
4730 | Reference RFC 3984, and update header registrations for headers defined |
---|
4731 | in this document. |
---|
4732 | </t> |
---|
4733 | </list> |
---|
4734 | </t> |
---|
4735 | <t> |
---|
4736 | Ongoing work on ABNF conversion (<eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/36"/>): |
---|
4737 | <list style="symbols"> |
---|
4738 | <t> |
---|
4739 | Replace string literals when the string really is case-sensitive (HTTP-Version). |
---|
4740 | </t> |
---|
4741 | </list> |
---|
4742 | </t> |
---|
4743 | </section> |
---|
4744 | |
---|
4745 | <section title="Since draft-ietf-httpbis-p1-messaging-03" anchor="changes.since.03"> |
---|
4746 | <t> |
---|
4747 | Closed issues: |
---|
4748 | <list style="symbols"> |
---|
4749 | <t> |
---|
4750 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/28"/>: |
---|
4751 | "Connection closing" |
---|
4752 | </t> |
---|
4753 | <t> |
---|
4754 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/97"/>: |
---|
4755 | "Move registrations and registry information to IANA Considerations" |
---|
4756 | </t> |
---|
4757 | <t> |
---|
4758 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/120"/>: |
---|
4759 | "need new URL for PAD1995 reference" |
---|
4760 | </t> |
---|
4761 | <t> |
---|
4762 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/127"/>: |
---|
4763 | "IANA Considerations: update HTTP URI scheme registration" |
---|
4764 | </t> |
---|
4765 | <t> |
---|
4766 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/128"/>: |
---|
4767 | "Cite HTTPS URI scheme definition" |
---|
4768 | </t> |
---|
4769 | <t> |
---|
4770 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/129"/>: |
---|
4771 | "List-type headers vs Set-Cookie" |
---|
4772 | </t> |
---|
4773 | </list> |
---|
4774 | </t> |
---|
4775 | <t> |
---|
4776 | Ongoing work on ABNF conversion (<eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/36"/>): |
---|
4777 | <list style="symbols"> |
---|
4778 | <t> |
---|
4779 | Replace string literals when the string really is case-sensitive (HTTP-Date). |
---|
4780 | </t> |
---|
4781 | <t> |
---|
4782 | Replace HEX by HEXDIG for future consistence with RFC 5234's core rules. |
---|
4783 | </t> |
---|
4784 | </list> |
---|
4785 | </t> |
---|
4786 | </section> |
---|
4787 | |
---|
4788 | <section title="Since draft-ietf-httpbis-p1-messaging-04" anchor="changes.since.04"> |
---|
4789 | <t> |
---|
4790 | Closed issues: |
---|
4791 | <list style="symbols"> |
---|
4792 | <t> |
---|
4793 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/34"/>: |
---|
4794 | "Out-of-date reference for URIs" |
---|
4795 | </t> |
---|
4796 | <t> |
---|
4797 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/132"/>: |
---|
4798 | "RFC 2822 is updated by RFC 5322" |
---|
4799 | </t> |
---|
4800 | </list> |
---|
4801 | </t> |
---|
4802 | <t> |
---|
4803 | Ongoing work on ABNF conversion (<eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/36"/>): |
---|
4804 | <list style="symbols"> |
---|
4805 | <t> |
---|
4806 | Use "/" instead of "|" for alternatives. |
---|
4807 | </t> |
---|
4808 | <t> |
---|
4809 | Get rid of RFC822 dependency; use RFC5234 plus extensions instead. |
---|
4810 | </t> |
---|
4811 | <t> |
---|
4812 | Only reference RFC 5234's core rules. |
---|
4813 | </t> |
---|
4814 | <t> |
---|
4815 | Introduce new ABNF rules for "bad" whitespace ("BWS"), optional |
---|
4816 | whitespace ("OWS") and required whitespace ("RWS"). |
---|
4817 | </t> |
---|
4818 | <t> |
---|
4819 | Rewrite ABNFs to spell out whitespace rules, factor out |
---|
4820 | header value format definitions. |
---|
4821 | </t> |
---|
4822 | </list> |
---|
4823 | </t> |
---|
4824 | </section> |
---|
4825 | |
---|
4826 | <section title="Since draft-ietf-httpbis-p1-messaging-05" anchor="changes.since.05"> |
---|
4827 | <t> |
---|
4828 | Closed issues: |
---|
4829 | <list style="symbols"> |
---|
4830 | <t> |
---|
4831 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/30"/>: |
---|
4832 | "Header LWS" |
---|
4833 | </t> |
---|
4834 | <t> |
---|
4835 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/52"/>: |
---|
4836 | "Sort 1.3 Terminology" |
---|
4837 | </t> |
---|
4838 | <t> |
---|
4839 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/63"/>: |
---|
4840 | "RFC2047 encoded words" |
---|
4841 | </t> |
---|
4842 | <t> |
---|
4843 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/74"/>: |
---|
4844 | "Character Encodings in TEXT" |
---|
4845 | </t> |
---|
4846 | <t> |
---|
4847 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/77"/>: |
---|
4848 | "Line Folding" |
---|
4849 | </t> |
---|
4850 | <t> |
---|
4851 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/83"/>: |
---|
4852 | "OPTIONS * and proxies" |
---|
4853 | </t> |
---|
4854 | <t> |
---|
4855 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/94"/>: |
---|
4856 | "Reason-Phrase BNF" |
---|
4857 | </t> |
---|
4858 | <t> |
---|
4859 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/111"/>: |
---|
4860 | "Use of TEXT" |
---|
4861 | </t> |
---|
4862 | <t> |
---|
4863 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/118"/>: |
---|
4864 | "Join "Differences Between HTTP Entities and RFC 2045 Entities"?" |
---|
4865 | </t> |
---|
4866 | <t> |
---|
4867 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/134"/>: |
---|
4868 | "RFC822 reference left in discussion of date formats" |
---|
4869 | </t> |
---|
4870 | </list> |
---|
4871 | </t> |
---|
4872 | <t> |
---|
4873 | Final work on ABNF conversion (<eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/36"/>): |
---|
4874 | <list style="symbols"> |
---|
4875 | <t> |
---|
4876 | Rewrite definition of list rules, deprecate empty list elements. |
---|
4877 | </t> |
---|
4878 | <t> |
---|
4879 | Add appendix containing collected and expanded ABNF. |
---|
4880 | </t> |
---|
4881 | </list> |
---|
4882 | </t> |
---|
4883 | <t> |
---|
4884 | Other changes: |
---|
4885 | <list style="symbols"> |
---|
4886 | <t> |
---|
4887 | Rewrite introduction; add mostly new Architecture Section. |
---|
4888 | </t> |
---|
4889 | <t> |
---|
4890 | Move definition of quality values from Part 3 into Part 1; |
---|
4891 | make TE request header grammar independent of accept-params (defined in Part 3). |
---|
4892 | </t> |
---|
4893 | </list> |
---|
4894 | </t> |
---|
4895 | </section> |
---|
4896 | |
---|
4897 | <section title="Since draft-ietf-httpbis-p1-messaging-06" anchor="changes.since.06"> |
---|
4898 | <t> |
---|
4899 | Closed issues: |
---|
4900 | <list style="symbols"> |
---|
4901 | <t> |
---|
4902 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/161"/>: |
---|
4903 | "base for numeric protocol elements" |
---|
4904 | </t> |
---|
4905 | <t> |
---|
4906 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/162"/>: |
---|
4907 | "comment ABNF" |
---|
4908 | </t> |
---|
4909 | </list> |
---|
4910 | </t> |
---|
4911 | <t> |
---|
4912 | Partly resolved issues: |
---|
4913 | <list style="symbols"> |
---|
4914 | <t> |
---|
4915 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/88"/>: |
---|
4916 | "205 Bodies" (took out language that implied that there may be |
---|
4917 | methods for which a request body MUST NOT be included) |
---|
4918 | </t> |
---|
4919 | <t> |
---|
4920 | <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/163"/>: |
---|
4921 | "editorial improvements around HTTP-date" |
---|
4922 | </t> |
---|
4923 | </list> |
---|
4924 | </t> |
---|
4925 | </section> |
---|
4926 | |
---|
4927 | </section> |
---|
4928 | |
---|
4929 | </back> |
---|
4930 | </rfc> |
---|