1 | |
---|
2 | |
---|
3 | |
---|
4 | Network Working Group R. Fielding, Ed. |
---|
5 | Internet-Draft Day Software |
---|
6 | Obsoletes: 2068, 2616 J. Gettys |
---|
7 | (if approved) One Laptop per Child |
---|
8 | Intended status: Standards Track J. Mogul |
---|
9 | Expires: June 22, 2008 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 | December 20, 2007 |
---|
19 | |
---|
20 | |
---|
21 | HTTP/1.1, part 1: URIs, Connections, and Message Parsing |
---|
22 | draft-ietf-httpbis-p1-messaging-00 |
---|
23 | |
---|
24 | Status of this Memo |
---|
25 | |
---|
26 | By submitting this Internet-Draft, each author represents that any |
---|
27 | applicable patent or other IPR claims of which he or she is aware |
---|
28 | have been or will be disclosed, and any of which he or she becomes |
---|
29 | aware will be disclosed, in accordance with Section 6 of BCP 79. |
---|
30 | |
---|
31 | Internet-Drafts are working documents of the Internet Engineering |
---|
32 | Task Force (IETF), its areas, and its working groups. Note that |
---|
33 | other groups may also distribute working documents as Internet- |
---|
34 | Drafts. |
---|
35 | |
---|
36 | Internet-Drafts are draft documents valid for a maximum of six months |
---|
37 | and may be updated, replaced, or obsoleted by other documents at any |
---|
38 | time. It is inappropriate to use Internet-Drafts as reference |
---|
39 | material or to cite them other than as "work in progress." |
---|
40 | |
---|
41 | The list of current Internet-Drafts can be accessed at |
---|
42 | http://www.ietf.org/ietf/1id-abstracts.txt. |
---|
43 | |
---|
44 | The list of Internet-Draft Shadow Directories can be accessed at |
---|
45 | http://www.ietf.org/shadow.html. |
---|
46 | |
---|
47 | This Internet-Draft will expire on June 22, 2008. |
---|
48 | |
---|
49 | Copyright Notice |
---|
50 | |
---|
51 | Copyright (C) The IETF Trust (2007). |
---|
52 | |
---|
53 | |
---|
54 | |
---|
55 | Fielding, et al. Expires June 22, 2008 [Page 1] |
---|
56 | |
---|
57 | Internet-Draft HTTP/1.1 December 2007 |
---|
58 | |
---|
59 | |
---|
60 | Abstract |
---|
61 | |
---|
62 | The Hypertext Transfer Protocol (HTTP) is an application-level |
---|
63 | protocol for distributed, collaborative, hypermedia information |
---|
64 | systems. HTTP has been in use by the World Wide Web global |
---|
65 | information initiative since 1990. This document is Part 1 of the |
---|
66 | seven-part specification that defines the protocol referred to as |
---|
67 | "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 1 provides |
---|
68 | an overview of HTTP and its associated terminology, defines the |
---|
69 | "http" and "https" Uniform Resource Identifier (URI) schemes, defines |
---|
70 | the generic message syntax and parsing requirements for HTTP message |
---|
71 | frames, and describes general security concerns for implementations. |
---|
72 | |
---|
73 | Editorial Note (To be removed by RFC Editor) |
---|
74 | |
---|
75 | This version of the HTTP specification contains only minimal |
---|
76 | editorial changes from [RFC2616] (abstract, introductory paragraph, |
---|
77 | and authors' addresses). All other changes are due to partitioning |
---|
78 | the original into seven mostly independent parts. The intent is for |
---|
79 | readers of future drafts to able to use draft 00 as the basis for |
---|
80 | comparison when the WG makes later changes to the specification text. |
---|
81 | This draft will shortly be followed by draft 01 (containing the first |
---|
82 | round of changes that have already been agreed to on the mailing |
---|
83 | list). There is no point in reviewing this draft other than to |
---|
84 | verify that the partitioning has been done correctly. Roy T. |
---|
85 | Fielding, Yves Lafon, and Julian Reschke will be the editors after |
---|
86 | draft 00 is submitted. |
---|
87 | |
---|
88 | Discussion of this draft should take place on the HTTPBIS working |
---|
89 | group mailing list (ietf-http-wg@w3.org). The current issues list is |
---|
90 | at <http://www3.tools.ietf.org/wg/httpbis/trac/report/11> and related |
---|
91 | documents (including fancy diffs) can be found at |
---|
92 | <http://www3.tools.ietf.org/wg/httpbis/>. |
---|
93 | |
---|
94 | |
---|
95 | |
---|
96 | |
---|
97 | |
---|
98 | |
---|
99 | |
---|
100 | |
---|
101 | |
---|
102 | |
---|
103 | |
---|
104 | |
---|
105 | |
---|
106 | |
---|
107 | |
---|
108 | |
---|
109 | |
---|
110 | |
---|
111 | Fielding, et al. Expires June 22, 2008 [Page 2] |
---|
112 | |
---|
113 | Internet-Draft HTTP/1.1 December 2007 |
---|
114 | |
---|
115 | |
---|
116 | Table of Contents |
---|
117 | |
---|
118 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 |
---|
119 | 1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 5 |
---|
120 | 1.2. Requirements . . . . . . . . . . . . . . . . . . . . . . . 6 |
---|
121 | 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 |
---|
122 | 1.4. Overall Operation . . . . . . . . . . . . . . . . . . . . 9 |
---|
123 | 2. Notational Conventions and Generic Grammar . . . . . . . . . . 11 |
---|
124 | 2.1. Augmented BNF . . . . . . . . . . . . . . . . . . . . . . 11 |
---|
125 | 2.2. Basic Rules . . . . . . . . . . . . . . . . . . . . . . . 13 |
---|
126 | 3. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 15 |
---|
127 | 3.1. HTTP Version . . . . . . . . . . . . . . . . . . . . . . . 15 |
---|
128 | 3.2. Uniform Resource Identifiers . . . . . . . . . . . . . . . 16 |
---|
129 | 3.2.1. General Syntax . . . . . . . . . . . . . . . . . . . . 16 |
---|
130 | 3.2.2. http URL . . . . . . . . . . . . . . . . . . . . . . . 17 |
---|
131 | 3.2.3. URI Comparison . . . . . . . . . . . . . . . . . . . . 17 |
---|
132 | 3.3. Date/Time Formats . . . . . . . . . . . . . . . . . . . . 18 |
---|
133 | 3.3.1. Full Date . . . . . . . . . . . . . . . . . . . . . . 18 |
---|
134 | 3.4. Transfer Codings . . . . . . . . . . . . . . . . . . . . . 19 |
---|
135 | 3.4.1. Chunked Transfer Coding . . . . . . . . . . . . . . . 20 |
---|
136 | 4. HTTP Message . . . . . . . . . . . . . . . . . . . . . . . . . 22 |
---|
137 | 4.1. Message Types . . . . . . . . . . . . . . . . . . . . . . 22 |
---|
138 | 4.2. Message Headers . . . . . . . . . . . . . . . . . . . . . 23 |
---|
139 | 4.3. Message Body . . . . . . . . . . . . . . . . . . . . . . . 24 |
---|
140 | 4.4. Message Length . . . . . . . . . . . . . . . . . . . . . . 25 |
---|
141 | 4.5. General Header Fields . . . . . . . . . . . . . . . . . . 26 |
---|
142 | 5. Request . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 |
---|
143 | 5.1. Request-Line . . . . . . . . . . . . . . . . . . . . . . . 27 |
---|
144 | 5.1.1. Method . . . . . . . . . . . . . . . . . . . . . . . . 27 |
---|
145 | 5.1.2. Request-URI . . . . . . . . . . . . . . . . . . . . . 27 |
---|
146 | 5.2. The Resource Identified by a Request . . . . . . . . . . . 28 |
---|
147 | 6. Response . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 |
---|
148 | 6.1. Status-Line . . . . . . . . . . . . . . . . . . . . . . . 29 |
---|
149 | 6.1.1. Status Code and Reason Phrase . . . . . . . . . . . . 30 |
---|
150 | 7. Connections . . . . . . . . . . . . . . . . . . . . . . . . . 30 |
---|
151 | 7.1. Persistent Connections . . . . . . . . . . . . . . . . . . 30 |
---|
152 | 7.1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . 30 |
---|
153 | 7.1.2. Overall Operation . . . . . . . . . . . . . . . . . . 31 |
---|
154 | 7.1.3. Proxy Servers . . . . . . . . . . . . . . . . . . . . 33 |
---|
155 | 7.1.4. Practical Considerations . . . . . . . . . . . . . . . 33 |
---|
156 | 7.2. Message Transmission Requirements . . . . . . . . . . . . 34 |
---|
157 | 7.2.1. Persistent Connections and Flow Control . . . . . . . 34 |
---|
158 | 7.2.2. Monitoring Connections for Error Status Messages . . . 34 |
---|
159 | 7.2.3. Use of the 100 (Continue) Status . . . . . . . . . . . 34 |
---|
160 | 7.2.4. Client Behavior if Server Prematurely Closes |
---|
161 | Connection . . . . . . . . . . . . . . . . . . . . . . 36 |
---|
162 | 8. Header Field Definitions . . . . . . . . . . . . . . . . . . . 37 |
---|
163 | 8.1. Connection . . . . . . . . . . . . . . . . . . . . . . . . 37 |
---|
164 | |
---|
165 | |
---|
166 | |
---|
167 | Fielding, et al. Expires June 22, 2008 [Page 3] |
---|
168 | |
---|
169 | Internet-Draft HTTP/1.1 December 2007 |
---|
170 | |
---|
171 | |
---|
172 | 8.2. Content-Length . . . . . . . . . . . . . . . . . . . . . . 38 |
---|
173 | 8.3. Date . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 |
---|
174 | 8.3.1. Clockless Origin Server Operation . . . . . . . . . . 40 |
---|
175 | 8.4. Host . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 |
---|
176 | 8.5. TE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 |
---|
177 | 8.6. Trailer . . . . . . . . . . . . . . . . . . . . . . . . . 42 |
---|
178 | 8.7. Transfer-Encoding . . . . . . . . . . . . . . . . . . . . 43 |
---|
179 | 8.8. Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . 43 |
---|
180 | 8.9. Via . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 |
---|
181 | 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 46 |
---|
182 | 10. Security Considerations . . . . . . . . . . . . . . . . . . . 46 |
---|
183 | 10.1. Personal Information . . . . . . . . . . . . . . . . . . . 46 |
---|
184 | 10.2. Abuse of Server Log Information . . . . . . . . . . . . . 46 |
---|
185 | 10.3. Attacks Based On File and Path Names . . . . . . . . . . . 46 |
---|
186 | 10.4. DNS Spoofing . . . . . . . . . . . . . . . . . . . . . . . 47 |
---|
187 | 10.5. Proxies and Caching . . . . . . . . . . . . . . . . . . . 47 |
---|
188 | 10.6. Denial of Service Attacks on Proxies . . . . . . . . . . . 48 |
---|
189 | 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 48 |
---|
190 | 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 50 |
---|
191 | Appendix A. Internet Media Type message/http and |
---|
192 | application/http . . . . . . . . . . . . . . . . . . 53 |
---|
193 | Appendix B. Tolerant Applications . . . . . . . . . . . . . . . . 54 |
---|
194 | Appendix C. Conversion of Date Formats . . . . . . . . . . . . . 55 |
---|
195 | Appendix D. Compatibility with Previous Versions . . . . . . . . 55 |
---|
196 | D.1. Changes from HTTP/1.0 . . . . . . . . . . . . . . . . . . 56 |
---|
197 | D.1.1. Changes to Simplify Multi-homed Web Servers and |
---|
198 | Conserve IP Addresses . . . . . . . . . . . . . . . . 56 |
---|
199 | D.2. Compatibility with HTTP/1.0 Persistent Connections . . . . 56 |
---|
200 | D.3. Changes from RFC 2068 . . . . . . . . . . . . . . . . . . 57 |
---|
201 | Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 |
---|
202 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 61 |
---|
203 | Intellectual Property and Copyright Statements . . . . . . . . . . 63 |
---|
204 | |
---|
205 | |
---|
206 | |
---|
207 | |
---|
208 | |
---|
209 | |
---|
210 | |
---|
211 | |
---|
212 | |
---|
213 | |
---|
214 | |
---|
215 | |
---|
216 | |
---|
217 | |
---|
218 | |
---|
219 | |
---|
220 | |
---|
221 | |
---|
222 | |
---|
223 | Fielding, et al. Expires June 22, 2008 [Page 4] |
---|
224 | |
---|
225 | Internet-Draft HTTP/1.1 December 2007 |
---|
226 | |
---|
227 | |
---|
228 | 1. Introduction |
---|
229 | |
---|
230 | This document will define aspects of HTTP related to overall network |
---|
231 | operation, message framing, interaction with transport protocols, and |
---|
232 | URI schemes. Right now it only includes the extracted relevant |
---|
233 | sections of [RFC2616]. |
---|
234 | |
---|
235 | 1.1. Purpose |
---|
236 | |
---|
237 | The Hypertext Transfer Protocol (HTTP) is an application-level |
---|
238 | protocol for distributed, collaborative, hypermedia information |
---|
239 | systems. HTTP has been in use by the World-Wide Web global |
---|
240 | information initiative since 1990. The first version of HTTP, |
---|
241 | referred to as HTTP/0.9, was a simple protocol for raw data transfer |
---|
242 | across the Internet. HTTP/1.0, as defined by RFC 1945 [RFC1945], |
---|
243 | improved the protocol by allowing messages to be in the format of |
---|
244 | MIME-like messages, containing metainformation about the data |
---|
245 | transferred and modifiers on the request/response semantics. |
---|
246 | However, HTTP/1.0 does not sufficiently take into consideration the |
---|
247 | effects of hierarchical proxies, caching, the need for persistent |
---|
248 | connections, or virtual hosts. In addition, the proliferation of |
---|
249 | incompletely-implemented applications calling themselves "HTTP/1.0" |
---|
250 | has necessitated a protocol version change in order for two |
---|
251 | communicating applications to determine each other's true |
---|
252 | capabilities. |
---|
253 | |
---|
254 | This specification defines the protocol referred to as "HTTP/1.1". |
---|
255 | This protocol includes more stringent requirements than HTTP/1.0 in |
---|
256 | order to ensure reliable implementation of its features. |
---|
257 | |
---|
258 | Practical information systems require more functionality than simple |
---|
259 | retrieval, including search, front-end update, and annotation. HTTP |
---|
260 | allows an open-ended set of methods and headers that indicate the |
---|
261 | purpose of a request [RFC2324]. It builds on the discipline of |
---|
262 | reference provided by the Uniform Resource Identifier (URI) |
---|
263 | [RFC1630], as a location (URL) [RFC1738] or name (URN) [RFC1737], for |
---|
264 | indicating the resource to which a method is to be applied. Messages |
---|
265 | are passed in a format similar to that used by Internet mail [RFC822] |
---|
266 | as defined by the Multipurpose Internet Mail Extensions (MIME) |
---|
267 | [RFC2045]. |
---|
268 | |
---|
269 | HTTP is also used as a generic protocol for communication between |
---|
270 | user agents and proxies/gateways to other Internet systems, including |
---|
271 | those supported by the SMTP [RFC821], NNTP [RFC977], FTP [RFC959], |
---|
272 | Gopher [RFC1436], and WAIS [WAIS] protocols. In this way, HTTP |
---|
273 | allows basic hypermedia access to resources available from diverse |
---|
274 | applications. |
---|
275 | |
---|
276 | |
---|
277 | |
---|
278 | |
---|
279 | Fielding, et al. Expires June 22, 2008 [Page 5] |
---|
280 | |
---|
281 | Internet-Draft HTTP/1.1 December 2007 |
---|
282 | |
---|
283 | |
---|
284 | 1.2. Requirements |
---|
285 | |
---|
286 | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", |
---|
287 | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this |
---|
288 | document are to be interpreted as described in RFC 2119 [RFC2119]. |
---|
289 | |
---|
290 | An implementation is not compliant if it fails to satisfy one or more |
---|
291 | of the MUST or REQUIRED level requirements for the protocols it |
---|
292 | implements. An implementation that satisfies all the MUST or |
---|
293 | REQUIRED level and all the SHOULD level requirements for its |
---|
294 | protocols is said to be "unconditionally compliant"; one that |
---|
295 | satisfies all the MUST level requirements but not all the SHOULD |
---|
296 | level requirements for its protocols is said to be "conditionally |
---|
297 | compliant." |
---|
298 | |
---|
299 | 1.3. Terminology |
---|
300 | |
---|
301 | This specification uses a number of terms to refer to the roles |
---|
302 | played by participants in, and objects of, the HTTP communication. |
---|
303 | |
---|
304 | connection |
---|
305 | |
---|
306 | A transport layer virtual circuit established between two programs |
---|
307 | for the purpose of communication. |
---|
308 | |
---|
309 | message |
---|
310 | |
---|
311 | The basic unit of HTTP communication, consisting of a structured |
---|
312 | sequence of octets matching the syntax defined in Section 4 and |
---|
313 | transmitted via the connection. |
---|
314 | |
---|
315 | request |
---|
316 | |
---|
317 | An HTTP request message, as defined in Section 5. |
---|
318 | |
---|
319 | response |
---|
320 | |
---|
321 | An HTTP response message, as defined in Section 6. |
---|
322 | |
---|
323 | resource |
---|
324 | |
---|
325 | A network data object or service that can be identified by a URI, |
---|
326 | as defined in Section 3.2. Resources may be available in multiple |
---|
327 | representations (e.g. multiple languages, data formats, size, and |
---|
328 | resolutions) or vary in other ways. |
---|
329 | |
---|
330 | entity |
---|
331 | |
---|
332 | |
---|
333 | |
---|
334 | |
---|
335 | Fielding, et al. Expires June 22, 2008 [Page 6] |
---|
336 | |
---|
337 | Internet-Draft HTTP/1.1 December 2007 |
---|
338 | |
---|
339 | |
---|
340 | The information transferred as the payload of a request or |
---|
341 | response. An entity consists of metainformation in the form of |
---|
342 | entity-header fields and content in the form of an entity-body, as |
---|
343 | described in Section 3 of [Part3]. |
---|
344 | |
---|
345 | representation |
---|
346 | |
---|
347 | An entity included with a response that is subject to content |
---|
348 | negotiation, as described in Section 4 of [Part3]. There may |
---|
349 | exist multiple representations associated with a particular |
---|
350 | response status. |
---|
351 | |
---|
352 | content negotiation |
---|
353 | |
---|
354 | The mechanism for selecting the appropriate representation when |
---|
355 | servicing a request, as described in Section 4 of [Part3]. The |
---|
356 | representation of entities in any response can be negotiated |
---|
357 | (including error responses). |
---|
358 | |
---|
359 | variant |
---|
360 | |
---|
361 | A resource may have one, or more than one, representation(s) |
---|
362 | associated with it at any given instant. Each of these |
---|
363 | representations is termed a `varriant'. Use of the term `variant' |
---|
364 | does not necessarily imply that the resource is subject to content |
---|
365 | negotiation. |
---|
366 | |
---|
367 | client |
---|
368 | |
---|
369 | A program that establishes connections for the purpose of sending |
---|
370 | requests. |
---|
371 | |
---|
372 | user agent |
---|
373 | |
---|
374 | The client which initiates a request. These are often browsers, |
---|
375 | editors, spiders (web-traversing robots), or other end user tools. |
---|
376 | |
---|
377 | server |
---|
378 | |
---|
379 | An application program that accepts connections in order to |
---|
380 | service requests by sending back responses. Any given program may |
---|
381 | be capable of being both a client and a server; our use of these |
---|
382 | terms refers only to the role being performed by the program for a |
---|
383 | particular connection, rather than to the program's capabilities |
---|
384 | in general. Likewise, any server may act as an origin server, |
---|
385 | proxy, gateway, or tunnel, switching behavior based on the nature |
---|
386 | of each request. |
---|
387 | |
---|
388 | |
---|
389 | |
---|
390 | |
---|
391 | Fielding, et al. Expires June 22, 2008 [Page 7] |
---|
392 | |
---|
393 | Internet-Draft HTTP/1.1 December 2007 |
---|
394 | |
---|
395 | |
---|
396 | origin server |
---|
397 | |
---|
398 | The server on which a given resource resides or is to be created. |
---|
399 | |
---|
400 | proxy |
---|
401 | |
---|
402 | An intermediary program which acts as both a server and a client |
---|
403 | for the purpose of making requests on behalf of other clients. |
---|
404 | Requests are serviced internally or by passing them on, with |
---|
405 | possible translation, to other servers. A proxy MUST implement |
---|
406 | both the client and server requirements of this specification. A |
---|
407 | "transparent proxy" is a proxy that does not modify the request or |
---|
408 | response beyond what is required for proxy authentication and |
---|
409 | identification. A "non-transparent proxy" is a proxy that |
---|
410 | modifies the request or response in order to provide some added |
---|
411 | service to the user agent, such as group annotation services, |
---|
412 | media type transformation, protocol reduction, or anonymity |
---|
413 | filtering. Except where either transparent or non-transparent |
---|
414 | behavior is explicitly stated, the HTTP proxy requirements apply |
---|
415 | to both types of proxies. |
---|
416 | |
---|
417 | gateway |
---|
418 | |
---|
419 | A server which acts as an intermediary for some other server. |
---|
420 | Unlike a proxy, a gateway receives requests as if it were the |
---|
421 | origin server for the requested resource; the requesting client |
---|
422 | may not be aware that it is communicating with a gateway. |
---|
423 | |
---|
424 | tunnel |
---|
425 | |
---|
426 | An intermediary program which is acting as a blind relay between |
---|
427 | two connections. Once active, a tunnel is not considered a party |
---|
428 | to the HTTP communication, though the tunnel may have been |
---|
429 | initiated by an HTTP request. The tunnel ceases to exist when |
---|
430 | both ends of the relayed connections are closed. |
---|
431 | |
---|
432 | cache |
---|
433 | |
---|
434 | A program's local store of response messages and the subsystem |
---|
435 | that controls its message storage, retrieval, and deletion. A |
---|
436 | cache stores cacheable responses in order to reduce the response |
---|
437 | time and network bandwidth consumption on future, equivalent |
---|
438 | requests. Any client or server may include a cache, though a |
---|
439 | cache cannot be used by a server that is acting as a tunnel. |
---|
440 | |
---|
441 | cacheable |
---|
442 | |
---|
443 | |
---|
444 | |
---|
445 | |
---|
446 | |
---|
447 | Fielding, et al. Expires June 22, 2008 [Page 8] |
---|
448 | |
---|
449 | Internet-Draft HTTP/1.1 December 2007 |
---|
450 | |
---|
451 | |
---|
452 | A response is cacheable if a cache is allowed to store a copy of |
---|
453 | the response message for use in answering subsequent requests. |
---|
454 | The rules for determining the cacheability of HTTP responses are |
---|
455 | defined in Section 2 of [Part6]. Even if a resource is cacheable, |
---|
456 | there may be additional constraints on whether a cache can use the |
---|
457 | cached copy for a particular request. |
---|
458 | |
---|
459 | upstream/downstream |
---|
460 | |
---|
461 | Upstream and downstream describe the flow of a message: all |
---|
462 | messages flow from upstream to downstream. |
---|
463 | |
---|
464 | inbound/outbound |
---|
465 | |
---|
466 | Inbound and outbound refer to the request and response paths for |
---|
467 | messages: "inbound" means "traveling toward the origin server", |
---|
468 | and "outbound" means "traveling toward the user agent" |
---|
469 | |
---|
470 | 1.4. Overall Operation |
---|
471 | |
---|
472 | The HTTP protocol is a request/response protocol. A client sends a |
---|
473 | request to the server in the form of a request method, URI, and |
---|
474 | protocol version, followed by a MIME-like message containing request |
---|
475 | modifiers, client information, and possible body content over a |
---|
476 | connection with a server. The server responds with a status line, |
---|
477 | including the message's protocol version and a success or error code, |
---|
478 | followed by a MIME-like message containing server information, entity |
---|
479 | metainformation, and possible entity-body content. The relationship |
---|
480 | between HTTP and MIME is described in Appendix A of [Part3]. |
---|
481 | |
---|
482 | Most HTTP communication is initiated by a user agent and consists of |
---|
483 | a request to be applied to a resource on some origin server. In the |
---|
484 | simplest case, this may be accomplished via a single connection (v) |
---|
485 | between the user agent (UA) and the origin server (O). |
---|
486 | |
---|
487 | request chain ------------------------> |
---|
488 | UA -------------------v------------------- O |
---|
489 | <----------------------- response chain |
---|
490 | |
---|
491 | A more complicated situation occurs when one or more intermediaries |
---|
492 | are present in the request/response chain. There are three common |
---|
493 | forms of intermediary: proxy, gateway, and tunnel. A proxy is a |
---|
494 | forwarding agent, receiving requests for a URI in its absolute form, |
---|
495 | rewriting all or part of the message, and forwarding the reformatted |
---|
496 | request toward the server identified by the URI. A gateway is a |
---|
497 | receiving agent, acting as a layer above some other server(s) and, if |
---|
498 | necessary, translating the requests to the underlying server's |
---|
499 | protocol. A tunnel acts as a relay point between two connections |
---|
500 | |
---|
501 | |
---|
502 | |
---|
503 | Fielding, et al. Expires June 22, 2008 [Page 9] |
---|
504 | |
---|
505 | Internet-Draft HTTP/1.1 December 2007 |
---|
506 | |
---|
507 | |
---|
508 | without changing the messages; tunnels are used when the |
---|
509 | communication needs to pass through an intermediary (such as a |
---|
510 | firewall) even when the intermediary cannot understand the contents |
---|
511 | of the messages. |
---|
512 | |
---|
513 | request chain --------------------------------------> |
---|
514 | UA -----v----- A -----v----- B -----v----- C -----v----- O |
---|
515 | <------------------------------------- response chain |
---|
516 | |
---|
517 | The figure above shows three intermediaries (A, B, and C) between the |
---|
518 | user agent and origin server. A request or response message that |
---|
519 | travels the whole chain will pass through four separate connections. |
---|
520 | This distinction is important because some HTTP communication options |
---|
521 | may apply only to the connection with the nearest, non-tunnel |
---|
522 | neighbor, only to the end-points of the chain, or to all connections |
---|
523 | along the chain. Although the diagram is linear, each participant |
---|
524 | may be engaged in multiple, simultaneous communications. For |
---|
525 | example, B may be receiving requests from many clients other than A, |
---|
526 | and/or forwarding requests to servers other than C, at the same time |
---|
527 | that it is handling A's request. |
---|
528 | |
---|
529 | Any party to the communication which is not acting as a tunnel may |
---|
530 | employ an internal cache for handling requests. The effect of a |
---|
531 | cache is that the request/response chain is shortened if one of the |
---|
532 | participants along the chain has a cached response applicable to that |
---|
533 | request. The following illustrates the resulting chain if B has a |
---|
534 | cached copy of an earlier response from O (via C) for a request which |
---|
535 | has not been cached by UA or A. |
---|
536 | |
---|
537 | request chain ----------> |
---|
538 | UA -----v----- A -----v----- B - - - - - - C - - - - - - O |
---|
539 | <--------- response chain |
---|
540 | |
---|
541 | Not all responses are usefully cacheable, and some requests may |
---|
542 | contain modifiers which place special requirements on cache behavior. |
---|
543 | HTTP requirements for cache behavior and cacheable responses are |
---|
544 | defined in Section 2 of [Part6]. |
---|
545 | |
---|
546 | In fact, there are a wide variety of architectures and configurations |
---|
547 | of caches and proxies currently being experimented with or deployed |
---|
548 | across the World Wide Web. These systems include national hierarchies |
---|
549 | of proxy caches to save transoceanic bandwidth, systems that |
---|
550 | broadcast or multicast cache entries, organizations that distribute |
---|
551 | subsets of cached data via CD-ROM, and so on. HTTP systems are used |
---|
552 | in corporate intranets over high-bandwidth links, and for access via |
---|
553 | PDAs with low-power radio links and intermittent connectivity. The |
---|
554 | goal of HTTP/1.1 is to support the wide diversity of configurations |
---|
555 | already deployed while introducing protocol constructs that meet the |
---|
556 | |
---|
557 | |
---|
558 | |
---|
559 | Fielding, et al. Expires June 22, 2008 [Page 10] |
---|
560 | |
---|
561 | Internet-Draft HTTP/1.1 December 2007 |
---|
562 | |
---|
563 | |
---|
564 | needs of those who build web applications that require high |
---|
565 | reliability and, failing that, at least reliable indications of |
---|
566 | failure. |
---|
567 | |
---|
568 | HTTP communication usually takes place over TCP/IP connections. The |
---|
569 | default port is TCP 80 [RFC1700], but other ports can be used. This |
---|
570 | does not preclude HTTP from being implemented on top of any other |
---|
571 | protocol on the Internet, or on other networks. HTTP only presumes a |
---|
572 | reliable transport; any protocol that provides such guarantees can be |
---|
573 | used; the mapping of the HTTP/1.1 request and response structures |
---|
574 | onto the transport data units of the protocol in question is outside |
---|
575 | the scope of this specification. |
---|
576 | |
---|
577 | In HTTP/1.0, most implementations used a new connection for each |
---|
578 | request/response exchange. In HTTP/1.1, a connection may be used for |
---|
579 | one or more request/response exchanges, although connections may be |
---|
580 | closed for a variety of reasons (see Section 7.1). |
---|
581 | |
---|
582 | |
---|
583 | 2. Notational Conventions and Generic Grammar |
---|
584 | |
---|
585 | 2.1. Augmented BNF |
---|
586 | |
---|
587 | All of the mechanisms specified in this document are described in |
---|
588 | both prose and an augmented Backus-Naur Form (BNF) similar to that |
---|
589 | used by RFC 822 [RFC822]. Implementors will need to be familiar with |
---|
590 | the notation in order to understand this specification. The |
---|
591 | augmented BNF includes the following constructs: |
---|
592 | |
---|
593 | name = definition |
---|
594 | |
---|
595 | The name of a rule is simply the name itself (without any |
---|
596 | enclosing "<" and ">") and is separated from its definition by the |
---|
597 | equal "=" character. White space is only significant in that |
---|
598 | indentation of continuation lines is used to indicate a rule |
---|
599 | definition that spans more than one line. Certain basic rules are |
---|
600 | in uppercase, such as SP, LWS, HT, CRLF, DIGIT, ALPHA, etc. Angle |
---|
601 | brackets are used within definitions whenever their presence will |
---|
602 | facilitate discerning the use of rule names. |
---|
603 | |
---|
604 | "literal" |
---|
605 | |
---|
606 | Quotation marks surround literal text. Unless stated otherwise, |
---|
607 | the text is case-insensitive. |
---|
608 | |
---|
609 | rule1 | rule2 |
---|
610 | |
---|
611 | |
---|
612 | |
---|
613 | |
---|
614 | |
---|
615 | Fielding, et al. Expires June 22, 2008 [Page 11] |
---|
616 | |
---|
617 | Internet-Draft HTTP/1.1 December 2007 |
---|
618 | |
---|
619 | |
---|
620 | Elements separated by a bar ("|") are alternatives, e.g., "yes | |
---|
621 | no" will accept yes or no. |
---|
622 | |
---|
623 | (rule1 rule2) |
---|
624 | |
---|
625 | Elements enclosed in parentheses are treated as a single element. |
---|
626 | Thus, "(elem (foo | bar) elem)" allows the token sequences "elem |
---|
627 | foo elem" and "elem bar elem". |
---|
628 | |
---|
629 | *rule |
---|
630 | |
---|
631 | The character "*" preceding an element indicates repetition. The |
---|
632 | full form is "<n>*<m>element" indicating at least <n> and at most |
---|
633 | <m> occurrences of element. Default values are 0 and infinity so |
---|
634 | that "*(element)" allows any number, including zero; "1*element" |
---|
635 | requires at least one; and "1*2element" allows one or two. |
---|
636 | |
---|
637 | [rule] |
---|
638 | |
---|
639 | Square brackets enclose optional elements; "[foo bar]" is |
---|
640 | equivalent to "*1(foo bar)". |
---|
641 | |
---|
642 | N rule |
---|
643 | |
---|
644 | Specific repetition: "<n>(element)" is equivalent to |
---|
645 | "<n>*<n>(element)"; that is, exactly <n> occurrences of (element). |
---|
646 | Thus 2DIGIT is a 2-digit number, and 3ALPHA is a string of three |
---|
647 | alphabetic characters. |
---|
648 | |
---|
649 | #rule |
---|
650 | |
---|
651 | A construct "#" is defined, similar to "*", for defining lists of |
---|
652 | elements. The full form is "<n>#<m>element" indicating at least |
---|
653 | <n> and at most <m> elements, each separated by one or more commas |
---|
654 | (",") and OPTIONAL linear white space (LWS). This makes the usual |
---|
655 | form of lists very easy; a rule such as |
---|
656 | |
---|
657 | ( *LWS element *( *LWS "," *LWS element )) |
---|
658 | |
---|
659 | can be shown as |
---|
660 | |
---|
661 | 1#element |
---|
662 | |
---|
663 | Wherever this construct is used, null elements are allowed, but do |
---|
664 | not contribute to the count of elements present. That is, |
---|
665 | "(element), , (element) " is permitted, but counts as only two |
---|
666 | elements. Therefore, where at least one element is required, at |
---|
667 | least one non-null element MUST be present. Default values are 0 |
---|
668 | |
---|
669 | |
---|
670 | |
---|
671 | Fielding, et al. Expires June 22, 2008 [Page 12] |
---|
672 | |
---|
673 | Internet-Draft HTTP/1.1 December 2007 |
---|
674 | |
---|
675 | |
---|
676 | and infinity so that "#element" allows any number, including zero; |
---|
677 | "1#element" requires at least one; and "1#2element" allows one or |
---|
678 | two. |
---|
679 | |
---|
680 | ; comment |
---|
681 | |
---|
682 | A semi-colon, set off some distance to the right of rule text, |
---|
683 | starts a comment that continues to the end of line. This is a |
---|
684 | simple way of including useful notes in parallel with the |
---|
685 | specifications. |
---|
686 | |
---|
687 | implied *LWS |
---|
688 | |
---|
689 | The grammar described by this specification is word-based. Except |
---|
690 | where noted otherwise, linear white space (LWS) can be included |
---|
691 | between any two adjacent words (token or quoted-string), and |
---|
692 | between adjacent words and separators, without changing the |
---|
693 | interpretation of a field. At least one delimiter (LWS and/or |
---|
694 | separators) MUST exist between any two tokens (for the definition |
---|
695 | of "token" below), since they would otherwise be interpreted as a |
---|
696 | single token. |
---|
697 | |
---|
698 | 2.2. Basic Rules |
---|
699 | |
---|
700 | The following rules are used throughout this specification to |
---|
701 | describe basic parsing constructs. The US-ASCII coded character set |
---|
702 | is defined by ANSI X3.4-1986 [USASCII]. |
---|
703 | |
---|
704 | OCTET = <any 8-bit sequence of data> |
---|
705 | CHAR = <any US-ASCII character (octets 0 - 127)> |
---|
706 | UPALPHA = <any US-ASCII uppercase letter "A".."Z"> |
---|
707 | LOALPHA = <any US-ASCII lowercase letter "a".."z"> |
---|
708 | ALPHA = UPALPHA | LOALPHA |
---|
709 | DIGIT = <any US-ASCII digit "0".."9"> |
---|
710 | CTL = <any US-ASCII control character |
---|
711 | (octets 0 - 31) and DEL (127)> |
---|
712 | CR = <US-ASCII CR, carriage return (13)> |
---|
713 | LF = <US-ASCII LF, linefeed (10)> |
---|
714 | SP = <US-ASCII SP, space (32)> |
---|
715 | HT = <US-ASCII HT, horizontal-tab (9)> |
---|
716 | <"> = <US-ASCII double-quote mark (34)> |
---|
717 | |
---|
718 | HTTP/1.1 defines the sequence CR LF as the end-of-line marker for all |
---|
719 | protocol elements except the entity-body (see Appendix B for tolerant |
---|
720 | applications). The end-of-line marker within an entity-body is |
---|
721 | defined by its associated media type, as described in [Part3]. |
---|
722 | |
---|
723 | CRLF = CR LF |
---|
724 | |
---|
725 | |
---|
726 | |
---|
727 | Fielding, et al. Expires June 22, 2008 [Page 13] |
---|
728 | |
---|
729 | Internet-Draft HTTP/1.1 December 2007 |
---|
730 | |
---|
731 | |
---|
732 | HTTP/1.1 header field values can be folded onto multiple lines if the |
---|
733 | continuation line begins with a space or horizontal tab. All linear |
---|
734 | white space, including folding, has the same semantics as SP. A |
---|
735 | recipient MAY replace any linear white space with a single SP before |
---|
736 | interpreting the field value or forwarding the message downstream. |
---|
737 | |
---|
738 | LWS = [CRLF] 1*( SP | HT ) |
---|
739 | |
---|
740 | The TEXT rule is only used for descriptive field contents and values |
---|
741 | that are not intended to be interpreted by the message parser. Words |
---|
742 | of *TEXT MAY contain characters from character sets other than ISO- |
---|
743 | 8859-1 [ISO-8859] only when encoded according to the rules of RFC |
---|
744 | 2047 [RFC2047]. |
---|
745 | |
---|
746 | TEXT = <any OCTET except CTLs, |
---|
747 | but including LWS> |
---|
748 | |
---|
749 | A CRLF is allowed in the definition of TEXT only as part of a header |
---|
750 | field continuation. It is expected that the folding LWS will be |
---|
751 | replaced with a single SP before interpretation of the TEXT value. |
---|
752 | |
---|
753 | Hexadecimal numeric characters are used in several protocol elements. |
---|
754 | |
---|
755 | HEX = "A" | "B" | "C" | "D" | "E" | "F" |
---|
756 | | "a" | "b" | "c" | "d" | "e" | "f" | DIGIT |
---|
757 | |
---|
758 | Many HTTP/1.1 header field values consist of words separated by LWS |
---|
759 | or special characters. These special characters MUST be in a quoted |
---|
760 | string to be used within a parameter value (as defined in |
---|
761 | Section 3.4). |
---|
762 | |
---|
763 | token = 1*<any CHAR except CTLs or separators> |
---|
764 | separators = "(" | ")" | "<" | ">" | "@" |
---|
765 | | "," | ";" | ":" | "\" | <"> |
---|
766 | | "/" | "[" | "]" | "?" | "=" |
---|
767 | | "{" | "}" | SP | HT |
---|
768 | |
---|
769 | Comments can be included in some HTTP header fields by surrounding |
---|
770 | the comment text with parentheses. Comments are only allowed in |
---|
771 | fields containing "comment" as part of their field value definition. |
---|
772 | In all other fields, parentheses are considered part of the field |
---|
773 | value. |
---|
774 | |
---|
775 | comment = "(" *( ctext | quoted-pair | comment ) ")" |
---|
776 | ctext = <any TEXT excluding "(" and ")"> |
---|
777 | |
---|
778 | A string of text is parsed as a single word if it is quoted using |
---|
779 | double-quote marks. |
---|
780 | |
---|
781 | |
---|
782 | |
---|
783 | Fielding, et al. Expires June 22, 2008 [Page 14] |
---|
784 | |
---|
785 | Internet-Draft HTTP/1.1 December 2007 |
---|
786 | |
---|
787 | |
---|
788 | quoted-string = ( <"> *(qdtext | quoted-pair ) <"> ) |
---|
789 | qdtext = <any TEXT except <">> |
---|
790 | |
---|
791 | The backslash character ("\") MAY be used as a single-character |
---|
792 | quoting mechanism only within quoted-string and comment constructs. |
---|
793 | |
---|
794 | quoted-pair = "\" CHAR |
---|
795 | |
---|
796 | |
---|
797 | 3. Protocol Parameters |
---|
798 | |
---|
799 | 3.1. HTTP Version |
---|
800 | |
---|
801 | HTTP uses a "<major>.<minor>" numbering scheme to indicate versions |
---|
802 | of the protocol. The protocol versioning policy is intended to allow |
---|
803 | the sender to indicate the format of a message and its capacity for |
---|
804 | understanding further HTTP communication, rather than the features |
---|
805 | obtained via that communication. No change is made to the version |
---|
806 | number for the addition of message components which do not affect |
---|
807 | communication behavior or which only add to extensible field values. |
---|
808 | The <minor> number is incremented when the changes made to the |
---|
809 | protocol add features which do not change the general message parsing |
---|
810 | algorithm, but which may add to the message semantics and imply |
---|
811 | additional capabilities of the sender. The <major> number is |
---|
812 | incremented when the format of a message within the protocol is |
---|
813 | changed. See RFC 2145 [RFC2145] for a fuller explanation. |
---|
814 | |
---|
815 | The version of an HTTP message is indicated by an HTTP-Version field |
---|
816 | in the first line of the message. |
---|
817 | |
---|
818 | HTTP-Version = "HTTP" "/" 1*DIGIT "." 1*DIGIT |
---|
819 | |
---|
820 | Note that the major and minor numbers MUST be treated as separate |
---|
821 | integers and that each MAY be incremented higher than a single digit. |
---|
822 | Thus, HTTP/2.4 is a lower version than HTTP/2.13, which in turn is |
---|
823 | lower than HTTP/12.3. Leading zeros MUST be ignored by recipients |
---|
824 | and MUST NOT be sent. |
---|
825 | |
---|
826 | An application that sends a request or response message that includes |
---|
827 | HTTP-Version of "HTTP/1.1" MUST be at least conditionally compliant |
---|
828 | with this specification. Applications that are at least |
---|
829 | conditionally compliant with this specification SHOULD use an HTTP- |
---|
830 | Version of "HTTP/1.1" in their messages, and MUST do so for any |
---|
831 | message that is not compatible with HTTP/1.0. For more details on |
---|
832 | when to send specific HTTP-Version values, see RFC 2145 [RFC2145]. |
---|
833 | |
---|
834 | The HTTP version of an application is the highest HTTP version for |
---|
835 | which the application is at least conditionally compliant. |
---|
836 | |
---|
837 | |
---|
838 | |
---|
839 | Fielding, et al. Expires June 22, 2008 [Page 15] |
---|
840 | |
---|
841 | Internet-Draft HTTP/1.1 December 2007 |
---|
842 | |
---|
843 | |
---|
844 | Proxy and gateway applications need to be careful when forwarding |
---|
845 | messages in protocol versions different from that of the application. |
---|
846 | Since the protocol version indicates the protocol capability of the |
---|
847 | sender, a proxy/gateway MUST NOT send a message with a version |
---|
848 | indicator which is greater than its actual version. If a higher |
---|
849 | version request is received, the proxy/gateway MUST either downgrade |
---|
850 | the request version, or respond with an error, or switch to tunnel |
---|
851 | behavior. |
---|
852 | |
---|
853 | Due to interoperability problems with HTTP/1.0 proxies discovered |
---|
854 | since the publication of RFC 2068 [RFC2068], caching proxies MUST, |
---|
855 | gateways MAY, and tunnels MUST NOT upgrade the request to the highest |
---|
856 | version they support. The proxy/gateway's response to that request |
---|
857 | MUST be in the same major version as the request. |
---|
858 | |
---|
859 | Note: Converting between versions of HTTP may involve modification |
---|
860 | of header fields required or forbidden by the versions involved. |
---|
861 | |
---|
862 | 3.2. Uniform Resource Identifiers |
---|
863 | |
---|
864 | URIs have been known by many names: WWW addresses, Universal Document |
---|
865 | Identifiers, Universal Resource Identifiers [RFC1630], and finally |
---|
866 | the combination of Uniform Resource Locators (URL) [RFC1738] and |
---|
867 | Names (URN) [RFC1737]. As far as HTTP is concerned, Uniform Resource |
---|
868 | Identifiers are simply formatted strings which identify--via name, |
---|
869 | location, or any other characteristic--a resource. |
---|
870 | |
---|
871 | 3.2.1. General Syntax |
---|
872 | |
---|
873 | URIs in HTTP can be represented in absolute form or relative to some |
---|
874 | known base URI [RFC1808], depending upon the context of their use. |
---|
875 | The two forms are differentiated by the fact that absolute URIs |
---|
876 | always begin with a scheme name followed by a colon. For definitive |
---|
877 | information on URL syntax and semantics, see "Uniform Resource |
---|
878 | Identifiers (URI): Generic Syntax and Semantics," RFC 2396 [RFC2396] |
---|
879 | (which replaces RFCs 1738 [RFC1738] and RFC 1808 [RFC1808]). This |
---|
880 | specification adopts the definitions of "URI-reference", |
---|
881 | "absoluteURI", "relativeURI", "port", "host","abs_path", "rel_path", |
---|
882 | and "authority" from that specification. |
---|
883 | |
---|
884 | The HTTP protocol does not place any a priori limit on the length of |
---|
885 | a URI. Servers MUST be able to handle the URI of any resource they |
---|
886 | serve, and SHOULD be able to handle URIs of unbounded length if they |
---|
887 | provide GET-based forms that could generate such URIs. A server |
---|
888 | SHOULD return 414 (Request-URI Too Long) status if a URI is longer |
---|
889 | than the server can handle (see Section 9.4.15 of [Part2]). |
---|
890 | |
---|
891 | |
---|
892 | |
---|
893 | |
---|
894 | |
---|
895 | Fielding, et al. Expires June 22, 2008 [Page 16] |
---|
896 | |
---|
897 | Internet-Draft HTTP/1.1 December 2007 |
---|
898 | |
---|
899 | |
---|
900 | Note: Servers ought to be cautious about depending on URI lengths |
---|
901 | above 255 bytes, because some older client or proxy |
---|
902 | implementations might not properly support these lengths. |
---|
903 | |
---|
904 | 3.2.2. http URL |
---|
905 | |
---|
906 | The "http" scheme is used to locate network resources via the HTTP |
---|
907 | protocol. This section defines the scheme-specific syntax and |
---|
908 | semantics for http URLs. |
---|
909 | |
---|
910 | http_URL = "http:" "//" host [ ":" port ] [ abs_path [ "?" query ]] |
---|
911 | |
---|
912 | If the port is empty or not given, port 80 is assumed. The semantics |
---|
913 | are that the identified resource is located at the server listening |
---|
914 | for TCP connections on that port of that host, and the Request-URI |
---|
915 | for the resource is abs_path (Section 5.1.2). The use of IP |
---|
916 | addresses in URLs SHOULD be avoided whenever possible (see RFC 1900 |
---|
917 | [RFC1900]). If the abs_path is not present in the URL, it MUST be |
---|
918 | given as "/" when used as a Request-URI for a resource |
---|
919 | (Section 5.1.2). If a proxy receives a host name which is not a |
---|
920 | fully qualified domain name, it MAY add its domain to the host name |
---|
921 | it received. If a proxy receives a fully qualified domain name, the |
---|
922 | proxy MUST NOT change the host name. |
---|
923 | |
---|
924 | 3.2.3. URI Comparison |
---|
925 | |
---|
926 | When comparing two URIs to decide if they match or not, a client |
---|
927 | SHOULD use a case-sensitive octet-by-octet comparison of the entire |
---|
928 | URIs, with these exceptions: |
---|
929 | |
---|
930 | o A port that is empty or not given is equivalent to the default |
---|
931 | port for that URI-reference; |
---|
932 | |
---|
933 | o Comparisons of host names MUST be case-insensitive; |
---|
934 | |
---|
935 | o Comparisons of scheme names MUST be case-insensitive; |
---|
936 | |
---|
937 | o An empty abs_path is equivalent to an abs_path of "/". |
---|
938 | |
---|
939 | Characters other than those in the "reserved" and "unsafe" sets (see |
---|
940 | RFC 2396 [RFC2396]) are equivalent to their ""%" HEX HEX" encoding. |
---|
941 | |
---|
942 | For example, the following three URIs are equivalent: |
---|
943 | |
---|
944 | http://abc.com:80/~smith/home.html |
---|
945 | http://ABC.com/%7Esmith/home.html |
---|
946 | http://ABC.com:/%7esmith/home.html |
---|
947 | |
---|
948 | |
---|
949 | |
---|
950 | |
---|
951 | Fielding, et al. Expires June 22, 2008 [Page 17] |
---|
952 | |
---|
953 | Internet-Draft HTTP/1.1 December 2007 |
---|
954 | |
---|
955 | |
---|
956 | 3.3. Date/Time Formats |
---|
957 | |
---|
958 | 3.3.1. Full Date |
---|
959 | |
---|
960 | HTTP applications have historically allowed three different formats |
---|
961 | for the representation of date/time stamps: |
---|
962 | |
---|
963 | Sun, 06 Nov 1994 08:49:37 GMT ; RFC 822, updated by RFC 1123 |
---|
964 | Sunday, 06-Nov-94 08:49:37 GMT ; RFC 850, obsoleted by RFC 1036 |
---|
965 | Sun Nov 6 08:49:37 1994 ; ANSI C's asctime() format |
---|
966 | |
---|
967 | The first format is preferred as an Internet standard and represents |
---|
968 | a fixed-length subset of that defined by RFC 1123 [RFC1123] (an |
---|
969 | update to RFC 822 [RFC822]). The second format is in common use, but |
---|
970 | is based on the obsolete RFC 850 [RFC1036] date format and lacks a |
---|
971 | four-digit year. HTTP/1.1 clients and servers that parse the date |
---|
972 | value MUST accept all three formats (for compatibility with |
---|
973 | HTTP/1.0), though they MUST only generate the RFC 1123 format for |
---|
974 | representing HTTP-date values in header fields. See Appendix B for |
---|
975 | further information. |
---|
976 | |
---|
977 | Note: Recipients of date values are encouraged to be robust in |
---|
978 | accepting date values that may have been sent by non-HTTP |
---|
979 | applications, as is sometimes the case when retrieving or posting |
---|
980 | messages via proxies/gateways to SMTP or NNTP. |
---|
981 | |
---|
982 | All HTTP date/time stamps MUST be represented in Greenwich Mean Time |
---|
983 | (GMT), without exception. For the purposes of HTTP, GMT is exactly |
---|
984 | equal to UTC (Coordinated Universal Time). This is indicated in the |
---|
985 | first two formats by the inclusion of "GMT" as the three-letter |
---|
986 | abbreviation for time zone, and MUST be assumed when reading the |
---|
987 | asctime format. HTTP-date is case sensitive and MUST NOT include |
---|
988 | additional LWS beyond that specifically included as SP in the |
---|
989 | grammar. |
---|
990 | |
---|
991 | |
---|
992 | |
---|
993 | |
---|
994 | |
---|
995 | |
---|
996 | |
---|
997 | |
---|
998 | |
---|
999 | |
---|
1000 | |
---|
1001 | |
---|
1002 | |
---|
1003 | |
---|
1004 | |
---|
1005 | |
---|
1006 | |
---|
1007 | Fielding, et al. Expires June 22, 2008 [Page 18] |
---|
1008 | |
---|
1009 | Internet-Draft HTTP/1.1 December 2007 |
---|
1010 | |
---|
1011 | |
---|
1012 | HTTP-date = rfc1123-date | rfc850-date | asctime-date |
---|
1013 | rfc1123-date = wkday "," SP date1 SP time SP "GMT" |
---|
1014 | rfc850-date = weekday "," SP date2 SP time SP "GMT" |
---|
1015 | asctime-date = wkday SP date3 SP time SP 4DIGIT |
---|
1016 | date1 = 2DIGIT SP month SP 4DIGIT |
---|
1017 | ; day month year (e.g., 02 Jun 1982) |
---|
1018 | date2 = 2DIGIT "-" month "-" 2DIGIT |
---|
1019 | ; day-month-year (e.g., 02-Jun-82) |
---|
1020 | date3 = month SP ( 2DIGIT | ( SP 1DIGIT )) |
---|
1021 | ; month day (e.g., Jun 2) |
---|
1022 | time = 2DIGIT ":" 2DIGIT ":" 2DIGIT |
---|
1023 | ; 00:00:00 - 23:59:59 |
---|
1024 | wkday = "Mon" | "Tue" | "Wed" |
---|
1025 | | "Thu" | "Fri" | "Sat" | "Sun" |
---|
1026 | weekday = "Monday" | "Tuesday" | "Wednesday" |
---|
1027 | | "Thursday" | "Friday" | "Saturday" | "Sunday" |
---|
1028 | month = "Jan" | "Feb" | "Mar" | "Apr" |
---|
1029 | | "May" | "Jun" | "Jul" | "Aug" |
---|
1030 | | "Sep" | "Oct" | "Nov" | "Dec" |
---|
1031 | |
---|
1032 | Note: HTTP requirements for the date/time stamp format apply only to |
---|
1033 | their usage within the protocol stream. Clients and servers are not |
---|
1034 | required to use these formats for user presentation, request logging, |
---|
1035 | etc. |
---|
1036 | |
---|
1037 | 3.4. Transfer Codings |
---|
1038 | |
---|
1039 | Transfer-coding values are used to indicate an encoding |
---|
1040 | transformation that has been, can be, or may need to be applied to an |
---|
1041 | entity-body in order to ensure "safe transport" through the network. |
---|
1042 | This differs from a content coding in that the transfer-coding is a |
---|
1043 | property of the message, not of the original entity. |
---|
1044 | |
---|
1045 | transfer-coding = "chunked" | transfer-extension |
---|
1046 | transfer-extension = token *( ";" parameter ) |
---|
1047 | |
---|
1048 | Parameters are in the form of attribute/value pairs. |
---|
1049 | |
---|
1050 | parameter = attribute "=" value |
---|
1051 | attribute = token |
---|
1052 | value = token | quoted-string |
---|
1053 | |
---|
1054 | All transfer-coding values are case-insensitive. HTTP/1.1 uses |
---|
1055 | transfer-coding values in the TE header field (Section 8.5) and in |
---|
1056 | the Transfer-Encoding header field (Section 8.7). |
---|
1057 | |
---|
1058 | Whenever a transfer-coding is applied to a message-body, the set of |
---|
1059 | transfer-codings MUST include "chunked", unless the message is |
---|
1060 | |
---|
1061 | |
---|
1062 | |
---|
1063 | Fielding, et al. Expires June 22, 2008 [Page 19] |
---|
1064 | |
---|
1065 | Internet-Draft HTTP/1.1 December 2007 |
---|
1066 | |
---|
1067 | |
---|
1068 | terminated by closing the connection. When the "chunked" transfer- |
---|
1069 | coding is used, it MUST be the last transfer-coding applied to the |
---|
1070 | message-body. The "chunked" transfer-coding MUST NOT be applied more |
---|
1071 | than once to a message-body. These rules allow the recipient to |
---|
1072 | determine the transfer-length of the message (Section 4.4). |
---|
1073 | |
---|
1074 | Transfer-codings are analogous to the Content-Transfer-Encoding |
---|
1075 | values of MIME [RFC2045], which were designed to enable safe |
---|
1076 | transport of binary data over a 7-bit transport service. However, |
---|
1077 | safe transport has a different focus for an 8bit-clean transfer |
---|
1078 | protocol. In HTTP, the only unsafe characteristic of message-bodies |
---|
1079 | is the difficulty in determining the exact body length (Section 4.4), |
---|
1080 | or the desire to encrypt data over a shared transport. |
---|
1081 | |
---|
1082 | The Internet Assigned Numbers Authority (IANA) acts as a registry for |
---|
1083 | transfer-coding value tokens. Initially, the registry contains the |
---|
1084 | following tokens: "chunked" (Section 3.4.1), "identity" (section |
---|
1085 | 3.6.2), "gzip" ([Part3]), "compress" ([Part3]), and "deflate" |
---|
1086 | ([Part3]). |
---|
1087 | |
---|
1088 | New transfer-coding value tokens SHOULD be registered in the same way |
---|
1089 | as new content-coding value tokens ([Part3]). |
---|
1090 | |
---|
1091 | A server which receives an entity-body with a transfer-coding it does |
---|
1092 | not understand SHOULD return 501 (Unimplemented), and close the |
---|
1093 | connection. A server MUST NOT send transfer-codings to an HTTP/1.0 |
---|
1094 | client. |
---|
1095 | |
---|
1096 | 3.4.1. Chunked Transfer Coding |
---|
1097 | |
---|
1098 | The chunked encoding modifies the body of a message in order to |
---|
1099 | transfer it as a series of chunks, each with its own size indicator, |
---|
1100 | followed by an OPTIONAL trailer containing entity-header fields. |
---|
1101 | This allows dynamically produced content to be transferred along with |
---|
1102 | the information necessary for the recipient to verify that it has |
---|
1103 | received the full message. |
---|
1104 | |
---|
1105 | |
---|
1106 | |
---|
1107 | |
---|
1108 | |
---|
1109 | |
---|
1110 | |
---|
1111 | |
---|
1112 | |
---|
1113 | |
---|
1114 | |
---|
1115 | |
---|
1116 | |
---|
1117 | |
---|
1118 | |
---|
1119 | Fielding, et al. Expires June 22, 2008 [Page 20] |
---|
1120 | |
---|
1121 | Internet-Draft HTTP/1.1 December 2007 |
---|
1122 | |
---|
1123 | |
---|
1124 | Chunked-Body = *chunk |
---|
1125 | last-chunk |
---|
1126 | trailer |
---|
1127 | CRLF |
---|
1128 | |
---|
1129 | chunk = chunk-size [ chunk-extension ] CRLF |
---|
1130 | chunk-data CRLF |
---|
1131 | chunk-size = 1*HEX |
---|
1132 | last-chunk = 1*("0") [ chunk-extension ] CRLF |
---|
1133 | |
---|
1134 | chunk-extension= *( ";" chunk-ext-name [ "=" chunk-ext-val ] ) |
---|
1135 | chunk-ext-name = token |
---|
1136 | chunk-ext-val = token | quoted-string |
---|
1137 | chunk-data = chunk-size(OCTET) |
---|
1138 | trailer = *(entity-header CRLF) |
---|
1139 | |
---|
1140 | The chunk-size field is a string of hex digits indicating the size of |
---|
1141 | the chunk. The chunked encoding is ended by any chunk whose size is |
---|
1142 | zero, followed by the trailer, which is terminated by an empty line. |
---|
1143 | |
---|
1144 | The trailer allows the sender to include additional HTTP header |
---|
1145 | fields at the end of the message. The Trailer header field can be |
---|
1146 | used to indicate which header fields are included in a trailer (see |
---|
1147 | Section 8.6). |
---|
1148 | |
---|
1149 | A server using chunked transfer-coding in a response MUST NOT use the |
---|
1150 | trailer for any header fields unless at least one of the following is |
---|
1151 | true: |
---|
1152 | |
---|
1153 | 1. the request included a TE header field that indicates "trailers" |
---|
1154 | is acceptable in the transfer-coding of the response, as |
---|
1155 | described in Section 8.5; or, |
---|
1156 | |
---|
1157 | 2. the server is the origin server for the response, the trailer |
---|
1158 | fields consist entirely of optional metadata, and the recipient |
---|
1159 | could use the message (in a manner acceptable to the origin |
---|
1160 | server) without receiving this metadata. In other words, the |
---|
1161 | origin server is willing to accept the possibility that the |
---|
1162 | trailer fields might be silently discarded along the path to the |
---|
1163 | client. |
---|
1164 | |
---|
1165 | This requirement prevents an interoperability failure when the |
---|
1166 | message is being received by an HTTP/1.1 (or later) proxy and |
---|
1167 | forwarded to an HTTP/1.0 recipient. It avoids a situation where |
---|
1168 | compliance with the protocol would have necessitated a possibly |
---|
1169 | infinite buffer on the proxy. |
---|
1170 | |
---|
1171 | A process for decoding the "chunked" transfer-coding can be |
---|
1172 | |
---|
1173 | |
---|
1174 | |
---|
1175 | Fielding, et al. Expires June 22, 2008 [Page 21] |
---|
1176 | |
---|
1177 | Internet-Draft HTTP/1.1 December 2007 |
---|
1178 | |
---|
1179 | |
---|
1180 | represented in pseudo-code as: |
---|
1181 | |
---|
1182 | length := 0 |
---|
1183 | read chunk-size, chunk-extension (if any) and CRLF |
---|
1184 | while (chunk-size > 0) { |
---|
1185 | read chunk-data and CRLF |
---|
1186 | append chunk-data to entity-body |
---|
1187 | length := length + chunk-size |
---|
1188 | read chunk-size and CRLF |
---|
1189 | } |
---|
1190 | read entity-header |
---|
1191 | while (entity-header not empty) { |
---|
1192 | append entity-header to existing header fields |
---|
1193 | read entity-header |
---|
1194 | } |
---|
1195 | Content-Length := length |
---|
1196 | Remove "chunked" from Transfer-Encoding |
---|
1197 | |
---|
1198 | All HTTP/1.1 applications MUST be able to receive and decode the |
---|
1199 | "chunked" transfer-coding, and MUST ignore chunk-extension extensions |
---|
1200 | they do not understand. |
---|
1201 | |
---|
1202 | |
---|
1203 | 4. HTTP Message |
---|
1204 | |
---|
1205 | 4.1. Message Types |
---|
1206 | |
---|
1207 | HTTP messages consist of requests from client to server and responses |
---|
1208 | from server to client. |
---|
1209 | |
---|
1210 | HTTP-message = Request | Response ; HTTP/1.1 messages |
---|
1211 | |
---|
1212 | Request (Section 5) and Response (Section 6) messages use the generic |
---|
1213 | message format of RFC 822 [RFC822] for transferring entities (the |
---|
1214 | payload of the message). Both types of message consist of a start- |
---|
1215 | line, zero or more header fields (also known as "headers"), an empty |
---|
1216 | line (i.e., a line with nothing preceding the CRLF) indicating the |
---|
1217 | end of the header fields, and possibly a message-body. |
---|
1218 | |
---|
1219 | generic-message = start-line |
---|
1220 | *(message-header CRLF) |
---|
1221 | CRLF |
---|
1222 | [ message-body ] |
---|
1223 | start-line = Request-Line | Status-Line |
---|
1224 | |
---|
1225 | In the interest of robustness, servers SHOULD ignore any empty |
---|
1226 | line(s) received where a Request-Line is expected. In other words, |
---|
1227 | if the server is reading the protocol stream at the beginning of a |
---|
1228 | |
---|
1229 | |
---|
1230 | |
---|
1231 | Fielding, et al. Expires June 22, 2008 [Page 22] |
---|
1232 | |
---|
1233 | Internet-Draft HTTP/1.1 December 2007 |
---|
1234 | |
---|
1235 | |
---|
1236 | message and receives a CRLF first, it should ignore the CRLF. |
---|
1237 | |
---|
1238 | Certain buggy HTTP/1.0 client implementations generate extra CRLF's |
---|
1239 | after a POST request. To restate what is explicitly forbidden by the |
---|
1240 | BNF, an HTTP/1.1 client MUST NOT preface or follow a request with an |
---|
1241 | extra CRLF. |
---|
1242 | |
---|
1243 | 4.2. Message Headers |
---|
1244 | |
---|
1245 | HTTP header fields, which include general-header (Section 4.5), |
---|
1246 | request-header (Section 4 of [Part2]), response-header (Section 6 of |
---|
1247 | [Part2]), and entity-header (Section 3.1 of [Part3]) fields, follow |
---|
1248 | the same generic format as that given in Section 3.1 of RFC 822 |
---|
1249 | [RFC822]. Each header field consists of a name followed by a colon |
---|
1250 | (":") and the field value. Field names are case-insensitive. The |
---|
1251 | field value MAY be preceded by any amount of LWS, though a single SP |
---|
1252 | is preferred. Header fields can be extended over multiple lines by |
---|
1253 | preceding each extra line with at least one SP or HT. Applications |
---|
1254 | ought to follow "common form", where one is known or indicated, when |
---|
1255 | generating HTTP constructs, since there might exist some |
---|
1256 | implementations that fail to accept anything beyond the common forms. |
---|
1257 | |
---|
1258 | message-header = field-name ":" [ field-value ] |
---|
1259 | field-name = token |
---|
1260 | field-value = *( field-content | LWS ) |
---|
1261 | field-content = <the OCTETs making up the field-value |
---|
1262 | and consisting of either *TEXT or combinations |
---|
1263 | of token, separators, and quoted-string> |
---|
1264 | |
---|
1265 | The field-content does not include any leading or trailing LWS: |
---|
1266 | linear white space occurring before the first non-whitespace |
---|
1267 | character of the field-value or after the last non-whitespace |
---|
1268 | character of the field-value. Such leading or trailing LWS MAY be |
---|
1269 | removed without changing the semantics of the field value. Any LWS |
---|
1270 | that occurs between field-content MAY be replaced with a single SP |
---|
1271 | before interpreting the field value or forwarding the message |
---|
1272 | downstream. |
---|
1273 | |
---|
1274 | The order in which header fields with differing field names are |
---|
1275 | received is not significant. However, it is "good practice" to send |
---|
1276 | general-header fields first, followed by request-header or response- |
---|
1277 | header fields, and ending with the entity-header fields. |
---|
1278 | |
---|
1279 | Multiple message-header fields with the same field-name MAY be |
---|
1280 | present in a message if and only if the entire field-value for that |
---|
1281 | header field is defined as a comma-separated list [i.e., #(values)]. |
---|
1282 | It MUST be possible to combine the multiple header fields into one |
---|
1283 | "field-name: field-value" pair, without changing the semantics of the |
---|
1284 | |
---|
1285 | |
---|
1286 | |
---|
1287 | Fielding, et al. Expires June 22, 2008 [Page 23] |
---|
1288 | |
---|
1289 | Internet-Draft HTTP/1.1 December 2007 |
---|
1290 | |
---|
1291 | |
---|
1292 | message, by appending each subsequent field-value to the first, each |
---|
1293 | separated by a comma. The order in which header fields with the same |
---|
1294 | field-name are received is therefore significant to the |
---|
1295 | interpretation of the combined field value, and thus a proxy MUST NOT |
---|
1296 | change the order of these field values when a message is forwarded. |
---|
1297 | |
---|
1298 | 4.3. Message Body |
---|
1299 | |
---|
1300 | The message-body (if any) of an HTTP message is used to carry the |
---|
1301 | entity-body associated with the request or response. The message- |
---|
1302 | body differs from the entity-body only when a transfer-coding has |
---|
1303 | been applied, as indicated by the Transfer-Encoding header field |
---|
1304 | (Section 8.7). |
---|
1305 | |
---|
1306 | message-body = entity-body |
---|
1307 | | <entity-body encoded as per Transfer-Encoding> |
---|
1308 | |
---|
1309 | Transfer-Encoding MUST be used to indicate any transfer-codings |
---|
1310 | applied by an application to ensure safe and proper transfer of the |
---|
1311 | message. Transfer-Encoding is a property of the message, not of the |
---|
1312 | entity, and thus MAY be added or removed by any application along the |
---|
1313 | request/response chain. (However, Section 3.4 places restrictions on |
---|
1314 | when certain transfer-codings may be used.) |
---|
1315 | |
---|
1316 | The rules for when a message-body is allowed in a message differ for |
---|
1317 | requests and responses. |
---|
1318 | |
---|
1319 | The presence of a message-body in a request is signaled by the |
---|
1320 | inclusion of a Content-Length or Transfer-Encoding header field in |
---|
1321 | the request's message-headers. A message-body MUST NOT be included |
---|
1322 | in a request if the specification of the request method (Section 3 of |
---|
1323 | [Part2]) does not allow sending an entity-body in requests. A server |
---|
1324 | SHOULD read and forward a message-body on any request; if the request |
---|
1325 | method does not include defined semantics for an entity-body, then |
---|
1326 | the message-body SHOULD be ignored when handling the request. |
---|
1327 | |
---|
1328 | For response messages, whether or not a message-body is included with |
---|
1329 | a message is dependent on both the request method and the response |
---|
1330 | status code (Section 6.1.1). All responses to the HEAD request |
---|
1331 | method MUST NOT include a message-body, even though the presence of |
---|
1332 | entity-header fields might lead one to believe they do. All 1xx |
---|
1333 | (informational), 204 (no content), and 304 (not modified) responses |
---|
1334 | MUST NOT include a message-body. All other responses do include a |
---|
1335 | message-body, although it MAY be of zero length. |
---|
1336 | |
---|
1337 | |
---|
1338 | |
---|
1339 | |
---|
1340 | |
---|
1341 | |
---|
1342 | |
---|
1343 | Fielding, et al. Expires June 22, 2008 [Page 24] |
---|
1344 | |
---|
1345 | Internet-Draft HTTP/1.1 December 2007 |
---|
1346 | |
---|
1347 | |
---|
1348 | 4.4. Message Length |
---|
1349 | |
---|
1350 | The transfer-length of a message is the length of the message-body as |
---|
1351 | it appears in the message; that is, after any transfer-codings have |
---|
1352 | been applied. When a message-body is included with a message, the |
---|
1353 | transfer-length of that body is determined by one of the following |
---|
1354 | (in order of precedence): |
---|
1355 | |
---|
1356 | 1. Any response message which "MUST NOT" include a message-body |
---|
1357 | (such as the 1xx, 204, and 304 responses and any response to a |
---|
1358 | HEAD request) is always terminated by the first empty line after |
---|
1359 | the header fields, regardless of the entity-header fields present |
---|
1360 | in the message. |
---|
1361 | |
---|
1362 | 2. If a Transfer-Encoding header field (Section 8.7) is present and |
---|
1363 | has any value other than "identity", then the transfer-length is |
---|
1364 | defined by use of the "chunked" transfer-coding (Section 3.4), |
---|
1365 | unless the message is terminated by closing the connection. |
---|
1366 | |
---|
1367 | 3. If a Content-Length header field (Section 8.2) is present, its |
---|
1368 | decimal value in OCTETs represents both the entity-length and the |
---|
1369 | transfer-length. The Content-Length header field MUST NOT be |
---|
1370 | sent if these two lengths are different (i.e., if a Transfer- |
---|
1371 | Encoding header field is present). If a message is received with |
---|
1372 | both a Transfer-Encoding header field and a Content-Length header |
---|
1373 | field, the latter MUST be ignored. |
---|
1374 | |
---|
1375 | 4. If the message uses the media type "multipart/byteranges", and |
---|
1376 | the ransfer-length is not otherwise specified, then this self- |
---|
1377 | elimiting media type defines the transfer-length. This media |
---|
1378 | type UST NOT be used unless the sender knows that the recipient |
---|
1379 | can arse it; the presence in a request of a Range header with |
---|
1380 | ultiple byte-range specifiers from a 1.1 client implies that the |
---|
1381 | lient can parse multipart/byteranges responses. |
---|
1382 | |
---|
1383 | A range header might be forwarded by a 1.0 proxy that does not |
---|
1384 | understand multipart/byteranges; in this case the server MUST |
---|
1385 | delimit the message using methods defined in items 1, 3 or 5 |
---|
1386 | of this section. |
---|
1387 | |
---|
1388 | 5. By the server closing the connection. (Closing the connection |
---|
1389 | cannot be used to indicate the end of a request body, since that |
---|
1390 | would leave no possibility for the server to send back a |
---|
1391 | response.) |
---|
1392 | |
---|
1393 | For compatibility with HTTP/1.0 applications, HTTP/1.1 requests |
---|
1394 | containing a message-body MUST include a valid Content-Length header |
---|
1395 | field unless the server is known to be HTTP/1.1 compliant. If a |
---|
1396 | |
---|
1397 | |
---|
1398 | |
---|
1399 | Fielding, et al. Expires June 22, 2008 [Page 25] |
---|
1400 | |
---|
1401 | Internet-Draft HTTP/1.1 December 2007 |
---|
1402 | |
---|
1403 | |
---|
1404 | request contains a message-body and a Content-Length is not given, |
---|
1405 | the server SHOULD respond with 400 (bad request) if it cannot |
---|
1406 | determine the length of the message, or with 411 (length required) if |
---|
1407 | it wishes to insist on receiving a valid Content-Length. |
---|
1408 | |
---|
1409 | All HTTP/1.1 applications that receive entities MUST accept the |
---|
1410 | "chunked" transfer-coding (Section 3.4), thus allowing this mechanism |
---|
1411 | to be used for messages when the message length cannot be determined |
---|
1412 | in advance. |
---|
1413 | |
---|
1414 | Messages MUST NOT include both a Content-Length header field and a |
---|
1415 | non-identity transfer-coding. If the message does include a non- |
---|
1416 | identity transfer-coding, the Content-Length MUST be ignored. |
---|
1417 | |
---|
1418 | When a Content-Length is given in a message where a message-body is |
---|
1419 | allowed, its field value MUST exactly match the number of OCTETs in |
---|
1420 | the message-body. HTTP/1.1 user agents MUST notify the user when an |
---|
1421 | invalid length is received and detected. |
---|
1422 | |
---|
1423 | 4.5. General Header Fields |
---|
1424 | |
---|
1425 | There are a few header fields which have general applicability for |
---|
1426 | both request and response messages, but which do not apply to the |
---|
1427 | entity being transferred. These header fields apply only to the |
---|
1428 | message being transmitted. |
---|
1429 | |
---|
1430 | general-header = Cache-Control ; [Part6], Section 3.2 |
---|
1431 | | Connection ; Section 8.1 |
---|
1432 | | Date ; Section 8.3 |
---|
1433 | | Pragma ; [Part6], Section 3.4 |
---|
1434 | | Trailer ; Section 8.6 |
---|
1435 | | Transfer-Encoding ; Section 8.7 |
---|
1436 | | Upgrade ; Section 8.8 |
---|
1437 | | Via ; Section 8.9 |
---|
1438 | | Warning ; [Part6], Section 3.6 |
---|
1439 | |
---|
1440 | General-header field names can be extended reliably only in |
---|
1441 | combination with a change in the protocol version. However, new or |
---|
1442 | experimental header fields may be given the semantics of general |
---|
1443 | header fields if all parties in the communication recognize them to |
---|
1444 | be general-header fields. Unrecognized header fields are treated as |
---|
1445 | entity-header fields. |
---|
1446 | |
---|
1447 | |
---|
1448 | 5. Request |
---|
1449 | |
---|
1450 | A request message from a client to a server includes, within the |
---|
1451 | first line of that message, the method to be applied to the resource, |
---|
1452 | |
---|
1453 | |
---|
1454 | |
---|
1455 | Fielding, et al. Expires June 22, 2008 [Page 26] |
---|
1456 | |
---|
1457 | Internet-Draft HTTP/1.1 December 2007 |
---|
1458 | |
---|
1459 | |
---|
1460 | the identifier of the resource, and the protocol version in use. |
---|
1461 | |
---|
1462 | Request = Request-Line ; Section 5.1 |
---|
1463 | *(( general-header ; Section 4.5 |
---|
1464 | | request-header ; [Part2], Section 4 |
---|
1465 | | entity-header ) CRLF) ; [Part3], Section 3.1 |
---|
1466 | CRLF |
---|
1467 | [ message-body ] ; Section 4.3 |
---|
1468 | |
---|
1469 | 5.1. Request-Line |
---|
1470 | |
---|
1471 | The Request-Line begins with a method token, followed by the Request- |
---|
1472 | URI and the protocol version, and ending with CRLF. The elements are |
---|
1473 | separated by SP characters. No CR or LF is allowed except in the |
---|
1474 | final CRLF sequence. |
---|
1475 | |
---|
1476 | Request-Line = Method SP Request-URI SP HTTP-Version CRLF |
---|
1477 | |
---|
1478 | 5.1.1. Method |
---|
1479 | |
---|
1480 | The Method token indicates the method to be performed on the resource |
---|
1481 | identified by the Request-URI. The method is case-sensitive. |
---|
1482 | |
---|
1483 | Method = token |
---|
1484 | |
---|
1485 | 5.1.2. Request-URI |
---|
1486 | |
---|
1487 | The Request-URI is a Uniform Resource Identifier (Section 3.2) and |
---|
1488 | identifies the resource upon which to apply the request. |
---|
1489 | |
---|
1490 | Request-URI = "*" | absoluteURI | abs_path | authority |
---|
1491 | |
---|
1492 | The four options for Request-URI are dependent on the nature of the |
---|
1493 | request. The asterisk "*" means that the request does not apply to a |
---|
1494 | particular resource, but to the server itself, and is only allowed |
---|
1495 | when the method used does not necessarily apply to a resource. One |
---|
1496 | example would be |
---|
1497 | |
---|
1498 | OPTIONS * HTTP/1.1 |
---|
1499 | |
---|
1500 | The absoluteURI form is REQUIRED when the request is being made to a |
---|
1501 | proxy. The proxy is requested to forward the request or service it |
---|
1502 | from a valid cache, and return the response. Note that the proxy MAY |
---|
1503 | forward the request on to another proxy or directly to the server |
---|
1504 | specified by the absoluteURI. In order to avoid request loops, a |
---|
1505 | proxy MUST be able to recognize all of its server names, including |
---|
1506 | any aliases, local variations, and the numeric IP address. An |
---|
1507 | example Request-Line would be: |
---|
1508 | |
---|
1509 | |
---|
1510 | |
---|
1511 | Fielding, et al. Expires June 22, 2008 [Page 27] |
---|
1512 | |
---|
1513 | Internet-Draft HTTP/1.1 December 2007 |
---|
1514 | |
---|
1515 | |
---|
1516 | GET http://www.w3.org/pub/WWW/TheProject.html HTTP/1.1 |
---|
1517 | |
---|
1518 | To allow for transition to absoluteURIs in all requests in future |
---|
1519 | versions of HTTP, all HTTP/1.1 servers MUST accept the absoluteURI |
---|
1520 | form in requests, even though HTTP/1.1 clients will only generate |
---|
1521 | them in requests to proxies. |
---|
1522 | |
---|
1523 | The authority form is only used by the CONNECT method (Section 8.9 of |
---|
1524 | [Part2]). |
---|
1525 | |
---|
1526 | The most common form of Request-URI is that used to identify a |
---|
1527 | resource on an origin server or gateway. In this case the absolute |
---|
1528 | path of the URI MUST be transmitted (see Section 3.2.1, abs_path) as |
---|
1529 | the Request-URI, and the network location of the URI (authority) MUST |
---|
1530 | be transmitted in a Host header field. For example, a client wishing |
---|
1531 | to retrieve the resource above directly from the origin server would |
---|
1532 | create a TCP connection to port 80 of the host "www.w3.org" and send |
---|
1533 | the lines: |
---|
1534 | |
---|
1535 | GET /pub/WWW/TheProject.html HTTP/1.1 |
---|
1536 | Host: www.w3.org |
---|
1537 | |
---|
1538 | followed by the remainder of the Request. Note that the absolute |
---|
1539 | path cannot be empty; if none is present in the original URI, it MUST |
---|
1540 | be given as "/" (the server root). |
---|
1541 | |
---|
1542 | The Request-URI is transmitted in the format specified in |
---|
1543 | Section 3.2.1. If the Request-URI is encoded using the "% HEX HEX" |
---|
1544 | encoding [RFC2396], the origin server MUST decode the Request-URI in |
---|
1545 | order to properly interpret the request. Servers SHOULD respond to |
---|
1546 | invalid Request-URIs with an appropriate status code. |
---|
1547 | |
---|
1548 | A transparent proxy MUST NOT rewrite the "abs_path" part of the |
---|
1549 | received Request-URI when forwarding it to the next inbound server, |
---|
1550 | except as noted above to replace a null abs_path with "/". |
---|
1551 | |
---|
1552 | Note: The "no rewrite" rule prevents the proxy from changing the |
---|
1553 | meaning of the request when the origin server is improperly using |
---|
1554 | a non-reserved URI character for a reserved purpose. Implementors |
---|
1555 | should be aware that some pre-HTTP/1.1 proxies have been known to |
---|
1556 | rewrite the Request-URI. |
---|
1557 | |
---|
1558 | 5.2. The Resource Identified by a Request |
---|
1559 | |
---|
1560 | The exact resource identified by an Internet request is determined by |
---|
1561 | examining both the Request-URI and the Host header field. |
---|
1562 | |
---|
1563 | An origin server that does not allow resources to differ by the |
---|
1564 | |
---|
1565 | |
---|
1566 | |
---|
1567 | Fielding, et al. Expires June 22, 2008 [Page 28] |
---|
1568 | |
---|
1569 | Internet-Draft HTTP/1.1 December 2007 |
---|
1570 | |
---|
1571 | |
---|
1572 | requested host MAY ignore the Host header field value when |
---|
1573 | determining the resource identified by an HTTP/1.1 request. (But see |
---|
1574 | Appendix D.1.1 for other requirements on Host support in HTTP/1.1.) |
---|
1575 | |
---|
1576 | An origin server that does differentiate resources based on the host |
---|
1577 | requested (sometimes referred to as virtual hosts or vanity host |
---|
1578 | names) MUST use the following rules for determining the requested |
---|
1579 | resource on an HTTP/1.1 request: |
---|
1580 | |
---|
1581 | 1. If Request-URI is an absoluteURI, the host is part of the |
---|
1582 | Request-URI. Any Host header field value in the request MUST be |
---|
1583 | ignored. |
---|
1584 | |
---|
1585 | 2. If the Request-URI is not an absoluteURI, and the request |
---|
1586 | includes a Host header field, the host is determined by the Host |
---|
1587 | header field value. |
---|
1588 | |
---|
1589 | 3. If the host as determined by rule 1 or 2 is not a valid host on |
---|
1590 | the server, the response MUST be a 400 (Bad Request) error |
---|
1591 | message. |
---|
1592 | |
---|
1593 | Recipients of an HTTP/1.0 request that lacks a Host header field MAY |
---|
1594 | attempt to use heuristics (e.g., examination of the URI path for |
---|
1595 | something unique to a particular host) in order to determine what |
---|
1596 | exact resource is being requested. |
---|
1597 | |
---|
1598 | |
---|
1599 | 6. Response |
---|
1600 | |
---|
1601 | After receiving and interpreting a request message, a server responds |
---|
1602 | with an HTTP response message. |
---|
1603 | |
---|
1604 | Response = Status-Line ; Section 6.1 |
---|
1605 | *(( general-header ; Section 4.5 |
---|
1606 | | response-header ; [Part2], Section 6 |
---|
1607 | | entity-header ) CRLF) ; [Part3], Section 3.1 |
---|
1608 | CRLF |
---|
1609 | [ message-body ] ; Section 4.3 |
---|
1610 | |
---|
1611 | 6.1. Status-Line |
---|
1612 | |
---|
1613 | The first line of a Response message is the Status-Line, consisting |
---|
1614 | of the protocol version followed by a numeric status code and its |
---|
1615 | associated textual phrase, with each element separated by SP |
---|
1616 | characters. No CR or LF is allowed except in the final CRLF |
---|
1617 | sequence. |
---|
1618 | |
---|
1619 | Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF |
---|
1620 | |
---|
1621 | |
---|
1622 | |
---|
1623 | Fielding, et al. Expires June 22, 2008 [Page 29] |
---|
1624 | |
---|
1625 | Internet-Draft HTTP/1.1 December 2007 |
---|
1626 | |
---|
1627 | |
---|
1628 | 6.1.1. Status Code and Reason Phrase |
---|
1629 | |
---|
1630 | The Status-Code element is a 3-digit integer result code of the |
---|
1631 | attempt to understand and satisfy the request. These codes are fully |
---|
1632 | defined in Section 9 of [Part2]. The Reason-Phrase is intended to |
---|
1633 | give a short textual description of the Status-Code. The Status-Code |
---|
1634 | is intended for use by automata and the Reason-Phrase is intended for |
---|
1635 | the human user. The client is not required to examine or display the |
---|
1636 | Reason-Phrase. |
---|
1637 | |
---|
1638 | The first digit of the Status-Code defines the class of response. |
---|
1639 | The last two digits do not have any categorization role. There are 5 |
---|
1640 | values for the first digit: |
---|
1641 | |
---|
1642 | o 1xx: Informational - Request received, continuing process |
---|
1643 | |
---|
1644 | o 2xx: Success - The action was successfully received, understood, |
---|
1645 | and accepted |
---|
1646 | |
---|
1647 | o 3xx: Redirection - Further action must be taken in order to |
---|
1648 | complete the request |
---|
1649 | |
---|
1650 | o 4xx: Client Error - The request contains bad syntax or cannot be |
---|
1651 | fulfilled |
---|
1652 | |
---|
1653 | o 5xx: Server Error - The server failed to fulfill an apparently |
---|
1654 | valid request |
---|
1655 | |
---|
1656 | |
---|
1657 | Status-Code = 3DIGIT |
---|
1658 | Reason-Phrase = *<TEXT, excluding CR, LF> |
---|
1659 | |
---|
1660 | |
---|
1661 | 7. Connections |
---|
1662 | |
---|
1663 | 7.1. Persistent Connections |
---|
1664 | |
---|
1665 | 7.1.1. Purpose |
---|
1666 | |
---|
1667 | Prior to persistent connections, a separate TCP connection was |
---|
1668 | established to fetch each URL, increasing the load on HTTP servers |
---|
1669 | and causing congestion on the Internet. The use of inline images and |
---|
1670 | other associated data often require a client to make multiple |
---|
1671 | requests of the same server in a short amount of time. Analysis of |
---|
1672 | these performance problems and results from a prototype |
---|
1673 | implementation are available [Pad1995] [Spe]. Implementation |
---|
1674 | experience and measurements of actual HTTP/1.1 (RFC 2068) |
---|
1675 | implementations show good results [Nie1997]. Alternatives have also |
---|
1676 | |
---|
1677 | |
---|
1678 | |
---|
1679 | Fielding, et al. Expires June 22, 2008 [Page 30] |
---|
1680 | |
---|
1681 | Internet-Draft HTTP/1.1 December 2007 |
---|
1682 | |
---|
1683 | |
---|
1684 | been explored, for example, T/TCP [Tou1998]. |
---|
1685 | |
---|
1686 | Persistent HTTP connections have a number of advantages: |
---|
1687 | |
---|
1688 | o By opening and closing fewer TCP connections, CPU time is saved in |
---|
1689 | routers and hosts (clients, servers, proxies, gateways, tunnels, |
---|
1690 | or caches), and memory used for TCP protocol control blocks can be |
---|
1691 | saved in hosts. |
---|
1692 | |
---|
1693 | o HTTP requests and responses can be pipelined on a connection. |
---|
1694 | Pipelining allows a client to make multiple requests without |
---|
1695 | waiting for each response, allowing a single TCP connection to be |
---|
1696 | used much more efficiently, with much lower elapsed time. |
---|
1697 | |
---|
1698 | o Network congestion is reduced by reducing the number of packets |
---|
1699 | caused by TCP opens, and by allowing TCP sufficient time to |
---|
1700 | determine the congestion state of the network. |
---|
1701 | |
---|
1702 | o Latency on subsequent requests is reduced since there is no time |
---|
1703 | spent in TCP's connection opening handshake. |
---|
1704 | |
---|
1705 | o HTTP can evolve more gracefully, since errors can be reported |
---|
1706 | without the penalty of closing the TCP connection. Clients using |
---|
1707 | future versions of HTTP might optimistically try a new feature, |
---|
1708 | but if communicating with an older server, retry with old |
---|
1709 | semantics after an error is reported. |
---|
1710 | |
---|
1711 | HTTP implementations SHOULD implement persistent connections. |
---|
1712 | |
---|
1713 | 7.1.2. Overall Operation |
---|
1714 | |
---|
1715 | A significant difference between HTTP/1.1 and earlier versions of |
---|
1716 | HTTP is that persistent connections are the default behavior of any |
---|
1717 | HTTP connection. That is, unless otherwise indicated, the client |
---|
1718 | SHOULD assume that the server will maintain a persistent connection, |
---|
1719 | even after error responses from the server. |
---|
1720 | |
---|
1721 | Persistent connections provide a mechanism by which a client and a |
---|
1722 | server can signal the close of a TCP connection. This signaling |
---|
1723 | takes place using the Connection header field (Section 8.1). Once a |
---|
1724 | close has been signaled, the client MUST NOT send any more requests |
---|
1725 | on that connection. |
---|
1726 | |
---|
1727 | 7.1.2.1. Negotiation |
---|
1728 | |
---|
1729 | An HTTP/1.1 server MAY assume that a HTTP/1.1 client intends to |
---|
1730 | maintain a persistent connection unless a Connection header including |
---|
1731 | the connection-token "close" was sent in the request. If the server |
---|
1732 | |
---|
1733 | |
---|
1734 | |
---|
1735 | Fielding, et al. Expires June 22, 2008 [Page 31] |
---|
1736 | |
---|
1737 | Internet-Draft HTTP/1.1 December 2007 |
---|
1738 | |
---|
1739 | |
---|
1740 | chooses to close the connection immediately after sending the |
---|
1741 | response, it SHOULD send a Connection header including the |
---|
1742 | connection-token close. |
---|
1743 | |
---|
1744 | An HTTP/1.1 client MAY expect a connection to remain open, but would |
---|
1745 | decide to keep it open based on whether the response from a server |
---|
1746 | contains a Connection header with the connection-token close. In |
---|
1747 | case the client does not want to maintain a connection for more than |
---|
1748 | that request, it SHOULD send a Connection header including the |
---|
1749 | connection-token close. |
---|
1750 | |
---|
1751 | If either the client or the server sends the close token in the |
---|
1752 | Connection header, that request becomes the last one for the |
---|
1753 | connection. |
---|
1754 | |
---|
1755 | Clients and servers SHOULD NOT assume that a persistent connection is |
---|
1756 | maintained for HTTP versions less than 1.1 unless it is explicitly |
---|
1757 | signaled. See Appendix D.2 for more information on backward |
---|
1758 | compatibility with HTTP/1.0 clients. |
---|
1759 | |
---|
1760 | In order to remain persistent, all messages on the connection MUST |
---|
1761 | have a self-defined message length (i.e., one not defined by closure |
---|
1762 | of the connection), as described in Section 4.4. |
---|
1763 | |
---|
1764 | 7.1.2.2. Pipelining |
---|
1765 | |
---|
1766 | A client that supports persistent connections MAY "pipeline" its |
---|
1767 | requests (i.e., send multiple requests without waiting for each |
---|
1768 | response). A server MUST send its responses to those requests in the |
---|
1769 | same order that the requests were received. |
---|
1770 | |
---|
1771 | Clients which assume persistent connections and pipeline immediately |
---|
1772 | after connection establishment SHOULD be prepared to retry their |
---|
1773 | connection if the first pipelined attempt fails. If a client does |
---|
1774 | such a retry, it MUST NOT pipeline before it knows the connection is |
---|
1775 | persistent. Clients MUST also be prepared to resend their requests |
---|
1776 | if the server closes the connection before sending all of the |
---|
1777 | corresponding responses. |
---|
1778 | |
---|
1779 | Clients SHOULD NOT pipeline requests using non-idempotent methods or |
---|
1780 | non-idempotent sequences of methods (see Section 8.1.2 of [Part2]). |
---|
1781 | Otherwise, a premature termination of the transport connection could |
---|
1782 | lead to indeterminate results. A client wishing to send a non- |
---|
1783 | idempotent request SHOULD wait to send that request until it has |
---|
1784 | received the response status for the previous request. |
---|
1785 | |
---|
1786 | |
---|
1787 | |
---|
1788 | |
---|
1789 | |
---|
1790 | |
---|
1791 | Fielding, et al. Expires June 22, 2008 [Page 32] |
---|
1792 | |
---|
1793 | Internet-Draft HTTP/1.1 December 2007 |
---|
1794 | |
---|
1795 | |
---|
1796 | 7.1.3. Proxy Servers |
---|
1797 | |
---|
1798 | It is especially important that proxies correctly implement the |
---|
1799 | properties of the Connection header field as specified in |
---|
1800 | Section 8.1. |
---|
1801 | |
---|
1802 | The proxy server MUST signal persistent connections separately with |
---|
1803 | its clients and the origin servers (or other proxy servers) that it |
---|
1804 | connects to. Each persistent connection applies to only one |
---|
1805 | transport link. |
---|
1806 | |
---|
1807 | A proxy server MUST NOT establish a HTTP/1.1 persistent connection |
---|
1808 | with an HTTP/1.0 client (but see RFC 2068 [RFC2068] for information |
---|
1809 | and discussion of the problems with the Keep-Alive header implemented |
---|
1810 | by many HTTP/1.0 clients). |
---|
1811 | |
---|
1812 | 7.1.4. Practical Considerations |
---|
1813 | |
---|
1814 | Servers will usually have some time-out value beyond which they will |
---|
1815 | no longer maintain an inactive connection. Proxy servers might make |
---|
1816 | this a higher value since it is likely that the client will be making |
---|
1817 | more connections through the same server. The use of persistent |
---|
1818 | connections places no requirements on the length (or existence) of |
---|
1819 | this time-out for either the client or the server. |
---|
1820 | |
---|
1821 | When a client or server wishes to time-out it SHOULD issue a graceful |
---|
1822 | close on the transport connection. Clients and servers SHOULD both |
---|
1823 | constantly watch for the other side of the transport close, and |
---|
1824 | respond to it as appropriate. If a client or server does not detect |
---|
1825 | the other side's close promptly it could cause unnecessary resource |
---|
1826 | drain on the network. |
---|
1827 | |
---|
1828 | A client, server, or proxy MAY close the transport connection at any |
---|
1829 | time. For example, a client might have started to send a new request |
---|
1830 | at the same time that the server has decided to close the "idle" |
---|
1831 | connection. From the server's point of view, the connection is being |
---|
1832 | closed while it was idle, but from the client's point of view, a |
---|
1833 | request is in progress. |
---|
1834 | |
---|
1835 | This means that clients, servers, and proxies MUST be able to recover |
---|
1836 | from asynchronous close events. Client software SHOULD reopen the |
---|
1837 | transport connection and retransmit the aborted sequence of requests |
---|
1838 | without user interaction so long as the request sequence is |
---|
1839 | idempotent (see Section 8.1.2 of [Part2]). Non-idempotent methods or |
---|
1840 | sequences MUST NOT be automatically retried, although user agents MAY |
---|
1841 | offer a human operator the choice of retrying the request(s). |
---|
1842 | Confirmation by user-agent software with semantic understanding of |
---|
1843 | the application MAY substitute for user confirmation. The automatic |
---|
1844 | |
---|
1845 | |
---|
1846 | |
---|
1847 | Fielding, et al. Expires June 22, 2008 [Page 33] |
---|
1848 | |
---|
1849 | Internet-Draft HTTP/1.1 December 2007 |
---|
1850 | |
---|
1851 | |
---|
1852 | retry SHOULD NOT be repeated if the second sequence of requests |
---|
1853 | fails. |
---|
1854 | |
---|
1855 | Servers SHOULD always respond to at least one request per connection, |
---|
1856 | if at all possible. Servers SHOULD NOT close a connection in the |
---|
1857 | middle of transmitting a response, unless a network or client failure |
---|
1858 | is suspected. |
---|
1859 | |
---|
1860 | Clients that use persistent connections SHOULD limit the number of |
---|
1861 | simultaneous connections that they maintain to a given server. A |
---|
1862 | single-user client SHOULD NOT maintain more than 2 connections with |
---|
1863 | any server or proxy. A proxy SHOULD use up to 2*N connections to |
---|
1864 | another server or proxy, where N is the number of simultaneously |
---|
1865 | active users. These guidelines are intended to improve HTTP response |
---|
1866 | times and avoid congestion. |
---|
1867 | |
---|
1868 | 7.2. Message Transmission Requirements |
---|
1869 | |
---|
1870 | 7.2.1. Persistent Connections and Flow Control |
---|
1871 | |
---|
1872 | HTTP/1.1 servers SHOULD maintain persistent connections and use TCP's |
---|
1873 | flow control mechanisms to resolve temporary overloads, rather than |
---|
1874 | terminating connections with the expectation that clients will retry. |
---|
1875 | The latter technique can exacerbate network congestion. |
---|
1876 | |
---|
1877 | 7.2.2. Monitoring Connections for Error Status Messages |
---|
1878 | |
---|
1879 | An HTTP/1.1 (or later) client sending a message-body SHOULD monitor |
---|
1880 | the network connection for an error status while it is transmitting |
---|
1881 | the request. If the client sees an error status, it SHOULD |
---|
1882 | immediately cease transmitting the body. If the body is being sent |
---|
1883 | using a "chunked" encoding (Section 3.4), a zero length chunk and |
---|
1884 | empty trailer MAY be used to prematurely mark the end of the message. |
---|
1885 | If the body was preceded by a Content-Length header, the client MUST |
---|
1886 | close the connection. |
---|
1887 | |
---|
1888 | 7.2.3. Use of the 100 (Continue) Status |
---|
1889 | |
---|
1890 | The purpose of the 100 (Continue) status (see Section 9.1.1 of |
---|
1891 | [Part2]) is to allow a client that is sending a request message with |
---|
1892 | a request body to determine if the origin server is willing to accept |
---|
1893 | the request (based on the request headers) before the client sends |
---|
1894 | the request body. In some cases, it might either be inappropriate or |
---|
1895 | highly inefficient for the client to send the body if the server will |
---|
1896 | reject the message without looking at the body. |
---|
1897 | |
---|
1898 | Requirements for HTTP/1.1 clients: |
---|
1899 | |
---|
1900 | |
---|
1901 | |
---|
1902 | |
---|
1903 | Fielding, et al. Expires June 22, 2008 [Page 34] |
---|
1904 | |
---|
1905 | Internet-Draft HTTP/1.1 December 2007 |
---|
1906 | |
---|
1907 | |
---|
1908 | o If a client will wait for a 100 (Continue) response before sending |
---|
1909 | the request body, it MUST send an Expect request-header field |
---|
1910 | (Section 10.2 of [Part2]) with the "100-continue" expectation. |
---|
1911 | |
---|
1912 | o A client MUST NOT send an Expect request-header field (Section |
---|
1913 | 10.2 of [Part2]) with the "100-continue" expectation if it does |
---|
1914 | not intend to send a request body. |
---|
1915 | |
---|
1916 | Because of the presence of older implementations, the protocol allows |
---|
1917 | ambiguous situations in which a client may send "Expect: 100- |
---|
1918 | continue" without receiving either a 417 (Expectation Failed) status |
---|
1919 | or a 100 (Continue) status. Therefore, when a client sends this |
---|
1920 | header field to an origin server (possibly via a proxy) from which it |
---|
1921 | has never seen a 100 (Continue) status, the client SHOULD NOT wait |
---|
1922 | for an indefinite period before sending the request body. |
---|
1923 | |
---|
1924 | Requirements for HTTP/1.1 origin servers: |
---|
1925 | |
---|
1926 | o Upon receiving a request which includes an Expect request-header |
---|
1927 | field with the "100-continue" expectation, an origin server MUST |
---|
1928 | either respond with 100 (Continue) status and continue to read |
---|
1929 | from the input stream, or respond with a final status code. The |
---|
1930 | origin server MUST NOT wait for the request body before sending |
---|
1931 | the 100 (Continue) response. If it responds with a final status |
---|
1932 | code, it MAY close the transport connection or it MAY continue to |
---|
1933 | read and discard the rest of the request. It MUST NOT perform the |
---|
1934 | requested method if it returns a final status code. |
---|
1935 | |
---|
1936 | o An origin server SHOULD NOT send a 100 (Continue) response if the |
---|
1937 | request message does not include an Expect request-header field |
---|
1938 | with the "100-continue" expectation, and MUST NOT send a 100 |
---|
1939 | (Continue) response if such a request comes from an HTTP/1.0 (or |
---|
1940 | earlier) client. There is an exception to this rule: for |
---|
1941 | compatibility with RFC 2068, a server MAY send a 100 (Continue) |
---|
1942 | status in response to an HTTP/1.1 PUT or POST request that does |
---|
1943 | not include an Expect request-header field with the "100-continue" |
---|
1944 | expectation. This exception, the purpose of which is to minimize |
---|
1945 | any client processing delays associated with an undeclared wait |
---|
1946 | for 100 (Continue) status, applies only to HTTP/1.1 requests, and |
---|
1947 | not to requests with any other HTTP-version value. |
---|
1948 | |
---|
1949 | o An origin server MAY omit a 100 (Continue) response if it has |
---|
1950 | already received some or all of the request body for the |
---|
1951 | corresponding request. |
---|
1952 | |
---|
1953 | o An origin server that sends a 100 (Continue) response MUST |
---|
1954 | ultimately send a final status code, once the request body is |
---|
1955 | received and processed, unless it terminates the transport |
---|
1956 | |
---|
1957 | |
---|
1958 | |
---|
1959 | Fielding, et al. Expires June 22, 2008 [Page 35] |
---|
1960 | |
---|
1961 | Internet-Draft HTTP/1.1 December 2007 |
---|
1962 | |
---|
1963 | |
---|
1964 | connection prematurely. |
---|
1965 | |
---|
1966 | o If an origin server receives a request that does not include an |
---|
1967 | Expect request-header field with the "100-continue" expectation, |
---|
1968 | the request includes a request body, and the server responds with |
---|
1969 | a final status code before reading the entire request body from |
---|
1970 | the transport connection, then the server SHOULD NOT close the |
---|
1971 | transport connection until it has read the entire request, or |
---|
1972 | until the client closes the connection. Otherwise, the client |
---|
1973 | might not reliably receive the response message. However, this |
---|
1974 | requirement is not be construed as preventing a server from |
---|
1975 | defending itself against denial-of-service attacks, or from badly |
---|
1976 | broken client implementations. |
---|
1977 | |
---|
1978 | Requirements for HTTP/1.1 proxies: |
---|
1979 | |
---|
1980 | o If a proxy receives a request that includes an Expect request- |
---|
1981 | header field with the "100-continue" expectation, and the proxy |
---|
1982 | either knows that the next-hop server complies with HTTP/1.1 or |
---|
1983 | higher, or does not know the HTTP version of the next-hop server, |
---|
1984 | it MUST forward the request, including the Expect header field. |
---|
1985 | |
---|
1986 | o If the proxy knows that the version of the next-hop server is |
---|
1987 | HTTP/1.0 or lower, it MUST NOT forward the request, and it MUST |
---|
1988 | respond with a 417 (Expectation Failed) status. |
---|
1989 | |
---|
1990 | o Proxies SHOULD maintain a cache recording the HTTP version numbers |
---|
1991 | received from recently-referenced next-hop servers. |
---|
1992 | |
---|
1993 | o A proxy MUST NOT forward a 100 (Continue) response if the request |
---|
1994 | message was received from an HTTP/1.0 (or earlier) client and did |
---|
1995 | not include an Expect request-header field with the "100-continue" |
---|
1996 | expectation. This requirement overrides the general rule for |
---|
1997 | forwarding of 1xx responses (see Section 9.1 of [Part2]). |
---|
1998 | |
---|
1999 | 7.2.4. Client Behavior if Server Prematurely Closes Connection |
---|
2000 | |
---|
2001 | If an HTTP/1.1 client sends a request which includes a request body, |
---|
2002 | but which does not include an Expect request-header field with the |
---|
2003 | "100-continue" expectation, and if the client is not directly |
---|
2004 | connected to an HTTP/1.1 origin server, and if the client sees the |
---|
2005 | connection close before receiving any status from the server, the |
---|
2006 | client SHOULD retry the request. If the client does retry this |
---|
2007 | request, it MAY use the following "binary exponential backoff" |
---|
2008 | algorithm to be assured of obtaining a reliable response: |
---|
2009 | |
---|
2010 | 1. Initiate a new connection to the server |
---|
2011 | |
---|
2012 | |
---|
2013 | |
---|
2014 | |
---|
2015 | Fielding, et al. Expires June 22, 2008 [Page 36] |
---|
2016 | |
---|
2017 | Internet-Draft HTTP/1.1 December 2007 |
---|
2018 | |
---|
2019 | |
---|
2020 | 2. Transmit the request-headers |
---|
2021 | |
---|
2022 | 3. Initialize a variable R to the estimated round-trip time to the |
---|
2023 | server (e.g., based on the time it took to establish the |
---|
2024 | connection), or to a constant value of 5 seconds if the round- |
---|
2025 | trip time is not available. |
---|
2026 | |
---|
2027 | 4. Compute T = R * (2**N), where N is the number of previous retries |
---|
2028 | of this request. |
---|
2029 | |
---|
2030 | 5. Wait either for an error response from the server, or for T |
---|
2031 | seconds (whichever comes first) |
---|
2032 | |
---|
2033 | 6. If no error response is received, after T seconds transmit the |
---|
2034 | body of the request. |
---|
2035 | |
---|
2036 | 7. If client sees that the connection is closed prematurely, repeat |
---|
2037 | from step 1 until the request is accepted, an error response is |
---|
2038 | received, or the user becomes impatient and terminates the retry |
---|
2039 | process. |
---|
2040 | |
---|
2041 | If at any point an error status is received, the client |
---|
2042 | |
---|
2043 | o SHOULD NOT continue and |
---|
2044 | |
---|
2045 | o SHOULD close the connection if it has not completed sending the |
---|
2046 | request message. |
---|
2047 | |
---|
2048 | |
---|
2049 | 8. Header Field Definitions |
---|
2050 | |
---|
2051 | This section defines the syntax and semantics of all standard |
---|
2052 | HTTP/1.1 header fields. For entity-header fields, both sender and |
---|
2053 | recipient refer to either the client or the server, depending on who |
---|
2054 | sends and who receives the entity. |
---|
2055 | |
---|
2056 | 8.1. Connection |
---|
2057 | |
---|
2058 | The Connection general-header field allows the sender to specify |
---|
2059 | options that are desired for that particular connection and MUST NOT |
---|
2060 | be communicated by proxies over further connections. |
---|
2061 | |
---|
2062 | The Connection header has the following grammar: |
---|
2063 | |
---|
2064 | Connection = "Connection" ":" 1#(connection-token) |
---|
2065 | connection-token = token |
---|
2066 | |
---|
2067 | HTTP/1.1 proxies MUST parse the Connection header field before a |
---|
2068 | |
---|
2069 | |
---|
2070 | |
---|
2071 | Fielding, et al. Expires June 22, 2008 [Page 37] |
---|
2072 | |
---|
2073 | Internet-Draft HTTP/1.1 December 2007 |
---|
2074 | |
---|
2075 | |
---|
2076 | message is forwarded and, for each connection-token in this field, |
---|
2077 | remove any header field(s) from the message with the same name as the |
---|
2078 | connection-token. Connection options are signaled by the presence of |
---|
2079 | a connection-token in the Connection header field, not by any |
---|
2080 | corresponding additional header field(s), since the additional header |
---|
2081 | field may not be sent if there are no parameters associated with that |
---|
2082 | connection option. |
---|
2083 | |
---|
2084 | Message headers listed in the Connection header MUST NOT include end- |
---|
2085 | to-end headers, such as Cache-Control. |
---|
2086 | |
---|
2087 | HTTP/1.1 defines the "close" connection option for the sender to |
---|
2088 | signal that the connection will be closed after completion of the |
---|
2089 | response. For example, |
---|
2090 | |
---|
2091 | Connection: close |
---|
2092 | |
---|
2093 | in either the request or the response header fields indicates that |
---|
2094 | the connection SHOULD NOT be considered `persistent' (Section 7.1) |
---|
2095 | after the current request/response is complete. |
---|
2096 | |
---|
2097 | HTTP/1.1 applications that do not support persistent connections MUST |
---|
2098 | include the "close" connection option in every message. |
---|
2099 | |
---|
2100 | A system receiving an HTTP/1.0 (or lower-version) message that |
---|
2101 | includes a Connection header MUST, for each connection-token in this |
---|
2102 | field, remove and ignore any header field(s) from the message with |
---|
2103 | the same name as the connection-token. This protects against |
---|
2104 | mistaken forwarding of such header fields by pre-HTTP/1.1 proxies. |
---|
2105 | See Appendix D.2. |
---|
2106 | |
---|
2107 | 8.2. Content-Length |
---|
2108 | |
---|
2109 | The Content-Length entity-header field indicates the size of the |
---|
2110 | entity-body, in decimal number of OCTETs, sent to the recipient or, |
---|
2111 | in the case of the HEAD method, the size of the entity-body that |
---|
2112 | would have been sent had the request been a GET. |
---|
2113 | |
---|
2114 | Content-Length = "Content-Length" ":" 1*DIGIT |
---|
2115 | |
---|
2116 | An example is |
---|
2117 | |
---|
2118 | Content-Length: 3495 |
---|
2119 | |
---|
2120 | Applications SHOULD use this field to indicate the transfer-length of |
---|
2121 | the message-body, unless this is prohibited by the rules in |
---|
2122 | Section 4.4. |
---|
2123 | |
---|
2124 | |
---|
2125 | |
---|
2126 | |
---|
2127 | Fielding, et al. Expires June 22, 2008 [Page 38] |
---|
2128 | |
---|
2129 | Internet-Draft HTTP/1.1 December 2007 |
---|
2130 | |
---|
2131 | |
---|
2132 | Any Content-Length greater than or equal to zero is a valid value. |
---|
2133 | Section 4.4 describes how to determine the length of a message-body |
---|
2134 | if a Content-Length is not given. |
---|
2135 | |
---|
2136 | Note that the meaning of this field is significantly different from |
---|
2137 | the corresponding definition in MIME, where it is an optional field |
---|
2138 | used within the "message/external-body" content-type. In HTTP, it |
---|
2139 | SHOULD be sent whenever the message's length can be determined prior |
---|
2140 | to being transferred, unless this is prohibited by the rules in |
---|
2141 | Section 4.4. |
---|
2142 | |
---|
2143 | 8.3. Date |
---|
2144 | |
---|
2145 | The Date general-header field represents the date and time at which |
---|
2146 | the message was originated, having the same semantics as orig-date in |
---|
2147 | RFC 822. The field value is an HTTP-date, as described in |
---|
2148 | Section 3.3.1; it MUST be sent in RFC 1123 [RFC1123]-date format. |
---|
2149 | |
---|
2150 | Date = "Date" ":" HTTP-date |
---|
2151 | |
---|
2152 | An example is |
---|
2153 | |
---|
2154 | Date: Tue, 15 Nov 1994 08:12:31 GMT |
---|
2155 | |
---|
2156 | Origin servers MUST include a Date header field in all responses, |
---|
2157 | except in these cases: |
---|
2158 | |
---|
2159 | 1. If the response status code is 100 (Continue) or 101 (Switching |
---|
2160 | Protocols), the response MAY include a Date header field, at the |
---|
2161 | server's option. |
---|
2162 | |
---|
2163 | 2. If the response status code conveys a server error, e.g. 500 |
---|
2164 | (Internal Server Error) or 503 (Service Unavailable), and it is |
---|
2165 | inconvenient or impossible to generate a valid Date. |
---|
2166 | |
---|
2167 | 3. If the server does not have a clock that can provide a reasonable |
---|
2168 | approximation of the current time, its responses MUST NOT include |
---|
2169 | a Date header field. In this case, the rules in Section 8.3.1 |
---|
2170 | MUST be followed. |
---|
2171 | |
---|
2172 | A received message that does not have a Date header field MUST be |
---|
2173 | assigned one by the recipient if the message will be cached by that |
---|
2174 | recipient or gatewayed via a protocol which requires a Date. An HTTP |
---|
2175 | implementation without a clock MUST NOT cache responses without |
---|
2176 | revalidating them on every use. An HTTP cache, especially a shared |
---|
2177 | cache, SHOULD use a mechanism, such as NTP [RFC1305], to synchronize |
---|
2178 | its clock with a reliable external standard. |
---|
2179 | |
---|
2180 | |
---|
2181 | |
---|
2182 | |
---|
2183 | Fielding, et al. Expires June 22, 2008 [Page 39] |
---|
2184 | |
---|
2185 | Internet-Draft HTTP/1.1 December 2007 |
---|
2186 | |
---|
2187 | |
---|
2188 | Clients SHOULD only send a Date header field in messages that include |
---|
2189 | an entity-body, as in the case of the PUT and POST requests, and even |
---|
2190 | then it is optional. A client without a clock MUST NOT send a Date |
---|
2191 | header field in a request. |
---|
2192 | |
---|
2193 | The HTTP-date sent in a Date header SHOULD NOT represent a date and |
---|
2194 | time subsequent to the generation of the message. It SHOULD |
---|
2195 | represent the best available approximation of the date and time of |
---|
2196 | message generation, unless the implementation has no means of |
---|
2197 | generating a reasonably accurate date and time. In theory, the date |
---|
2198 | ought to represent the moment just before the entity is generated. |
---|
2199 | In practice, the date can be generated at any time during the message |
---|
2200 | origination without affecting its semantic value. |
---|
2201 | |
---|
2202 | 8.3.1. Clockless Origin Server Operation |
---|
2203 | |
---|
2204 | Some origin server implementations might not have a clock available. |
---|
2205 | An origin server without a clock MUST NOT assign Expires or Last- |
---|
2206 | Modified values to a response, unless these values were associated |
---|
2207 | with the resource by a system or user with a reliable clock. It MAY |
---|
2208 | assign an Expires value that is known, at or before server |
---|
2209 | configuration time, to be in the past (this allows "pre-expiration" |
---|
2210 | of responses without storing separate Expires values for each |
---|
2211 | resource). |
---|
2212 | |
---|
2213 | 8.4. Host |
---|
2214 | |
---|
2215 | The Host request-header field specifies the Internet host and port |
---|
2216 | number of the resource being requested, as obtained from the original |
---|
2217 | URI given by the user or referring resource (generally an HTTP URL, |
---|
2218 | as described in Section 3.2.2). The Host field value MUST represent |
---|
2219 | the naming authority of the origin server or gateway given by the |
---|
2220 | original URL. This allows the origin server or gateway to |
---|
2221 | differentiate between internally-ambiguous URLs, such as the root "/" |
---|
2222 | URL of a server for multiple host names on a single IP address. |
---|
2223 | |
---|
2224 | Host = "Host" ":" host [ ":" port ] ; Section 3.2.2 |
---|
2225 | |
---|
2226 | A "host" without any trailing port information implies the default |
---|
2227 | port for the service requested (e.g., "80" for an HTTP URL). For |
---|
2228 | example, a request on the origin server for |
---|
2229 | <http://www.w3.org/pub/WWW/> would properly include: |
---|
2230 | |
---|
2231 | GET /pub/WWW/ HTTP/1.1 |
---|
2232 | Host: www.w3.org |
---|
2233 | |
---|
2234 | A client MUST include a Host header field in all HTTP/1.1 request |
---|
2235 | messages . If the requested URI does not include an Internet host |
---|
2236 | |
---|
2237 | |
---|
2238 | |
---|
2239 | Fielding, et al. Expires June 22, 2008 [Page 40] |
---|
2240 | |
---|
2241 | Internet-Draft HTTP/1.1 December 2007 |
---|
2242 | |
---|
2243 | |
---|
2244 | name for the service being requested, then the Host header field MUST |
---|
2245 | be given with an empty value. An HTTP/1.1 proxy MUST ensure that any |
---|
2246 | request message it forwards does contain an appropriate Host header |
---|
2247 | field that identifies the service being requested by the proxy. All |
---|
2248 | Internet-based HTTP/1.1 servers MUST respond with a 400 (Bad Request) |
---|
2249 | status code to any HTTP/1.1 request message which lacks a Host header |
---|
2250 | field. |
---|
2251 | |
---|
2252 | See sections 5.2 and D.1.1 for other requirements relating to Host. |
---|
2253 | |
---|
2254 | 8.5. TE |
---|
2255 | |
---|
2256 | The TE request-header field indicates what extension transfer-codings |
---|
2257 | it is willing to accept in the response and whether or not it is |
---|
2258 | willing to accept trailer fields in a chunked transfer-coding. Its |
---|
2259 | value may consist of the keyword "trailers" and/or a comma-separated |
---|
2260 | list of extension transfer-coding names with optional accept |
---|
2261 | parameters (as described in Section 3.4). |
---|
2262 | |
---|
2263 | TE = "TE" ":" #( t-codings ) |
---|
2264 | t-codings = "trailers" | ( transfer-extension [ accept-params ] ) |
---|
2265 | |
---|
2266 | The presence of the keyword "trailers" indicates that the client is |
---|
2267 | willing to accept trailer fields in a chunked transfer-coding, as |
---|
2268 | defined in Section 3.4.1. This keyword is reserved for use with |
---|
2269 | transfer-coding values even though it does not itself represent a |
---|
2270 | transfer-coding. |
---|
2271 | |
---|
2272 | Examples of its use are: |
---|
2273 | |
---|
2274 | TE: deflate |
---|
2275 | TE: |
---|
2276 | TE: trailers, deflate;q=0.5 |
---|
2277 | |
---|
2278 | The TE header field only applies to the immediate connection. |
---|
2279 | Therefore, the keyword MUST be supplied within a Connection header |
---|
2280 | field (Section 8.1) whenever TE is present in an HTTP/1.1 message. |
---|
2281 | |
---|
2282 | A server tests whether a transfer-coding is acceptable, according to |
---|
2283 | a TE field, using these rules: |
---|
2284 | |
---|
2285 | 1. The "chunked" transfer-coding is always acceptable. If the |
---|
2286 | keyword "trailers" is listed, the client indicates that it is |
---|
2287 | willing to accept trailer fields in the chunked response on |
---|
2288 | behalf of itself and any downstream clients. The implication is |
---|
2289 | that, if given, the client is stating that either all downstream |
---|
2290 | clients are willing to accept trailer fields in the forwarded |
---|
2291 | response, or that it will attempt to buffer the response on |
---|
2292 | |
---|
2293 | |
---|
2294 | |
---|
2295 | Fielding, et al. Expires June 22, 2008 [Page 41] |
---|
2296 | |
---|
2297 | Internet-Draft HTTP/1.1 December 2007 |
---|
2298 | |
---|
2299 | |
---|
2300 | behalf of downstream recipients. |
---|
2301 | |
---|
2302 | Note: HTTP/1.1 does not define any means to limit the size of a |
---|
2303 | chunked response such that a client can be assured of buffering |
---|
2304 | the entire response. |
---|
2305 | |
---|
2306 | 2. If the transfer-coding being tested is one of the transfer- |
---|
2307 | codings listed in the TE field, then it is acceptable unless it |
---|
2308 | is accompanied by a qvalue of 0. (As defined in Section 2.4 of |
---|
2309 | [Part3], a qvalue of 0 means "not acceptable.") |
---|
2310 | |
---|
2311 | 3. If multiple transfer-codings are acceptable, then the acceptable |
---|
2312 | transfer-coding with the highest non-zero qvalue is preferred. |
---|
2313 | The "chunked" transfer-coding always has a qvalue of 1. |
---|
2314 | |
---|
2315 | If the TE field-value is empty or if no TE field is present, the only |
---|
2316 | transfer-coding is "chunked". A message with no transfer-coding is |
---|
2317 | always acceptable. |
---|
2318 | |
---|
2319 | 8.6. Trailer |
---|
2320 | |
---|
2321 | The Trailer general field value indicates that the given set of |
---|
2322 | header fields is present in the trailer of a message encoded with |
---|
2323 | chunked transfer-coding. |
---|
2324 | |
---|
2325 | Trailer = "Trailer" ":" 1#field-name |
---|
2326 | |
---|
2327 | An HTTP/1.1 message SHOULD include a Trailer header field in a |
---|
2328 | message using chunked transfer-coding with a non-empty trailer. |
---|
2329 | Doing so allows the recipient to know which header fields to expect |
---|
2330 | in the trailer. |
---|
2331 | |
---|
2332 | If no Trailer header field is present, the trailer SHOULD NOT include |
---|
2333 | any header fields. See Section 3.4.1 for restrictions on the use of |
---|
2334 | trailer fields in a "chunked" transfer-coding. |
---|
2335 | |
---|
2336 | Message header fields listed in the Trailer header field MUST NOT |
---|
2337 | include the following header fields: |
---|
2338 | |
---|
2339 | o Transfer-Encoding |
---|
2340 | |
---|
2341 | o Content-Length |
---|
2342 | |
---|
2343 | o Trailer |
---|
2344 | |
---|
2345 | |
---|
2346 | |
---|
2347 | |
---|
2348 | |
---|
2349 | |
---|
2350 | |
---|
2351 | Fielding, et al. Expires June 22, 2008 [Page 42] |
---|
2352 | |
---|
2353 | Internet-Draft HTTP/1.1 December 2007 |
---|
2354 | |
---|
2355 | |
---|
2356 | 8.7. Transfer-Encoding |
---|
2357 | |
---|
2358 | The Transfer-Encoding general-header field indicates what (if any) |
---|
2359 | type of transformation has been applied to the message body in order |
---|
2360 | to safely transfer it between the sender and the recipient. This |
---|
2361 | differs from the content-coding in that the transfer-coding is a |
---|
2362 | property of the message, not of the entity. |
---|
2363 | |
---|
2364 | Transfer-Encoding = "Transfer-Encoding" ":" 1#transfer-coding |
---|
2365 | |
---|
2366 | Transfer-codings are defined in Section 3.4. An example is: |
---|
2367 | |
---|
2368 | Transfer-Encoding: chunked |
---|
2369 | |
---|
2370 | If multiple encodings have been applied to an entity, the transfer- |
---|
2371 | codings MUST be listed in the order in which they were applied. |
---|
2372 | Additional information about the encoding parameters MAY be provided |
---|
2373 | by other entity-header fields not defined by this specification. |
---|
2374 | |
---|
2375 | Many older HTTP/1.0 applications do not understand the Transfer- |
---|
2376 | Encoding header. |
---|
2377 | |
---|
2378 | 8.8. Upgrade |
---|
2379 | |
---|
2380 | The Upgrade general-header allows the client to specify what |
---|
2381 | additional communication protocols it supports and would like to use |
---|
2382 | if the server finds it appropriate to switch protocols. The server |
---|
2383 | MUST use the Upgrade header field within a 101 (Switching Protocols) |
---|
2384 | response to indicate which protocol(s) are being switched. |
---|
2385 | |
---|
2386 | Upgrade = "Upgrade" ":" 1#product |
---|
2387 | |
---|
2388 | For example, |
---|
2389 | |
---|
2390 | Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11 |
---|
2391 | |
---|
2392 | The Upgrade header field is intended to provide a simple mechanism |
---|
2393 | for transition from HTTP/1.1 to some other, incompatible protocol. |
---|
2394 | It does so by allowing the client to advertise its desire to use |
---|
2395 | another protocol, such as a later version of HTTP with a higher major |
---|
2396 | version number, even though the current request has been made using |
---|
2397 | HTTP/1.1. This eases the difficult transition between incompatible |
---|
2398 | protocols by allowing the client to initiate a request in the more |
---|
2399 | commonly supported protocol while indicating to the server that it |
---|
2400 | would like to use a "better" protocol if available (where "better" is |
---|
2401 | determined by the server, possibly according to the nature of the |
---|
2402 | method and/or resource being requested). |
---|
2403 | |
---|
2404 | |
---|
2405 | |
---|
2406 | |
---|
2407 | Fielding, et al. Expires June 22, 2008 [Page 43] |
---|
2408 | |
---|
2409 | Internet-Draft HTTP/1.1 December 2007 |
---|
2410 | |
---|
2411 | |
---|
2412 | The Upgrade header field only applies to switching application-layer |
---|
2413 | protocols upon the existing transport-layer connection. Upgrade |
---|
2414 | cannot be used to insist on a protocol change; its acceptance and use |
---|
2415 | by the server is optional. The capabilities and nature of the |
---|
2416 | application-layer communication after the protocol change is entirely |
---|
2417 | dependent upon the new protocol chosen, although the first action |
---|
2418 | after changing the protocol MUST be a response to the initial HTTP |
---|
2419 | request containing the Upgrade header field. |
---|
2420 | |
---|
2421 | The Upgrade header field only applies to the immediate connection. |
---|
2422 | Therefore, the upgrade keyword MUST be supplied within a Connection |
---|
2423 | header field (Section 8.1) whenever Upgrade is present in an HTTP/1.1 |
---|
2424 | message. |
---|
2425 | |
---|
2426 | The Upgrade header field cannot be used to indicate a switch to a |
---|
2427 | protocol on a different connection. For that purpose, it is more |
---|
2428 | appropriate to use a 301, 302, 303, or 305 redirection response. |
---|
2429 | |
---|
2430 | This specification only defines the protocol name "HTTP" for use by |
---|
2431 | the family of Hypertext Transfer Protocols, as defined by the HTTP |
---|
2432 | version rules of Section 3.1 and future updates to this |
---|
2433 | specification. Any token can be used as a protocol name; however, it |
---|
2434 | will only be useful if both the client and server associate the name |
---|
2435 | with the same protocol. |
---|
2436 | |
---|
2437 | 8.9. Via |
---|
2438 | |
---|
2439 | The Via general-header field MUST be used by gateways and proxies to |
---|
2440 | indicate the intermediate protocols and recipients between the user |
---|
2441 | agent and the server on requests, and between the origin server and |
---|
2442 | the client on responses. It is analogous to the "Received" field of |
---|
2443 | RFC 822 [RFC822] and is intended to be used for tracking message |
---|
2444 | forwards, avoiding request loops, and identifying the protocol |
---|
2445 | capabilities of all senders along the request/response chain. |
---|
2446 | |
---|
2447 | Via = "Via" ":" 1#( received-protocol received-by [ comment ] ) |
---|
2448 | received-protocol = [ protocol-name "/" ] protocol-version |
---|
2449 | protocol-name = token |
---|
2450 | protocol-version = token |
---|
2451 | received-by = ( host [ ":" port ] ) | pseudonym |
---|
2452 | pseudonym = token |
---|
2453 | |
---|
2454 | The received-protocol indicates the protocol version of the message |
---|
2455 | received by the server or client along each segment of the request/ |
---|
2456 | response chain. The received-protocol version is appended to the Via |
---|
2457 | field value when the message is forwarded so that information about |
---|
2458 | the protocol capabilities of upstream applications remains visible to |
---|
2459 | all recipients. |
---|
2460 | |
---|
2461 | |
---|
2462 | |
---|
2463 | Fielding, et al. Expires June 22, 2008 [Page 44] |
---|
2464 | |
---|
2465 | Internet-Draft HTTP/1.1 December 2007 |
---|
2466 | |
---|
2467 | |
---|
2468 | The protocol-name is optional if and only if it would be "HTTP". The |
---|
2469 | received-by field is normally the host and optional port number of a |
---|
2470 | recipient server or client that subsequently forwarded the message. |
---|
2471 | However, if the real host is considered to be sensitive information, |
---|
2472 | it MAY be replaced by a pseudonym. If the port is not given, it MAY |
---|
2473 | be assumed to be the default port of the received-protocol. |
---|
2474 | |
---|
2475 | Multiple Via field values represents each proxy or gateway that has |
---|
2476 | forwarded the message. Each recipient MUST append its information |
---|
2477 | such that the end result is ordered according to the sequence of |
---|
2478 | forwarding applications. |
---|
2479 | |
---|
2480 | Comments MAY be used in the Via header field to identify the software |
---|
2481 | of the recipient proxy or gateway, analogous to the User-Agent and |
---|
2482 | Server header fields. However, all comments in the Via field are |
---|
2483 | optional and MAY be removed by any recipient prior to forwarding the |
---|
2484 | message. |
---|
2485 | |
---|
2486 | For example, a request message could be sent from an HTTP/1.0 user |
---|
2487 | agent to an internal proxy code-named "fred", which uses HTTP/1.1 to |
---|
2488 | forward the request to a public proxy at nowhere.com, which completes |
---|
2489 | the request by forwarding it to the origin server at www.ics.uci.edu. |
---|
2490 | The request received by www.ics.uci.edu would then have the following |
---|
2491 | Via header field: |
---|
2492 | |
---|
2493 | Via: 1.0 fred, 1.1 nowhere.com (Apache/1.1) |
---|
2494 | |
---|
2495 | Proxies and gateways used as a portal through a network firewall |
---|
2496 | SHOULD NOT, by default, forward the names and ports of hosts within |
---|
2497 | the firewall region. This information SHOULD only be propagated if |
---|
2498 | explicitly enabled. If not enabled, the received-by host of any host |
---|
2499 | behind the firewall SHOULD be replaced by an appropriate pseudonym |
---|
2500 | for that host. |
---|
2501 | |
---|
2502 | For organizations that have strong privacy requirements for hiding |
---|
2503 | internal structures, a proxy MAY combine an ordered subsequence of |
---|
2504 | Via header field entries with identical received-protocol values into |
---|
2505 | a single such entry. For example, |
---|
2506 | |
---|
2507 | Via: 1.0 ricky, 1.1 ethel, 1.1 fred, 1.0 lucy |
---|
2508 | |
---|
2509 | could be collapsed to |
---|
2510 | |
---|
2511 | Via: 1.0 ricky, 1.1 mertz, 1.0 lucy |
---|
2512 | |
---|
2513 | Applications SHOULD NOT combine multiple entries unless they are all |
---|
2514 | under the same organizational control and the hosts have already been |
---|
2515 | replaced by pseudonyms. Applications MUST NOT combine entries which |
---|
2516 | |
---|
2517 | |
---|
2518 | |
---|
2519 | Fielding, et al. Expires June 22, 2008 [Page 45] |
---|
2520 | |
---|
2521 | Internet-Draft HTTP/1.1 December 2007 |
---|
2522 | |
---|
2523 | |
---|
2524 | have different received-protocol values. |
---|
2525 | |
---|
2526 | |
---|
2527 | 9. IANA Considerations |
---|
2528 | |
---|
2529 | TBD. |
---|
2530 | |
---|
2531 | |
---|
2532 | 10. Security Considerations |
---|
2533 | |
---|
2534 | This section is meant to inform application developers, information |
---|
2535 | providers, and users of the security limitations in HTTP/1.1 as |
---|
2536 | described by this document. The discussion does not include |
---|
2537 | definitive solutions to the problems revealed, though it does make |
---|
2538 | some suggestions for reducing security risks. |
---|
2539 | |
---|
2540 | 10.1. Personal Information |
---|
2541 | |
---|
2542 | HTTP clients are often privy to large amounts of personal information |
---|
2543 | (e.g. the user's name, location, mail address, passwords, encryption |
---|
2544 | keys, etc.), and SHOULD be very careful to prevent unintentional |
---|
2545 | leakage of this information via the HTTP protocol to other sources. |
---|
2546 | We very strongly recommend that a convenient interface be provided |
---|
2547 | for the user to control dissemination of such information, and that |
---|
2548 | designers and implementors be particularly careful in this area. |
---|
2549 | History shows that errors in this area often create serious security |
---|
2550 | and/or privacy problems and generate highly adverse publicity for the |
---|
2551 | implementor's company. |
---|
2552 | |
---|
2553 | 10.2. Abuse of Server Log Information |
---|
2554 | |
---|
2555 | A server is in the position to save personal data about a user's |
---|
2556 | requests which might identify their reading patterns or subjects of |
---|
2557 | interest. This information is clearly confidential in nature and its |
---|
2558 | handling can be constrained by law in certain countries. People |
---|
2559 | using the HTTP protocol to provide data are responsible for ensuring |
---|
2560 | that such material is not distributed without the permission of any |
---|
2561 | individuals that are identifiable by the published results. |
---|
2562 | |
---|
2563 | 10.3. Attacks Based On File and Path Names |
---|
2564 | |
---|
2565 | Implementations of HTTP origin servers SHOULD be careful to restrict |
---|
2566 | the documents returned by HTTP requests to be only those that were |
---|
2567 | intended by the server administrators. If an HTTP server translates |
---|
2568 | HTTP URIs directly into file system calls, the server MUST take |
---|
2569 | special care not to serve files that were not intended to be |
---|
2570 | delivered to HTTP clients. For example, UNIX, Microsoft Windows, and |
---|
2571 | other operating systems use ".." as a path component to indicate a |
---|
2572 | |
---|
2573 | |
---|
2574 | |
---|
2575 | Fielding, et al. Expires June 22, 2008 [Page 46] |
---|
2576 | |
---|
2577 | Internet-Draft HTTP/1.1 December 2007 |
---|
2578 | |
---|
2579 | |
---|
2580 | directory level above the current one. On such a system, an HTTP |
---|
2581 | server MUST disallow any such construct in the Request-URI if it |
---|
2582 | would otherwise allow access to a resource outside those intended to |
---|
2583 | be accessible via the HTTP server. Similarly, files intended for |
---|
2584 | reference only internally to the server (such as access control |
---|
2585 | files, configuration files, and script code) MUST be protected from |
---|
2586 | inappropriate retrieval, since they might contain sensitive |
---|
2587 | information. Experience has shown that minor bugs in such HTTP |
---|
2588 | server implementations have turned into security risks. |
---|
2589 | |
---|
2590 | 10.4. DNS Spoofing |
---|
2591 | |
---|
2592 | Clients using HTTP rely heavily on the Domain Name Service, and are |
---|
2593 | thus generally prone to security attacks based on the deliberate mis- |
---|
2594 | association of IP addresses and DNS names. Clients need to be |
---|
2595 | cautious in assuming the continuing validity of an IP number/DNS name |
---|
2596 | association. |
---|
2597 | |
---|
2598 | In particular, HTTP clients SHOULD rely on their name resolver for |
---|
2599 | confirmation of an IP number/DNS name association, rather than |
---|
2600 | caching the result of previous host name lookups. Many platforms |
---|
2601 | already can cache host name lookups locally when appropriate, and |
---|
2602 | they SHOULD be configured to do so. It is proper for these lookups |
---|
2603 | to be cached, however, only when the TTL (Time To Live) information |
---|
2604 | reported by the name server makes it likely that the cached |
---|
2605 | information will remain useful. |
---|
2606 | |
---|
2607 | If HTTP clients cache the results of host name lookups in order to |
---|
2608 | achieve a performance improvement, they MUST observe the TTL |
---|
2609 | information reported by DNS. |
---|
2610 | |
---|
2611 | If HTTP clients do not observe this rule, they could be spoofed when |
---|
2612 | a previously-accessed server's IP address changes. As network |
---|
2613 | renumbering is expected to become increasingly common [RFC1900], the |
---|
2614 | possibility of this form of attack will grow. Observing this |
---|
2615 | requirement thus reduces this potential security vulnerability. |
---|
2616 | |
---|
2617 | This requirement also improves the load-balancing behavior of clients |
---|
2618 | for replicated servers using the same DNS name and reduces the |
---|
2619 | likelihood of a user's experiencing failure in accessing sites which |
---|
2620 | use that strategy. |
---|
2621 | |
---|
2622 | 10.5. Proxies and Caching |
---|
2623 | |
---|
2624 | By their very nature, HTTP proxies are men-in-the-middle, and |
---|
2625 | represent an opportunity for man-in-the-middle attacks. Compromise |
---|
2626 | of the systems on which the proxies run can result in serious |
---|
2627 | security and privacy problems. Proxies have access to security- |
---|
2628 | |
---|
2629 | |
---|
2630 | |
---|
2631 | Fielding, et al. Expires June 22, 2008 [Page 47] |
---|
2632 | |
---|
2633 | Internet-Draft HTTP/1.1 December 2007 |
---|
2634 | |
---|
2635 | |
---|
2636 | related information, personal information about individual users and |
---|
2637 | organizations, and proprietary information belonging to users and |
---|
2638 | content providers. A compromised proxy, or a proxy implemented or |
---|
2639 | configured without regard to security and privacy considerations, |
---|
2640 | might be used in the commission of a wide range of potential attacks. |
---|
2641 | |
---|
2642 | Proxy operators should protect the systems on which proxies run as |
---|
2643 | they would protect any system that contains or transports sensitive |
---|
2644 | information. In particular, log information gathered at proxies |
---|
2645 | often contains highly sensitive personal information, and/or |
---|
2646 | information about organizations. Log information should be carefully |
---|
2647 | guarded, and appropriate guidelines for use developed and followed. |
---|
2648 | (Section 10.2). |
---|
2649 | |
---|
2650 | Proxy implementors should consider the privacy and security |
---|
2651 | implications of their design and coding decisions, and of the |
---|
2652 | configuration options they provide to proxy operators (especially the |
---|
2653 | default configuration). |
---|
2654 | |
---|
2655 | Users of a proxy need to be aware that they are no trustworthier than |
---|
2656 | the people who run the proxy; HTTP itself cannot solve this problem. |
---|
2657 | |
---|
2658 | The judicious use of cryptography, when appropriate, may suffice to |
---|
2659 | protect against a broad range of security and privacy attacks. Such |
---|
2660 | cryptography is beyond the scope of the HTTP/1.1 specification. |
---|
2661 | |
---|
2662 | 10.6. Denial of Service Attacks on Proxies |
---|
2663 | |
---|
2664 | They exist. They are hard to defend against. Research continues. |
---|
2665 | Beware. |
---|
2666 | |
---|
2667 | |
---|
2668 | 11. Acknowledgments |
---|
2669 | |
---|
2670 | This specification makes heavy use of the augmented BNF and generic |
---|
2671 | constructs defined by David H. Crocker for RFC 822 [RFC822]. |
---|
2672 | Similarly, it reuses many of the definitions provided by Nathaniel |
---|
2673 | Borenstein and Ned Freed for MIME [RFC2045]. We hope that their |
---|
2674 | inclusion in this specification will help reduce past confusion over |
---|
2675 | the relationship between HTTP and Internet mail message formats. |
---|
2676 | |
---|
2677 | The HTTP protocol has evolved considerably over the years. It has |
---|
2678 | benefited from a large and active developer community--the many |
---|
2679 | people who have participated on the www-talk mailing list--and it is |
---|
2680 | that community which has been most responsible for the success of |
---|
2681 | HTTP and of the World-Wide Web in general. Marc Andreessen, Robert |
---|
2682 | Cailliau, Daniel W. Connolly, Bob Denny, John Franks, Jean-Francois |
---|
2683 | Groff, Phillip M. Hallam-Baker, Hakon W. Lie, Ari Luotonen, Rob |
---|
2684 | |
---|
2685 | |
---|
2686 | |
---|
2687 | Fielding, et al. Expires June 22, 2008 [Page 48] |
---|
2688 | |
---|
2689 | Internet-Draft HTTP/1.1 December 2007 |
---|
2690 | |
---|
2691 | |
---|
2692 | McCool, Lou Montulli, Dave Raggett, Tony Sanders, and Marc |
---|
2693 | VanHeyningen deserve special recognition for their efforts in |
---|
2694 | defining early aspects of the protocol. |
---|
2695 | |
---|
2696 | This document has benefited greatly from the comments of all those |
---|
2697 | participating in the HTTP-WG. In addition to those already |
---|
2698 | mentioned, the following individuals have contributed to this |
---|
2699 | specification: |
---|
2700 | |
---|
2701 | Gary Adams Ross Patterson |
---|
2702 | Harald Tveit Alvestrand Albert Lunde |
---|
2703 | Keith Ball John C. Mallery |
---|
2704 | Brian Behlendorf Jean-Philippe Martin-Flatin |
---|
2705 | Paul Burchard Mitra |
---|
2706 | Maurizio Codogno David Morris |
---|
2707 | Mike Cowlishaw Gavin Nicol |
---|
2708 | Roman Czyborra Bill Perry |
---|
2709 | Michael A. Dolan Jeffrey Perry |
---|
2710 | David J. Fiander Scott Powers |
---|
2711 | Alan Freier Owen Rees |
---|
2712 | Marc Hedlund Luigi Rizzo |
---|
2713 | Greg Herlihy David Robinson |
---|
2714 | Koen Holtman Marc Salomon |
---|
2715 | Alex Hopmann Rich Salz |
---|
2716 | Bob Jernigan Allan M. Schiffman |
---|
2717 | Shel Kaphan Jim Seidman |
---|
2718 | Rohit Khare Chuck Shotton |
---|
2719 | John Klensin Eric W. Sink |
---|
2720 | Martijn Koster Simon E. Spero |
---|
2721 | Alexei Kosut Richard N. Taylor |
---|
2722 | David M. Kristol Robert S. Thau |
---|
2723 | Daniel LaLiberte Bill (BearHeart) Weinman |
---|
2724 | Ben Laurie Francois Yergeau |
---|
2725 | Paul J. Leach Mary Ellen Zurko |
---|
2726 | Daniel DuBois Josh Cohen |
---|
2727 | |
---|
2728 | Thanks to the "cave men" of Palo Alto. You know who you are. |
---|
2729 | |
---|
2730 | Jim Gettys (the current editor of this document) wishes particularly |
---|
2731 | to thank Roy Fielding, the previous editor of this document, along |
---|
2732 | with John Klensin, Jeff Mogul, Paul Leach, Dave Kristol, Koen |
---|
2733 | Holtman, John Franks, Josh Cohen, Alex Hopmann, Scott Lawrence, and |
---|
2734 | Larry Masinter for their help. And thanks go particularly to Jeff |
---|
2735 | Mogul and Scott Lawrence for performing the "MUST/MAY/SHOULD" audit. |
---|
2736 | |
---|
2737 | The Apache Group, Anselm Baird-Smith, author of Jigsaw, and Henrik |
---|
2738 | Frystyk implemented RFC 2068 early, and we wish to thank them for the |
---|
2739 | discovery of many of the problems that this document attempts to |
---|
2740 | |
---|
2741 | |
---|
2742 | |
---|
2743 | Fielding, et al. Expires June 22, 2008 [Page 49] |
---|
2744 | |
---|
2745 | Internet-Draft HTTP/1.1 December 2007 |
---|
2746 | |
---|
2747 | |
---|
2748 | rectify. |
---|
2749 | |
---|
2750 | Based on an XML translation of RFC 2616 by Julian Reschke. |
---|
2751 | |
---|
2752 | |
---|
2753 | 12. References |
---|
2754 | |
---|
2755 | [ISO-8859] |
---|
2756 | International Organization for Standardization, |
---|
2757 | "Information technology - 8-bit single byte coded graphic |
---|
2758 | - character sets", 1987-1990. |
---|
2759 | |
---|
2760 | Part 1: Latin alphabet No. 1, ISO-8859-1:1987. Part 2: |
---|
2761 | Latin alphabet No. 2, ISO-8859-2, 1987. Part 3: Latin |
---|
2762 | alphabet No. 3, ISO-8859-3, 1988. Part 4: Latin alphabet |
---|
2763 | No. 4, ISO-8859-4, 1988. Part 5: Latin/Cyrillic alphabet, |
---|
2764 | ISO-8859-5, 1988. Part 6: Latin/Arabic alphabet, ISO- |
---|
2765 | 8859-6, 1987. Part 7: Latin/Greek alphabet, ISO-8859-7, |
---|
2766 | 1987. Part 8: Latin/Hebrew alphabet, ISO-8859-8, 1988. |
---|
2767 | Part 9: Latin alphabet No. 5, ISO-8859-9, 1990. |
---|
2768 | |
---|
2769 | [Nie1997] Nielsen, H., Gettys, J., Prud'hommeaux, E., Lie, H., and |
---|
2770 | C. Lilley, "Network Performance Effects of HTTP/1.1, CSS1, |
---|
2771 | and PNG", Proceedings of ACM SIGCOMM '97, Cannes France , |
---|
2772 | Sep 1997. |
---|
2773 | |
---|
2774 | [Pad1995] Padmanabhan, V. and J. Mogul, "Improving HTTP Latency", |
---|
2775 | Computer Networks and ISDN Systems v. 28, pp. 25-35, |
---|
2776 | Dec 1995. |
---|
2777 | |
---|
2778 | Slightly revised version of paper in Proc. 2nd |
---|
2779 | International WWW Conference '94: Mosaic and the Web, Oct. |
---|
2780 | 1994, which is available at <http://www.ncsa.uiuc.edu/SDG/ |
---|
2781 | IT94/Proceedings/DDay/mogul/HTTPLatency.html>. |
---|
2782 | |
---|
2783 | [Part2] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., |
---|
2784 | Masinter, L., Leach, P., and T. Berners-Lee, "HTTP/1.1, |
---|
2785 | part 2: Message Semantics", |
---|
2786 | draft-ietf-httpbis-p2-semantics-00 (work in progress), |
---|
2787 | December 2007. |
---|
2788 | |
---|
2789 | [Part3] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., |
---|
2790 | Masinter, L., Leach, P., and T. Berners-Lee, "HTTP/1.1, |
---|
2791 | part 3: Message Payload and Content Negotiation", |
---|
2792 | draft-ietf-httpbis-p3-payload-00 (work in progress), |
---|
2793 | December 2007. |
---|
2794 | |
---|
2795 | [Part6] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., |
---|
2796 | |
---|
2797 | |
---|
2798 | |
---|
2799 | Fielding, et al. Expires June 22, 2008 [Page 50] |
---|
2800 | |
---|
2801 | Internet-Draft HTTP/1.1 December 2007 |
---|
2802 | |
---|
2803 | |
---|
2804 | Masinter, L., Leach, P., and T. Berners-Lee, "HTTP/1.1, |
---|
2805 | part 6: Caching", draft-ietf-httpbis-p6-cache-00 (work in |
---|
2806 | progress), December 2007. |
---|
2807 | |
---|
2808 | [RFC1036] Horton, M. and R. Adams, "Standard for interchange of |
---|
2809 | USENET messages", RFC 1036, December 1987. |
---|
2810 | |
---|
2811 | [RFC1123] Braden, R., "Requirements for Internet Hosts - Application |
---|
2812 | and Support", STD 3, RFC 1123, October 1989. |
---|
2813 | |
---|
2814 | [RFC1305] Mills, D., "Network Time Protocol (Version 3) |
---|
2815 | Specification, Implementation", RFC 1305, March 1992. |
---|
2816 | |
---|
2817 | [RFC1436] Anklesaria, F., McCahill, M., Lindner, P., Johnson, D., |
---|
2818 | Torrey, D., and B. Alberti, "The Internet Gopher Protocol |
---|
2819 | (a distributed document search and retrieval protocol)", |
---|
2820 | RFC 1436, March 1993. |
---|
2821 | |
---|
2822 | [RFC1590] Postel, J., "Media Type Registration Procedure", RFC 1590, |
---|
2823 | November 1996. |
---|
2824 | |
---|
2825 | [RFC1630] Berners-Lee, T., "Universal Resource Identifiers in WWW: A |
---|
2826 | Unifying Syntax for the Expression of Names and Addresses |
---|
2827 | of Objects on the Network as used in the World-Wide Web", |
---|
2828 | RFC 1630, June 1994. |
---|
2829 | |
---|
2830 | [RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, |
---|
2831 | RFC 1700, October 1994. |
---|
2832 | |
---|
2833 | [RFC1737] Masinter, L. and K. Sollins, "Functional Requirements for |
---|
2834 | Uniform Resource Names", RFC 1737, December 1994. |
---|
2835 | |
---|
2836 | [RFC1738] Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform |
---|
2837 | Resource Locators (URL)", RFC 1738, December 1994. |
---|
2838 | |
---|
2839 | [RFC1808] Fielding, R., "Relative Uniform Resource Locators", |
---|
2840 | RFC 1808, June 1995. |
---|
2841 | |
---|
2842 | [RFC1900] Carpenter, B. and Y. Rekhter, "Renumbering Needs Work", |
---|
2843 | RFC 1900, February 1996. |
---|
2844 | |
---|
2845 | [RFC1945] Berners-Lee, T., Fielding, R., and H. Nielsen, "Hypertext |
---|
2846 | Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996. |
---|
2847 | |
---|
2848 | [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail |
---|
2849 | Extensions (MIME) Part One: Format of Internet Message |
---|
2850 | Bodies", RFC 2045, November 1996. |
---|
2851 | |
---|
2852 | |
---|
2853 | |
---|
2854 | |
---|
2855 | Fielding, et al. Expires June 22, 2008 [Page 51] |
---|
2856 | |
---|
2857 | Internet-Draft HTTP/1.1 December 2007 |
---|
2858 | |
---|
2859 | |
---|
2860 | [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) |
---|
2861 | Part Three: Message Header Extensions for Non-ASCII Text", |
---|
2862 | RFC 2047, November 1996. |
---|
2863 | |
---|
2864 | [RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and T. |
---|
2865 | Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", |
---|
2866 | RFC 2068, January 1997. |
---|
2867 | |
---|
2868 | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate |
---|
2869 | Requirement Levels", BCP 14, RFC 2119, March 1997. |
---|
2870 | |
---|
2871 | [RFC2145] Mogul, J., Fielding, R., Gettys, J., and H. Nielsen, "Use |
---|
2872 | and Interpretation of HTTP Version Numbers", RFC 2145, |
---|
2873 | May 1997. |
---|
2874 | |
---|
2875 | [RFC2324] Masinter, L., "Hyper Text Coffee Pot Control Protocol |
---|
2876 | (HTCPCP/1.0)", RFC 2324, April 1998. |
---|
2877 | |
---|
2878 | [RFC2396] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform |
---|
2879 | Resource Identifiers (URI): Generic Syntax", RFC 2396, |
---|
2880 | August 1998. |
---|
2881 | |
---|
2882 | [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., |
---|
2883 | Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext |
---|
2884 | Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. |
---|
2885 | |
---|
2886 | [RFC821] Postel, J., "Simple Mail Transfer Protocol", STD 10, |
---|
2887 | RFC 821, August 1982. |
---|
2888 | |
---|
2889 | [RFC822] Crocker, D., "Standard for the format of ARPA Internet |
---|
2890 | text messages", STD 11, RFC 822, August 1982. |
---|
2891 | |
---|
2892 | [RFC959] Postel, J. and J. Reynolds, "File Transfer Protocol", |
---|
2893 | STD 9, RFC 959, October 1985. |
---|
2894 | |
---|
2895 | [RFC977] Kantor, B. and P. Lapsley, "Network News Transfer |
---|
2896 | Protocol", RFC 977, February 1986. |
---|
2897 | |
---|
2898 | [Spe] Spero, S., "Analysis of HTTP Performance Problems", |
---|
2899 | <http://sunsite.unc.edu/mdma-release/http-prob.html>. |
---|
2900 | |
---|
2901 | [Tou1998] Touch, J., Heidemann, J., and K. Obraczka, "Analysis of |
---|
2902 | HTTP Performance", ISI Research Report ISI/RR-98-463 |
---|
2903 | (original report dated Aug.1996), Aug 1998, |
---|
2904 | <http://www.isi.edu/touch/pubs/http-perf96/>. |
---|
2905 | |
---|
2906 | [USASCII] American National Standards Institute, "Coded Character |
---|
2907 | Set -- 7-bit American Standard Code for Information |
---|
2908 | |
---|
2909 | |
---|
2910 | |
---|
2911 | Fielding, et al. Expires June 22, 2008 [Page 52] |
---|
2912 | |
---|
2913 | Internet-Draft HTTP/1.1 December 2007 |
---|
2914 | |
---|
2915 | |
---|
2916 | Interchange", ANSI X3.4, 1986. |
---|
2917 | |
---|
2918 | [WAIS] Davis, F., Kahle, B., Morris, H., Salem, J., Shen, T., |
---|
2919 | Wang, R., Sui, J., and M. Grinbaum, "WAIS Interface |
---|
2920 | Protocol Prototype Functional Specification (v1.5)", |
---|
2921 | Thinking Machines Corporation , April 1990. |
---|
2922 | |
---|
2923 | |
---|
2924 | Appendix A. Internet Media Type message/http and application/http |
---|
2925 | |
---|
2926 | In addition to defining the HTTP/1.1 protocol, this document serves |
---|
2927 | as the specification for the Internet media type "message/http" and |
---|
2928 | "application/http". The message/http type can be used to enclose a |
---|
2929 | single HTTP request or response message, provided that it obeys the |
---|
2930 | MIME restrictions for all "message" types regarding line length and |
---|
2931 | encodings. The application/http type can be used to enclose a |
---|
2932 | pipeline of one or more HTTP request or response messages (not |
---|
2933 | intermixed). The following is to be registered with IANA [RFC1590]. |
---|
2934 | |
---|
2935 | Media Type name: message |
---|
2936 | |
---|
2937 | Media subtype name: http |
---|
2938 | |
---|
2939 | Required parameters: none |
---|
2940 | |
---|
2941 | Optional parameters: version, msgtype |
---|
2942 | |
---|
2943 | version: The HTTP-Version number of the enclosed message (e.g., |
---|
2944 | "1.1"). If not present, the version can be determined from the |
---|
2945 | first line of the body. |
---|
2946 | |
---|
2947 | msgtype: The message type -- "request" or "response". If not |
---|
2948 | present, the type can be determined from the first line of the |
---|
2949 | body. |
---|
2950 | |
---|
2951 | Encoding considerations: only "7bit", "8bit", or "binary" are |
---|
2952 | permitted |
---|
2953 | |
---|
2954 | Security considerations: none |
---|
2955 | |
---|
2956 | Media Type name: application |
---|
2957 | |
---|
2958 | Media subtype name: http |
---|
2959 | |
---|
2960 | Required parameters: none |
---|
2961 | |
---|
2962 | |
---|
2963 | |
---|
2964 | |
---|
2965 | |
---|
2966 | |
---|
2967 | Fielding, et al. Expires June 22, 2008 [Page 53] |
---|
2968 | |
---|
2969 | Internet-Draft HTTP/1.1 December 2007 |
---|
2970 | |
---|
2971 | |
---|
2972 | Optional parameters: version, msgtype |
---|
2973 | |
---|
2974 | version: The HTTP-Version number of the enclosed messages (e.g., |
---|
2975 | "1.1"). If not present, the version can be determined from the |
---|
2976 | first line of the body. |
---|
2977 | |
---|
2978 | msgtype: The message type -- "request" or "response". If not |
---|
2979 | present, the type can be determined from the first line of the |
---|
2980 | body. |
---|
2981 | |
---|
2982 | Encoding considerations: HTTP messages enclosed by this type are in |
---|
2983 | "binary" format; use of an appropriate Content-Transfer-Encoding |
---|
2984 | is required when transmitted via E-mail. |
---|
2985 | |
---|
2986 | Security considerations: none |
---|
2987 | |
---|
2988 | |
---|
2989 | Appendix B. Tolerant Applications |
---|
2990 | |
---|
2991 | Although this document specifies the requirements for the generation |
---|
2992 | of HTTP/1.1 messages, not all applications will be correct in their |
---|
2993 | implementation. We therefore recommend that operational applications |
---|
2994 | be tolerant of deviations whenever those deviations can be |
---|
2995 | interpreted unambiguously. |
---|
2996 | |
---|
2997 | Clients SHOULD be tolerant in parsing the Status-Line and servers |
---|
2998 | tolerant when parsing the Request-Line. In particular, they SHOULD |
---|
2999 | accept any amount of SP or HT characters between fields, even though |
---|
3000 | only a single SP is required. |
---|
3001 | |
---|
3002 | The line terminator for message-header fields is the sequence CRLF. |
---|
3003 | However, we recommend that applications, when parsing such headers, |
---|
3004 | recognize a single LF as a line terminator and ignore the leading CR. |
---|
3005 | |
---|
3006 | The character set of an entity-body SHOULD be labeled as the lowest |
---|
3007 | common denominator of the character codes used within that body, with |
---|
3008 | the exception that not labeling the entity is preferred over labeling |
---|
3009 | the entity with the labels US-ASCII or ISO-8859-1. See [Part3]. |
---|
3010 | |
---|
3011 | Additional rules for requirements on parsing and encoding of dates |
---|
3012 | and other potential problems with date encodings include: |
---|
3013 | |
---|
3014 | o HTTP/1.1 clients and caches SHOULD assume that an RFC-850 date |
---|
3015 | which appears to be more than 50 years in the future is in fact in |
---|
3016 | the past (this helps solve the "year 2000" problem). |
---|
3017 | |
---|
3018 | o An HTTP/1.1 implementation MAY internally represent a parsed |
---|
3019 | Expires date as earlier than the proper value, but MUST NOT |
---|
3020 | |
---|
3021 | |
---|
3022 | |
---|
3023 | Fielding, et al. Expires June 22, 2008 [Page 54] |
---|
3024 | |
---|
3025 | Internet-Draft HTTP/1.1 December 2007 |
---|
3026 | |
---|
3027 | |
---|
3028 | internally represent a parsed Expires date as later than the |
---|
3029 | proper value. |
---|
3030 | |
---|
3031 | o All expiration-related calculations MUST be done in GMT. The |
---|
3032 | local time zone MUST NOT influence the calculation or comparison |
---|
3033 | of an age or expiration time. |
---|
3034 | |
---|
3035 | o If an HTTP header incorrectly carries a date value with a time |
---|
3036 | zone other than GMT, it MUST be converted into GMT using the most |
---|
3037 | conservative possible conversion. |
---|
3038 | |
---|
3039 | |
---|
3040 | Appendix C. Conversion of Date Formats |
---|
3041 | |
---|
3042 | HTTP/1.1 uses a restricted set of date formats (Section 3.3.1) to |
---|
3043 | simplify the process of date comparison. Proxies and gateways from |
---|
3044 | other protocols SHOULD ensure that any Date header field present in a |
---|
3045 | message conforms to one of the HTTP/1.1 formats and rewrite the date |
---|
3046 | if necessary. |
---|
3047 | |
---|
3048 | |
---|
3049 | Appendix D. Compatibility with Previous Versions |
---|
3050 | |
---|
3051 | It is beyond the scope of a protocol specification to mandate |
---|
3052 | compliance with previous versions. HTTP/1.1 was deliberately |
---|
3053 | designed, however, to make supporting previous versions easy. It is |
---|
3054 | worth noting that, at the time of composing this specification |
---|
3055 | (1996), we would expect commercial HTTP/1.1 servers to: |
---|
3056 | |
---|
3057 | o recognize the format of the Request-Line for HTTP/0.9, 1.0, and |
---|
3058 | 1.1 requests; |
---|
3059 | |
---|
3060 | o understand any valid request in the format of HTTP/0.9, 1.0, or |
---|
3061 | 1.1; |
---|
3062 | |
---|
3063 | o respond appropriately with a message in the same major version |
---|
3064 | used by the client. |
---|
3065 | |
---|
3066 | And we would expect HTTP/1.1 clients to: |
---|
3067 | |
---|
3068 | o recognize the format of the Status-Line for HTTP/1.0 and 1.1 |
---|
3069 | responses; |
---|
3070 | |
---|
3071 | o understand any valid response in the format of HTTP/0.9, 1.0, or |
---|
3072 | 1.1. |
---|
3073 | |
---|
3074 | For most implementations of HTTP/1.0, each connection is established |
---|
3075 | by the client prior to the request and closed by the server after |
---|
3076 | |
---|
3077 | |
---|
3078 | |
---|
3079 | Fielding, et al. Expires June 22, 2008 [Page 55] |
---|
3080 | |
---|
3081 | Internet-Draft HTTP/1.1 December 2007 |
---|
3082 | |
---|
3083 | |
---|
3084 | sending the response. Some implementations implement the Keep-Alive |
---|
3085 | version of persistent connections described in Section 19.7.1 of RFC |
---|
3086 | 2068 [RFC2068]. |
---|
3087 | |
---|
3088 | D.1. Changes from HTTP/1.0 |
---|
3089 | |
---|
3090 | This section summarizes major differences between versions HTTP/1.0 |
---|
3091 | and HTTP/1.1. |
---|
3092 | |
---|
3093 | D.1.1. Changes to Simplify Multi-homed Web Servers and Conserve IP |
---|
3094 | Addresses |
---|
3095 | |
---|
3096 | The requirements that clients and servers support the Host request- |
---|
3097 | header, report an error if the Host request-header (Section 8.4) is |
---|
3098 | missing from an HTTP/1.1 request, and accept absolute URIs |
---|
3099 | (Section 5.1.2) are among the most important changes defined by this |
---|
3100 | specification. |
---|
3101 | |
---|
3102 | Older HTTP/1.0 clients assumed a one-to-one relationship of IP |
---|
3103 | addresses and servers; there was no other established mechanism for |
---|
3104 | distinguishing the intended server of a request than the IP address |
---|
3105 | to which that request was directed. The changes outlined above will |
---|
3106 | allow the Internet, once older HTTP clients are no longer common, to |
---|
3107 | support multiple Web sites from a single IP address, greatly |
---|
3108 | simplifying large operational Web servers, where allocation of many |
---|
3109 | IP addresses to a single host has created serious problems. The |
---|
3110 | Internet will also be able to recover the IP addresses that have been |
---|
3111 | allocated for the sole purpose of allowing special-purpose domain |
---|
3112 | names to be used in root-level HTTP URLs. Given the rate of growth |
---|
3113 | of the Web, and the number of servers already deployed, it is |
---|
3114 | extremely important that all implementations of HTTP (including |
---|
3115 | updates to existing HTTP/1.0 applications) correctly implement these |
---|
3116 | requirements: |
---|
3117 | |
---|
3118 | o Both clients and servers MUST support the Host request-header. |
---|
3119 | |
---|
3120 | o A client that sends an HTTP/1.1 request MUST send a Host header. |
---|
3121 | |
---|
3122 | o Servers MUST report a 400 (Bad Request) error if an HTTP/1.1 |
---|
3123 | request does not include a Host request-header. |
---|
3124 | |
---|
3125 | o Servers MUST accept absolute URIs. |
---|
3126 | |
---|
3127 | D.2. Compatibility with HTTP/1.0 Persistent Connections |
---|
3128 | |
---|
3129 | Some clients and servers might wish to be compatible with some |
---|
3130 | previous implementations of persistent connections in HTTP/1.0 |
---|
3131 | clients and servers. Persistent connections in HTTP/1.0 are |
---|
3132 | |
---|
3133 | |
---|
3134 | |
---|
3135 | Fielding, et al. Expires June 22, 2008 [Page 56] |
---|
3136 | |
---|
3137 | Internet-Draft HTTP/1.1 December 2007 |
---|
3138 | |
---|
3139 | |
---|
3140 | explicitly negotiated as they are not the default behavior. HTTP/1.0 |
---|
3141 | experimental implementations of persistent connections are faulty, |
---|
3142 | and the new facilities in HTTP/1.1 are designed to rectify these |
---|
3143 | problems. The problem was that some existing 1.0 clients may be |
---|
3144 | sending Keep-Alive to a proxy server that doesn't understand |
---|
3145 | Connection, which would then erroneously forward it to the next |
---|
3146 | inbound server, which would establish the Keep-Alive connection and |
---|
3147 | result in a hung HTTP/1.0 proxy waiting for the close on the |
---|
3148 | response. The result is that HTTP/1.0 clients must be prevented from |
---|
3149 | using Keep-Alive when talking to proxies. |
---|
3150 | |
---|
3151 | However, talking to proxies is the most important use of persistent |
---|
3152 | connections, so that prohibition is clearly unacceptable. Therefore, |
---|
3153 | we need some other mechanism for indicating a persistent connection |
---|
3154 | is desired, which is safe to use even when talking to an old proxy |
---|
3155 | that ignores Connection. Persistent connections are the default for |
---|
3156 | HTTP/1.1 messages; we introduce a new keyword (Connection: close) for |
---|
3157 | declaring non-persistence. See Section 8.1. |
---|
3158 | |
---|
3159 | The original HTTP/1.0 form of persistent connections (the Connection: |
---|
3160 | Keep-Alive and Keep-Alive header) is documented in RFC 2068. |
---|
3161 | [RFC2068] |
---|
3162 | |
---|
3163 | D.3. Changes from RFC 2068 |
---|
3164 | |
---|
3165 | This specification has been carefully audited to correct and |
---|
3166 | disambiguate key word usage; RFC 2068 had many problems in respect to |
---|
3167 | the conventions laid out in RFC 2119 [RFC2119]. |
---|
3168 | |
---|
3169 | Transfer-coding and message lengths all interact in ways that |
---|
3170 | required fixing exactly when chunked encoding is used (to allow for |
---|
3171 | transfer encoding that may not be self delimiting); it was important |
---|
3172 | to straighten out exactly how message lengths are computed. |
---|
3173 | |
---|
3174 | The use and interpretation of HTTP version numbers has been clarified |
---|
3175 | by RFC 2145. Require proxies to upgrade requests to highest protocol |
---|
3176 | version they support to deal with problems discovered in HTTP/1.0 |
---|
3177 | implementations (Section 3.1) |
---|
3178 | |
---|
3179 | Proxies should be able to add Content-Length when appropriate. |
---|
3180 | |
---|
3181 | Transfer-coding had significant problems, particularly with |
---|
3182 | interactions with chunked encoding. The solution is that transfer- |
---|
3183 | codings become as full fledged as content-codings. This involves |
---|
3184 | adding an IANA registry for transfer-codings (separate from content |
---|
3185 | codings), a new header field (TE) and enabling trailer headers in the |
---|
3186 | future. Transfer encoding is a major performance benefit, so it was |
---|
3187 | worth fixing [Nie1997]. TE also solves another, obscure, downward |
---|
3188 | |
---|
3189 | |
---|
3190 | |
---|
3191 | Fielding, et al. Expires June 22, 2008 [Page 57] |
---|
3192 | |
---|
3193 | Internet-Draft HTTP/1.1 December 2007 |
---|
3194 | |
---|
3195 | |
---|
3196 | interoperability problem that could have occurred due to interactions |
---|
3197 | between authentication trailers, chunked encoding and HTTP/1.0 |
---|
3198 | clients.(Section 3.4, 3.4.1, and 8.5) |
---|
3199 | |
---|
3200 | |
---|
3201 | Index |
---|
3202 | |
---|
3203 | A |
---|
3204 | application/http Media Type 53 |
---|
3205 | |
---|
3206 | C |
---|
3207 | cache 8 |
---|
3208 | cacheable 8 |
---|
3209 | client 7 |
---|
3210 | connection 6 |
---|
3211 | Connection header 37 |
---|
3212 | content negotiation 7 |
---|
3213 | Content-Length header 38 |
---|
3214 | |
---|
3215 | D |
---|
3216 | Date header 39 |
---|
3217 | downstream 9 |
---|
3218 | |
---|
3219 | E |
---|
3220 | entity 6 |
---|
3221 | |
---|
3222 | G |
---|
3223 | gateway 8 |
---|
3224 | Grammar |
---|
3225 | ALPHA 13 |
---|
3226 | asctime-date 19 |
---|
3227 | attribute 19 |
---|
3228 | CHAR 13 |
---|
3229 | chunk 21 |
---|
3230 | chunk-data 21 |
---|
3231 | chunk-ext-name 21 |
---|
3232 | chunk-ext-val 21 |
---|
3233 | chunk-extension 21 |
---|
3234 | chunk-size 21 |
---|
3235 | Chunked-Body 21 |
---|
3236 | comment 14 |
---|
3237 | Connection 37 |
---|
3238 | connection-token 37 |
---|
3239 | Content-Length 38 |
---|
3240 | CR 13 |
---|
3241 | CRLF 13 |
---|
3242 | ctext 14 |
---|
3243 | CTL 13 |
---|
3244 | |
---|
3245 | |
---|
3246 | |
---|
3247 | Fielding, et al. Expires June 22, 2008 [Page 58] |
---|
3248 | |
---|
3249 | Internet-Draft HTTP/1.1 December 2007 |
---|
3250 | |
---|
3251 | |
---|
3252 | Date 39 |
---|
3253 | date1 19 |
---|
3254 | date2 19 |
---|
3255 | date3 19 |
---|
3256 | DIGIT 13 |
---|
3257 | extension-code 30 |
---|
3258 | extension-method 27 |
---|
3259 | field-content 23 |
---|
3260 | field-name 23 |
---|
3261 | field-value 23 |
---|
3262 | general-header 26 |
---|
3263 | generic-message 22 |
---|
3264 | HEX 14 |
---|
3265 | Host 40 |
---|
3266 | HT 13 |
---|
3267 | HTTP-date 19 |
---|
3268 | HTTP-message 22 |
---|
3269 | HTTP-Version 15 |
---|
3270 | http_URL 17 |
---|
3271 | last-chunk 21 |
---|
3272 | LF 13 |
---|
3273 | LOALPHA 13 |
---|
3274 | LWS 14 |
---|
3275 | message-body 24 |
---|
3276 | message-header 23 |
---|
3277 | Method 27 |
---|
3278 | month 19 |
---|
3279 | OCTET 13 |
---|
3280 | parameter 19 |
---|
3281 | protocol-name 44 |
---|
3282 | protocol-version 44 |
---|
3283 | pseudonym 44 |
---|
3284 | qdtext 15 |
---|
3285 | quoted-pair 15 |
---|
3286 | quoted-string 15 |
---|
3287 | Reason-Phrase 30 |
---|
3288 | received-by 44 |
---|
3289 | received-protocol 44 |
---|
3290 | Request 27 |
---|
3291 | Request-Line 27 |
---|
3292 | Request-URI 27 |
---|
3293 | Response 29 |
---|
3294 | rfc850-date 19 |
---|
3295 | rfc1123-date 19 |
---|
3296 | separators 14 |
---|
3297 | SP 13 |
---|
3298 | start-line 22 |
---|
3299 | Status-Code 30 |
---|
3300 | |
---|
3301 | |
---|
3302 | |
---|
3303 | Fielding, et al. Expires June 22, 2008 [Page 59] |
---|
3304 | |
---|
3305 | Internet-Draft HTTP/1.1 December 2007 |
---|
3306 | |
---|
3307 | |
---|
3308 | Status-Line 29 |
---|
3309 | t-codings 41 |
---|
3310 | TE 41 |
---|
3311 | TEXT 14 |
---|
3312 | time 19 |
---|
3313 | token 14 |
---|
3314 | Trailer 42 |
---|
3315 | trailer 21 |
---|
3316 | transfer-coding 19 |
---|
3317 | Transfer-Encoding 43 |
---|
3318 | transfer-extension 19 |
---|
3319 | UPALPHA 13 |
---|
3320 | Upgrade 43 |
---|
3321 | value 19 |
---|
3322 | Via 44 |
---|
3323 | weekday 19 |
---|
3324 | wkday 19 |
---|
3325 | |
---|
3326 | H |
---|
3327 | Headers |
---|
3328 | Connection 37 |
---|
3329 | Content-Length 38 |
---|
3330 | Date 39 |
---|
3331 | Host 40 |
---|
3332 | TE 41 |
---|
3333 | Trailer 42 |
---|
3334 | Transfer-Encoding 43 |
---|
3335 | Upgrade 43 |
---|
3336 | Via 44 |
---|
3337 | Host header 40 |
---|
3338 | |
---|
3339 | I |
---|
3340 | inbound 9 |
---|
3341 | |
---|
3342 | M |
---|
3343 | Media Type |
---|
3344 | application/http 53 |
---|
3345 | message/http 53 |
---|
3346 | message 6 |
---|
3347 | message/http Media Type 53 |
---|
3348 | |
---|
3349 | O |
---|
3350 | origin server 8 |
---|
3351 | outbound 9 |
---|
3352 | |
---|
3353 | P |
---|
3354 | proxy 8 |
---|
3355 | |
---|
3356 | |
---|
3357 | |
---|
3358 | |
---|
3359 | Fielding, et al. Expires June 22, 2008 [Page 60] |
---|
3360 | |
---|
3361 | Internet-Draft HTTP/1.1 December 2007 |
---|
3362 | |
---|
3363 | |
---|
3364 | R |
---|
3365 | representation 7 |
---|
3366 | request 6 |
---|
3367 | resource 6 |
---|
3368 | response 6 |
---|
3369 | |
---|
3370 | S |
---|
3371 | server 7 |
---|
3372 | |
---|
3373 | T |
---|
3374 | TE header 41 |
---|
3375 | Trailer header 42 |
---|
3376 | Transfer-Encoding header 43 |
---|
3377 | tunnel 8 |
---|
3378 | |
---|
3379 | U |
---|
3380 | Upgrade header 43 |
---|
3381 | upstream 9 |
---|
3382 | user agent 7 |
---|
3383 | |
---|
3384 | V |
---|
3385 | variant 7 |
---|
3386 | Via header 44 |
---|
3387 | |
---|
3388 | |
---|
3389 | Authors' Addresses |
---|
3390 | |
---|
3391 | Roy T. Fielding (editor) |
---|
3392 | Day Software |
---|
3393 | 23 Corporate Plaza DR, Suite 280 |
---|
3394 | Newport Beach, CA 92660 |
---|
3395 | USA |
---|
3396 | |
---|
3397 | Phone: +1-949-706-5300 |
---|
3398 | Fax: +1-949-706-5305 |
---|
3399 | Email: fielding@gbiv.com |
---|
3400 | URI: http://roy.gbiv.com/ |
---|
3401 | |
---|
3402 | |
---|
3403 | Jim Gettys |
---|
3404 | One Laptop per Child |
---|
3405 | 21 Oak Knoll Road |
---|
3406 | Carlisle, MA 01741 |
---|
3407 | USA |
---|
3408 | |
---|
3409 | Email: jg@laptop.org |
---|
3410 | URI: http://www.laptop.org/ |
---|
3411 | |
---|
3412 | |
---|
3413 | |
---|
3414 | |
---|
3415 | Fielding, et al. Expires June 22, 2008 [Page 61] |
---|
3416 | |
---|
3417 | Internet-Draft HTTP/1.1 December 2007 |
---|
3418 | |
---|
3419 | |
---|
3420 | Jeffrey C. Mogul |
---|
3421 | Hewlett-Packard Company |
---|
3422 | HP Labs, Large Scale Systems Group |
---|
3423 | 1501 Page Mill Road, MS 1177 |
---|
3424 | Palo Alto, CA 94304 |
---|
3425 | USA |
---|
3426 | |
---|
3427 | Email: JeffMogul@acm.org |
---|
3428 | |
---|
3429 | |
---|
3430 | Henrik Frystyk Nielsen |
---|
3431 | Microsoft Corporation |
---|
3432 | 1 Microsoft Way |
---|
3433 | Redmond, WA 98052 |
---|
3434 | USA |
---|
3435 | |
---|
3436 | Email: henrikn@microsoft.com |
---|
3437 | |
---|
3438 | |
---|
3439 | Larry Masinter |
---|
3440 | Adobe Systems, Incorporated |
---|
3441 | 345 Park Ave |
---|
3442 | San Jose, CA 95110 |
---|
3443 | USA |
---|
3444 | |
---|
3445 | Email: LMM@acm.org |
---|
3446 | URI: http://larry.masinter.net/ |
---|
3447 | |
---|
3448 | |
---|
3449 | Paul J. Leach |
---|
3450 | Microsoft Corporation |
---|
3451 | 1 Microsoft Way |
---|
3452 | Redmond, WA 98052 |
---|
3453 | |
---|
3454 | Email: paulle@microsoft.com |
---|
3455 | |
---|
3456 | |
---|
3457 | Tim Berners-Lee |
---|
3458 | World Wide Web Consortium |
---|
3459 | MIT Computer Science and Artificial Intelligence Laboratory |
---|
3460 | The Stata Center, Building 32 |
---|
3461 | 32 Vassar Street |
---|
3462 | Cambridge, MA 02139 |
---|
3463 | USA |
---|
3464 | |
---|
3465 | Email: timbl@w3.org |
---|
3466 | URI: http://www.w3.org/People/Berners-Lee/ |
---|
3467 | |
---|
3468 | |
---|
3469 | |
---|
3470 | |
---|
3471 | Fielding, et al. Expires June 22, 2008 [Page 62] |
---|
3472 | |
---|
3473 | Internet-Draft HTTP/1.1 December 2007 |
---|
3474 | |
---|
3475 | |
---|
3476 | Full Copyright Statement |
---|
3477 | |
---|
3478 | Copyright (C) The IETF Trust (2007). |
---|
3479 | |
---|
3480 | This document is subject to the rights, licenses and restrictions |
---|
3481 | contained in BCP 78, and except as set forth therein, the authors |
---|
3482 | retain all their rights. |
---|
3483 | |
---|
3484 | This document and the information contained herein are provided on an |
---|
3485 | "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS |
---|
3486 | OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND |
---|
3487 | THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS |
---|
3488 | OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF |
---|
3489 | THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED |
---|
3490 | WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. |
---|
3491 | |
---|
3492 | |
---|
3493 | Intellectual Property |
---|
3494 | |
---|
3495 | The IETF takes no position regarding the validity or scope of any |
---|
3496 | Intellectual Property Rights or other rights that might be claimed to |
---|
3497 | pertain to the implementation or use of the technology described in |
---|
3498 | this document or the extent to which any license under such rights |
---|
3499 | might or might not be available; nor does it represent that it has |
---|
3500 | made any independent effort to identify any such rights. Information |
---|
3501 | on the procedures with respect to rights in RFC documents can be |
---|
3502 | found in BCP 78 and BCP 79. |
---|
3503 | |
---|
3504 | Copies of IPR disclosures made to the IETF Secretariat and any |
---|
3505 | assurances of licenses to be made available, or the result of an |
---|
3506 | attempt made to obtain a general license or permission for the use of |
---|
3507 | such proprietary rights by implementers or users of this |
---|
3508 | specification can be obtained from the IETF on-line IPR repository at |
---|
3509 | http://www.ietf.org/ipr. |
---|
3510 | |
---|
3511 | The IETF invites any interested party to bring to its attention any |
---|
3512 | copyrights, patents or patent applications, or other proprietary |
---|
3513 | rights that may cover technology that may be required to implement |
---|
3514 | this standard. Please address the information to the IETF at |
---|
3515 | ietf-ipr@ietf.org. |
---|
3516 | |
---|
3517 | |
---|
3518 | Acknowledgment |
---|
3519 | |
---|
3520 | Funding for the RFC Editor function is provided by the IETF |
---|
3521 | Administrative Support Activity (IASA). |
---|
3522 | |
---|
3523 | |
---|
3524 | |
---|
3525 | |
---|
3526 | |
---|
3527 | Fielding, et al. Expires June 22, 2008 [Page 63] |
---|
3528 | |
---|