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

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

Prepare release of -24 on Sept 25

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