source: draft-ietf-httpbis/22/draft-ietf-httpbis-p1-messaging-22.txt @ 2561

Last change on this file since 2561 was 2190, checked in by julian.reschke@…, 7 years ago

prepare -22 for release

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