source: draft-ietf-httpbis/latest/auth48/p1-messaging.unpg.txt @ 2653

Last change on this file since 2653 was 2653, checked in by julian.reschke@…, 6 years ago

IANA considerations: vertical ws, past tense (#553)

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