source: draft-ietf-httpbis/20/draft-ietf-httpbis-p1-messaging-20.txt @ 1860

Last change on this file since 1860 was 1807, checked in by julian.reschke@…, 8 years ago

Prepare release of -20 drafts

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