source: draft-ietf-httpbis/21/draft-ietf-httpbis-p1-messaging-21.txt @ 2492

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

prepare release of -21 drafts on Oct 4

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