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

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

min. fixes (reg names, punctuation, etc) (see #553)

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