source: draft-ietf-httpbis/23/draft-ietf-httpbis-p1-messaging-23.txt @ 2568

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

prepare release of -23

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