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