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