source: draft-ietf-httpbis/latest/auth48/rfc7230-to-be.unpg.txt @ 2631

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

add subproject for auth48 checks (#553)

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