idnits 2.17.1 draft-ietf-httpbis-p1-messaging-23.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document obsoletes RFC2616, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document obsoletes RFC2145, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC2817, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC2818, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC2817, updated by this document, for RFC5378 checks: 1998-11-18) (Using the creation date from RFC2818, updated by this document, for RFC5378 checks: 1998-01-27) -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 15, 2013) is 3932 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'Part5' is defined on line 3102, but no explicit reference was found in the text == Unused Reference: 'Part7' is defined on line 3112, but no explicit reference was found in the text == Unused Reference: 'RFC2145' is defined on line 3191, but no explicit reference was found in the text == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p2-semantics-23 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p4-conditional-23 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p5-range-23 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p6-cache-23 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p7-auth-23 ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) ** Downref: Normative reference to an Informational RFC: RFC 1950 ** Downref: Normative reference to an Informational RFC: RFC 1951 ** Downref: Normative reference to an Informational RFC: RFC 1952 -- Possible downref: Non-RFC (?) normative reference: ref. 'USASCII' -- Possible downref: Non-RFC (?) normative reference: ref. 'Welch' -- Obsolete informational reference (is this intentional?): RFC 4395 (ref. 'BCP115') (Obsoleted by RFC 7595) -- Obsolete informational reference (is this intentional?): RFC 2068 (Obsoleted by RFC 2616) -- Obsolete informational reference (is this intentional?): RFC 2145 (Obsoleted by RFC 7230) -- Obsolete informational reference (is this intentional?): RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) -- Obsolete informational reference (is this intentional?): RFC 2818 (Obsoleted by RFC 9110) -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) Summary: 4 errors (**), 0 flaws (~~), 9 warnings (==), 16 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 HTTPbis Working Group R. Fielding, Ed. 3 Internet-Draft Adobe 4 Obsoletes: 2145,2616 (if approved) J. Reschke, Ed. 5 Updates: 2817,2818 (if approved) greenbytes 6 Intended status: Standards Track July 15, 2013 7 Expires: January 16, 2014 9 Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing 10 draft-ietf-httpbis-p1-messaging-23 12 Abstract 14 The Hypertext Transfer Protocol (HTTP) is an application-level 15 protocol for distributed, collaborative, hypertext information 16 systems. HTTP has been in use by the World Wide Web global 17 information initiative since 1990. This document provides an 18 overview of HTTP architecture and its associated terminology, defines 19 the "http" and "https" Uniform Resource Identifier (URI) schemes, 20 defines the HTTP/1.1 message syntax and parsing requirements, and 21 describes general security concerns for implementations. 23 Editorial Note (To be removed by RFC Editor) 25 Discussion of this draft takes place on the HTTPBIS working group 26 mailing list (ietf-http-wg@w3.org), which is archived at 27 . 29 The current issues list is at 30 and related 31 documents (including fancy diffs) can be found at 32 . 34 The changes in this draft are summarized in Appendix D.3. 36 Status of This Memo 38 This Internet-Draft is submitted in full conformance with the 39 provisions of BCP 78 and BCP 79. 41 Internet-Drafts are working documents of the Internet Engineering 42 Task Force (IETF). Note that other groups may also distribute 43 working documents as Internet-Drafts. The list of current Internet- 44 Drafts is at http://datatracker.ietf.org/drafts/current/. 46 Internet-Drafts are draft documents valid for a maximum of six months 47 and may be updated, replaced, or obsoleted by other documents at any 48 time. It is inappropriate to use Internet-Drafts as reference 49 material or to cite them other than as "work in progress." 51 This Internet-Draft will expire on January 16, 2014. 53 Copyright Notice 55 Copyright (c) 2013 IETF Trust and the persons identified as the 56 document authors. All rights reserved. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents 60 (http://trustee.ietf.org/license-info) in effect on the date of 61 publication of this document. Please review these documents 62 carefully, as they describe your rights and restrictions with respect 63 to this document. Code Components extracted from this document must 64 include Simplified BSD License text as described in Section 4.e of 65 the Trust Legal Provisions and are provided without warranty as 66 described in the Simplified BSD License. 68 This document may contain material from IETF Documents or IETF 69 Contributions published or made publicly available before November 70 10, 2008. The person(s) controlling the copyright in some of this 71 material may not have granted the IETF Trust the right to allow 72 modifications of such material outside the IETF Standards Process. 73 Without obtaining an adequate license from the person(s) controlling 74 the copyright in such materials, this document may not be modified 75 outside the IETF Standards Process, and derivative works of it may 76 not be created outside the IETF Standards Process, except to format 77 it for publication as an RFC or to translate it into languages other 78 than English. 80 Table of Contents 82 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 83 1.1. Requirement Notation . . . . . . . . . . . . . . . . . . . 6 84 1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 6 85 2. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 6 86 2.1. Client/Server Messaging . . . . . . . . . . . . . . . . . 7 87 2.2. Implementation Diversity . . . . . . . . . . . . . . . . . 8 88 2.3. Intermediaries . . . . . . . . . . . . . . . . . . . . . . 9 89 2.4. Caches . . . . . . . . . . . . . . . . . . . . . . . . . . 11 90 2.5. Conformance and Error Handling . . . . . . . . . . . . . . 12 91 2.6. Protocol Versioning . . . . . . . . . . . . . . . . . . . 13 92 2.7. Uniform Resource Identifiers . . . . . . . . . . . . . . . 15 93 2.7.1. http URI scheme . . . . . . . . . . . . . . . . . . . 16 94 2.7.2. https URI scheme . . . . . . . . . . . . . . . . . . . 17 95 2.7.3. http and https URI Normalization and Comparison . . . 18 96 3. Message Format . . . . . . . . . . . . . . . . . . . . . . . . 19 97 3.1. Start Line . . . . . . . . . . . . . . . . . . . . . . . . 20 98 3.1.1. Request Line . . . . . . . . . . . . . . . . . . . . . 20 99 3.1.2. Status Line . . . . . . . . . . . . . . . . . . . . . 21 100 3.2. Header Fields . . . . . . . . . . . . . . . . . . . . . . 22 101 3.2.1. Field Extensibility . . . . . . . . . . . . . . . . . 22 102 3.2.2. Field Order . . . . . . . . . . . . . . . . . . . . . 22 103 3.2.3. Whitespace . . . . . . . . . . . . . . . . . . . . . . 23 104 3.2.4. Field Parsing . . . . . . . . . . . . . . . . . . . . 24 105 3.2.5. Field Limits . . . . . . . . . . . . . . . . . . . . . 25 106 3.2.6. Field value components . . . . . . . . . . . . . . . . 25 107 3.3. Message Body . . . . . . . . . . . . . . . . . . . . . . . 27 108 3.3.1. Transfer-Encoding . . . . . . . . . . . . . . . . . . 27 109 3.3.2. Content-Length . . . . . . . . . . . . . . . . . . . . 29 110 3.3.3. Message Body Length . . . . . . . . . . . . . . . . . 30 111 3.4. Handling Incomplete Messages . . . . . . . . . . . . . . . 32 112 3.5. Message Parsing Robustness . . . . . . . . . . . . . . . . 33 113 4. Transfer Codings . . . . . . . . . . . . . . . . . . . . . . . 34 114 4.1. Chunked Transfer Coding . . . . . . . . . . . . . . . . . 34 115 4.1.1. Trailer . . . . . . . . . . . . . . . . . . . . . . . 35 116 4.1.2. Decoding chunked . . . . . . . . . . . . . . . . . . . 36 117 4.2. Compression Codings . . . . . . . . . . . . . . . . . . . 37 118 4.2.1. Compress Coding . . . . . . . . . . . . . . . . . . . 37 119 4.2.2. Deflate Coding . . . . . . . . . . . . . . . . . . . . 37 120 4.2.3. Gzip Coding . . . . . . . . . . . . . . . . . . . . . 37 121 4.3. TE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 122 5. Message Routing . . . . . . . . . . . . . . . . . . . . . . . 38 123 5.1. Identifying a Target Resource . . . . . . . . . . . . . . 38 124 5.2. Connecting Inbound . . . . . . . . . . . . . . . . . . . . 39 125 5.3. Request Target . . . . . . . . . . . . . . . . . . . . . . 39 126 5.4. Host . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 127 5.5. Effective Request URI . . . . . . . . . . . . . . . . . . 43 128 5.6. Associating a Response to a Request . . . . . . . . . . . 44 129 5.7. Message Forwarding . . . . . . . . . . . . . . . . . . . . 44 130 5.7.1. Via . . . . . . . . . . . . . . . . . . . . . . . . . 45 131 5.7.2. Transformations . . . . . . . . . . . . . . . . . . . 46 132 6. Connection Management . . . . . . . . . . . . . . . . . . . . 47 133 6.1. Connection . . . . . . . . . . . . . . . . . . . . . . . . 48 134 6.2. Establishment . . . . . . . . . . . . . . . . . . . . . . 49 135 6.3. Persistence . . . . . . . . . . . . . . . . . . . . . . . 49 136 6.3.1. Retrying Requests . . . . . . . . . . . . . . . . . . 51 137 6.3.2. Pipelining . . . . . . . . . . . . . . . . . . . . . . 51 138 6.4. Concurrency . . . . . . . . . . . . . . . . . . . . . . . 52 139 6.5. Failures and Time-outs . . . . . . . . . . . . . . . . . . 52 140 6.6. Tear-down . . . . . . . . . . . . . . . . . . . . . . . . 53 141 6.7. Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . 54 142 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 56 143 7.1. Header Field Registration . . . . . . . . . . . . . . . . 56 144 7.2. URI Scheme Registration . . . . . . . . . . . . . . . . . 57 145 7.3. Internet Media Type Registration . . . . . . . . . . . . . 57 146 7.3.1. Internet Media Type message/http . . . . . . . . . . . 57 147 7.3.2. Internet Media Type application/http . . . . . . . . . 58 148 7.4. Transfer Coding Registry . . . . . . . . . . . . . . . . . 60 149 7.4.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 60 150 7.4.2. Registration . . . . . . . . . . . . . . . . . . . . . 60 151 7.5. Upgrade Token Registry . . . . . . . . . . . . . . . . . . 61 152 7.5.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 61 153 7.5.2. Upgrade Token Registration . . . . . . . . . . . . . . 61 154 8. Security Considerations . . . . . . . . . . . . . . . . . . . 62 155 8.1. DNS-related Attacks . . . . . . . . . . . . . . . . . . . 62 156 8.2. Intermediaries and Caching . . . . . . . . . . . . . . . . 62 157 8.3. Buffer Overflows . . . . . . . . . . . . . . . . . . . . . 63 158 8.4. Message Integrity . . . . . . . . . . . . . . . . . . . . 63 159 8.5. Server Log Information . . . . . . . . . . . . . . . . . . 64 160 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 64 161 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 66 162 10.1. Normative References . . . . . . . . . . . . . . . . . . . 66 163 10.2. Informative References . . . . . . . . . . . . . . . . . . 67 164 Appendix A. HTTP Version History . . . . . . . . . . . . . . . . 69 165 A.1. Changes from HTTP/1.0 . . . . . . . . . . . . . . . . . . 70 166 A.1.1. Multi-homed Web Servers . . . . . . . . . . . . . . . 70 167 A.1.2. Keep-Alive Connections . . . . . . . . . . . . . . . . 70 168 A.1.3. Introduction of Transfer-Encoding . . . . . . . . . . 71 169 A.2. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 71 170 Appendix B. ABNF list extension: #rule . . . . . . . . . . . . . 74 171 Appendix C. Collected ABNF . . . . . . . . . . . . . . . . . . . 75 172 Appendix D. Change Log (to be removed by RFC Editor before 173 publication) . . . . . . . . . . . . . . . . . . . . 77 174 D.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 77 175 D.2. Since draft-ietf-httpbis-p1-messaging-21 . . . . . . . . . 77 176 D.3. Since draft-ietf-httpbis-p1-messaging-22 . . . . . . . . . 79 177 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 179 1. Introduction 181 The Hypertext Transfer Protocol (HTTP) is an application-level 182 request/response protocol that uses extensible semantics and self- 183 descriptive message payloads for flexible interaction with network- 184 based hypertext information systems. This document is the first in a 185 series of documents that collectively form the HTTP/1.1 186 specification: 188 RFC xxx1: Message Syntax and Routing 190 RFC xxx2: Semantics and Content 192 RFC xxx3: Conditional Requests 194 RFC xxx4: Range Requests 196 RFC xxx5: Caching 198 RFC xxx6: Authentication 200 This HTTP/1.1 specification obsoletes and moves to historic status 201 RFC 2616, its predecessor RFC 2068, and RFC 2145 (on HTTP 202 versioning). This specification also updates the use of CONNECT to 203 establish a tunnel, previously defined in RFC 2817, and defines the 204 "https" URI scheme that was described informally in RFC 2818. 206 HTTP is a generic interface protocol for information systems. It is 207 designed to hide the details of how a service is implemented by 208 presenting a uniform interface to clients that is independent of the 209 types of resources provided. Likewise, servers do not need to be 210 aware of each client's purpose: an HTTP request can be considered in 211 isolation rather than being associated with a specific type of client 212 or a predetermined sequence of application steps. The result is a 213 protocol that can be used effectively in many different contexts and 214 for which implementations can evolve independently over time. 216 HTTP is also designed for use as an intermediation protocol for 217 translating communication to and from non-HTTP information systems. 218 HTTP proxies and gateways can provide access to alternative 219 information services by translating their diverse protocols into a 220 hypertext format that can be viewed and manipulated by clients in the 221 same way as HTTP services. 223 One consequence of this flexibility is that the protocol cannot be 224 defined in terms of what occurs behind the interface. Instead, we 225 are limited to defining the syntax of communication, the intent of 226 received communication, and the expected behavior of recipients. If 227 the communication is considered in isolation, then successful actions 228 ought to be reflected in corresponding changes to the observable 229 interface provided by servers. However, since multiple clients might 230 act in parallel and perhaps at cross-purposes, we cannot require that 231 such changes be observable beyond the scope of a single response. 233 This document describes the architectural elements that are used or 234 referred to in HTTP, defines the "http" and "https" URI schemes, 235 describes overall network operation and connection management, and 236 defines HTTP message framing and forwarding requirements. Our goal 237 is to define all of the mechanisms necessary for HTTP message 238 handling that are independent of message semantics, thereby defining 239 the complete set of requirements for message parsers and message- 240 forwarding intermediaries. 242 1.1. Requirement Notation 244 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 245 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 246 document are to be interpreted as described in [RFC2119]. 248 Conformance criteria and considerations regarding error handling are 249 defined in Section 2.5. 251 1.2. Syntax Notation 253 This specification uses the Augmented Backus-Naur Form (ABNF) 254 notation of [RFC5234] with the list rule extension defined in 255 Appendix B. Appendix C shows the collected ABNF with the list rule 256 expanded. 258 The following core rules are included by reference, as defined in 259 [RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF 260 (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote), 261 HEXDIG (hexadecimal 0-9/A-F/a-f), HTAB (horizontal tab), LF (line 262 feed), OCTET (any 8-bit sequence of data), SP (space), and VCHAR (any 263 visible [USASCII] character). 265 As a convention, ABNF rule names prefixed with "obs-" denote 266 "obsolete" grammar rules that appear for historical reasons. 268 2. Architecture 270 HTTP was created for the World Wide Web architecture and has evolved 271 over time to support the scalability needs of a worldwide hypertext 272 system. Much of that architecture is reflected in the terminology 273 and syntax productions used to define HTTP. 275 2.1. Client/Server Messaging 277 HTTP is a stateless request/response protocol that operates by 278 exchanging messages (Section 3) across a reliable transport or 279 session-layer "connection" (Section 6). An HTTP "client" is a 280 program that establishes a connection to a server for the purpose of 281 sending one or more HTTP requests. An HTTP "server" is a program 282 that accepts connections in order to service HTTP requests by sending 283 HTTP responses. 285 The terms client and server refer only to the roles that these 286 programs perform for a particular connection. The same program might 287 act as a client on some connections and a server on others. We use 288 the term "user agent" to refer to any of the various client programs 289 that initiate a request, including (but not limited to) browsers, 290 spiders (web-based robots), command-line tools, native applications, 291 and mobile apps. The term "origin server" is used to refer to the 292 program that can originate authoritative responses to a request. For 293 general requirements, we use the terms "sender" and "recipient" to 294 refer to any component that sends or receives, respectively, a given 295 message. 297 HTTP relies upon the Uniform Resource Identifier (URI) standard 298 [RFC3986] to indicate the target resource (Section 5.1) and 299 relationships between resources. Messages are passed in a format 300 similar to that used by Internet mail [RFC5322] and the Multipurpose 301 Internet Mail Extensions (MIME) [RFC2045] (see Appendix A of [Part2] 302 for the differences between HTTP and MIME messages). 304 Most HTTP communication consists of a retrieval request (GET) for a 305 representation of some resource identified by a URI. In the simplest 306 case, this might be accomplished via a single bidirectional 307 connection (===) between the user agent (UA) and the origin server 308 (O). 310 request > 311 UA ======================================= O 312 < response 314 A client sends an HTTP request to a server in the form of a request 315 message, beginning with a request-line that includes a method, URI, 316 and protocol version (Section 3.1.1), followed by header fields 317 containing request modifiers, client information, and representation 318 metadata (Section 3.2), an empty line to indicate the end of the 319 header section, and finally a message body containing the payload 320 body (if any, Section 3.3). 322 A server responds to a client's request by sending one or more HTTP 323 response messages, each beginning with a status line that includes 324 the protocol version, a success or error code, and textual reason 325 phrase (Section 3.1.2), possibly followed by header fields containing 326 server information, resource metadata, and representation metadata 327 (Section 3.2), an empty line to indicate the end of the header 328 section, and finally a message body containing the payload body (if 329 any, Section 3.3). 331 A connection might be used for multiple request/response exchanges, 332 as defined in Section 6.3. 334 The following example illustrates a typical message exchange for a 335 GET request on the URI "http://www.example.com/hello.txt": 337 client request: 339 GET /hello.txt HTTP/1.1 340 User-Agent: curl/7.16.3 libcurl/7.16.3 OpenSSL/0.9.7l zlib/1.2.3 341 Host: www.example.com 342 Accept-Language: en, mi 344 server response: 346 HTTP/1.1 200 OK 347 Date: Mon, 27 Jul 2009 12:28:53 GMT 348 Server: Apache 349 Last-Modified: Wed, 22 Jul 2009 19:15:56 GMT 350 ETag: "34aa387-d-1568eb00" 351 Accept-Ranges: bytes 352 Content-Length: 51 353 Vary: Accept-Encoding 354 Content-Type: text/plain 356 Hello World! My payload includes a trailing CRLF. 358 2.2. Implementation Diversity 360 When considering the design of HTTP, it is easy to fall into a trap 361 of thinking that all user agents are general-purpose browsers and all 362 origin servers are large public websites. That is not the case in 363 practice. Common HTTP user agents include household appliances, 364 stereos, scales, firmware update scripts, command-line programs, 365 mobile apps, and communication devices in a multitude of shapes and 366 sizes. Likewise, common HTTP origin servers include home automation 367 units, configurable networking components, office machines, 368 autonomous robots, news feeds, traffic cameras, ad selectors, and 369 video delivery platforms. 371 The term "user agent" does not imply that there is a human user 372 directly interacting with the software agent at the time of a 373 request. In many cases, a user agent is installed or configured to 374 run in the background and save its results for later inspection (or 375 save only a subset of those results that might be interesting or 376 erroneous). Spiders, for example, are typically given a start URI 377 and configured to follow certain behavior while crawling the Web as a 378 hypertext graph. 380 The implementation diversity of HTTP means that we cannot assume the 381 user agent can make interactive suggestions to a user or provide 382 adequate warning for security or privacy options. In the few cases 383 where this specification requires reporting of errors to the user, it 384 is acceptable for such reporting to only be observable in an error 385 console or log file. Likewise, requirements that an automated action 386 be confirmed by the user before proceeding might be met via advance 387 configuration choices, run-time options, or simple avoidance of the 388 unsafe action; confirmation does not imply any specific user 389 interface or interruption of normal processing if the user has 390 already made that choice. 392 2.3. Intermediaries 394 HTTP enables the use of intermediaries to satisfy requests through a 395 chain of connections. There are three common forms of HTTP 396 intermediary: proxy, gateway, and tunnel. In some cases, a single 397 intermediary might act as an origin server, proxy, gateway, or 398 tunnel, switching behavior based on the nature of each request. 400 > > > > 401 UA =========== A =========== B =========== C =========== O 402 < < < < 404 The figure above shows three intermediaries (A, B, and C) between the 405 user agent and origin server. A request or response message that 406 travels the whole chain will pass through four separate connections. 407 Some HTTP communication options might apply only to the connection 408 with the nearest, non-tunnel neighbor, only to the end-points of the 409 chain, or to all connections along the chain. Although the diagram 410 is linear, each participant might be engaged in multiple, 411 simultaneous communications. For example, B might be receiving 412 requests from many clients other than A, and/or forwarding requests 413 to servers other than C, at the same time that it is handling A's 414 request. Likewise, later requests might be sent through a different 415 path of connections, often based on dynamic configuration for load 416 balancing. 418 We use the terms "upstream" and "downstream" to describe various 419 requirements in relation to the directional flow of a message: all 420 messages flow from upstream to downstream. Likewise, we use the 421 terms inbound and outbound to refer to directions in relation to the 422 request path: "inbound" means toward the origin server and "outbound" 423 means toward the user agent. 425 A "proxy" is a message forwarding agent that is selected by the 426 client, usually via local configuration rules, to receive requests 427 for some type(s) of absolute URI and attempt to satisfy those 428 requests via translation through the HTTP interface. Some 429 translations are minimal, such as for proxy requests for "http" URIs, 430 whereas other requests might require translation to and from entirely 431 different application-level protocols. Proxies are often used to 432 group an organization's HTTP requests through a common intermediary 433 for the sake of security, annotation services, or shared caching. 435 An HTTP-to-HTTP proxy is called a "transforming proxy" if it is 436 designed or configured to modify request or response messages in a 437 semantically meaningful way (i.e., modifications, beyond those 438 required by normal HTTP processing, that change the message in a way 439 that would be significant to the original sender or potentially 440 significant to downstream recipients). For example, a transforming 441 proxy might be acting as a shared annotation server (modifying 442 responses to include references to a local annotation database), a 443 malware filter, a format transcoder, or an intranet-to-Internet 444 privacy filter. Such transformations are presumed to be desired by 445 the client (or client organization) that selected the proxy and are 446 beyond the scope of this specification. However, when a proxy is not 447 intended to transform a given message, we use the term "non- 448 transforming proxy" to target requirements that preserve HTTP message 449 semantics. See Section 6.3.4 of [Part2] and Section 7.5 of [Part6] 450 for status and warning codes related to transformations. 452 A "gateway" (a.k.a., "reverse proxy") is an intermediary that acts as 453 an origin server for the outbound connection, but translates received 454 requests and forwards them inbound to another server or servers. 455 Gateways are often used to encapsulate legacy or untrusted 456 information services, to improve server performance through 457 "accelerator" caching, and to enable partitioning or load balancing 458 of HTTP services across multiple machines. 460 All HTTP requirements applicable to an origin server also apply to 461 the outbound communication of a gateway. A gateway communicates with 462 inbound servers using any protocol that it desires, including private 463 extensions to HTTP that are outside the scope of this specification. 464 However, an HTTP-to-HTTP gateway that wishes to interoperate with 465 third-party HTTP servers ought to conform to user agent requirements 466 on the gateway's inbound connection. 468 A "tunnel" acts as a blind relay between two connections without 469 changing the messages. Once active, a tunnel is not considered a 470 party to the HTTP communication, though the tunnel might have been 471 initiated by an HTTP request. A tunnel ceases to exist when both 472 ends of the relayed connection are closed. Tunnels are used to 473 extend a virtual connection through an intermediary, such as when 474 Transport Layer Security (TLS, [RFC5246]) is used to establish 475 confidential communication through a shared firewall proxy. 477 The above categories for intermediary only consider those acting as 478 participants in the HTTP communication. There are also 479 intermediaries that can act on lower layers of the network protocol 480 stack, filtering or redirecting HTTP traffic without the knowledge or 481 permission of message senders. Network intermediaries often 482 introduce security flaws or interoperability problems by violating 483 HTTP semantics. For example, an "interception proxy" [RFC3040] (also 484 commonly known as a "transparent proxy" [RFC1919] or "captive 485 portal") differs from an HTTP proxy because it is not selected by the 486 client. Instead, an interception proxy filters or redirects outgoing 487 TCP port 80 packets (and occasionally other common port traffic). 488 Interception proxies are commonly found on public network access 489 points, as a means of enforcing account subscription prior to 490 allowing use of non-local Internet services, and within corporate 491 firewalls to enforce network usage policies. They are 492 indistinguishable from a man-in-the-middle attack. 494 HTTP is defined as a stateless protocol, meaning that each request 495 message can be understood in isolation. Many implementations depend 496 on HTTP's stateless design in order to reuse proxied connections or 497 dynamically load-balance requests across multiple servers. Hence, 498 servers MUST NOT assume that two requests on the same connection are 499 from the same user agent unless the connection is secured and 500 specific to that agent. Some non-standard HTTP extensions (e.g., 501 [RFC4559]) have been known to violate this requirement, resulting in 502 security and interoperability problems. 504 2.4. Caches 506 A "cache" is a local store of previous response messages and the 507 subsystem that controls its message storage, retrieval, and deletion. 508 A cache stores cacheable responses in order to reduce the response 509 time and network bandwidth consumption on future, equivalent 510 requests. Any client or server MAY employ a cache, though a cache 511 cannot be used by a server while it is acting as a tunnel. 513 The effect of a cache is that the request/response chain is shortened 514 if one of the participants along the chain has a cached response 515 applicable to that request. The following illustrates the resulting 516 chain if B has a cached copy of an earlier response from O (via C) 517 for a request that has not been cached by UA or A. 519 > > 520 UA =========== A =========== B - - - - - - C - - - - - - O 521 < < 523 A response is "cacheable" if a cache is allowed to store a copy of 524 the response message for use in answering subsequent requests. Even 525 when a response is cacheable, there might be additional constraints 526 placed by the client or by the origin server on when that cached 527 response can be used for a particular request. HTTP requirements for 528 cache behavior and cacheable responses are defined in Section 2 of 529 [Part6]. 531 There are a wide variety of architectures and configurations of 532 caches deployed across the World Wide Web and inside large 533 organizations. These include national hierarchies of proxy caches to 534 save transoceanic bandwidth, collaborative systems that broadcast or 535 multicast cache entries, archives of pre-fetched cache entries for 536 use in off-line or high-latency environments, and so on. 538 2.5. Conformance and Error Handling 540 This specification targets conformance criteria according to the role 541 of a participant in HTTP communication. Hence, HTTP requirements are 542 placed on senders, recipients, clients, servers, user agents, 543 intermediaries, origin servers, proxies, gateways, or caches, 544 depending on what behavior is being constrained by the requirement. 545 Additional (social) requirements are placed on implementations, 546 resource owners, and protocol element registrations when they apply 547 beyond the scope of a single communication. 549 The verb "generate" is used instead of "send" where a requirement 550 differentiates between creating a protocol element and merely 551 forwarding a received element downstream. 553 An implementation is considered conformant if it complies with all of 554 the requirements associated with the roles it partakes in HTTP. 556 Conformance applies to both the syntax and semantics of HTTP protocol 557 elements. A sender MUST NOT generate protocol elements that convey a 558 meaning that is known by that sender to be false. A sender MUST NOT 559 generate protocol elements that do not match the grammar defined by 560 the ABNF rules for those protocol elements that are applicable to the 561 sender's role. If a received protocol element is processed, the 562 recipient MUST be able to parse any value that would match the ABNF 563 rules for that protocol element, excluding only those rules not 564 applicable to the recipient's role. 566 Unless noted otherwise, a recipient MAY attempt to recover a usable 567 protocol element from an invalid construct. HTTP does not define 568 specific error handling mechanisms except when they have a direct 569 impact on security, since different applications of the protocol 570 require different error handling strategies. For example, a Web 571 browser might wish to transparently recover from a response where the 572 Location header field doesn't parse according to the ABNF, whereas a 573 systems control client might consider any form of error recovery to 574 be dangerous. 576 2.6. Protocol Versioning 578 HTTP uses a "." numbering scheme to indicate versions 579 of the protocol. This specification defines version "1.1". The 580 protocol version as a whole indicates the sender's conformance with 581 the set of requirements laid out in that version's corresponding 582 specification of HTTP. 584 The version of an HTTP message is indicated by an HTTP-version field 585 in the first line of the message. HTTP-version is case-sensitive. 587 HTTP-version = HTTP-name "/" DIGIT "." DIGIT 588 HTTP-name = %x48.54.54.50 ; "HTTP", case-sensitive 590 The HTTP version number consists of two decimal digits separated by a 591 "." (period or decimal point). The first digit ("major version") 592 indicates the HTTP messaging syntax, whereas the second digit ("minor 593 version") indicates the highest minor version within that major 594 version to which the sender is conformant and able to understand for 595 future communication. The minor version advertises the sender's 596 communication capabilities even when the sender is only using a 597 backwards-compatible subset of the protocol, thereby letting the 598 recipient know that more advanced features can be used in response 599 (by servers) or in future requests (by clients). 601 When an HTTP/1.1 message is sent to an HTTP/1.0 recipient [RFC1945] 602 or a recipient whose version is unknown, the HTTP/1.1 message is 603 constructed such that it can be interpreted as a valid HTTP/1.0 604 message if all of the newer features are ignored. This specification 605 places recipient-version requirements on some new features so that a 606 conformant sender will only use compatible features until it has 607 determined, through configuration or the receipt of a message, that 608 the recipient supports HTTP/1.1. 610 The interpretation of a header field does not change between minor 611 versions of the same major HTTP version, though the default behavior 612 of a recipient in the absence of such a field can change. Unless 613 specified otherwise, header fields defined in HTTP/1.1 are defined 614 for all versions of HTTP/1.x. In particular, the Host and Connection 615 header fields ought to be implemented by all HTTP/1.x implementations 616 whether or not they advertise conformance with HTTP/1.1. 618 New header fields can be defined such that, when they are understood 619 by a recipient, they might override or enhance the interpretation of 620 previously defined header fields. When an implementation receives an 621 unrecognized header field, the recipient MUST ignore that header 622 field for local processing regardless of the message's HTTP version. 623 An unrecognized header field received by a proxy MUST be forwarded 624 downstream unless the header field's field-name is listed in the 625 message's Connection header field (see Section 6.1). These 626 requirements allow HTTP's functionality to be enhanced without 627 requiring prior update of deployed intermediaries. 629 Intermediaries that process HTTP messages (i.e., all intermediaries 630 other than those acting as tunnels) MUST send their own HTTP-version 631 in forwarded messages. In other words, they MUST NOT blindly forward 632 the first line of an HTTP message without ensuring that the protocol 633 version in that message matches a version to which that intermediary 634 is conformant for both the receiving and sending of messages. 635 Forwarding an HTTP message without rewriting the HTTP-version might 636 result in communication errors when downstream recipients use the 637 message sender's version to determine what features are safe to use 638 for later communication with that sender. 640 A client SHOULD send a request version equal to the highest version 641 to which the client is conformant and whose major version is no 642 higher than the highest version supported by the server, if this is 643 known. A client MUST NOT send a version to which it is not 644 conformant. 646 A client MAY send a lower request version if it is known that the 647 server incorrectly implements the HTTP specification, but only after 648 the client has attempted at least one normal request and determined 649 from the response status or header fields (e.g., Server) that the 650 server improperly handles higher request versions. 652 A server SHOULD send a response version equal to the highest version 653 to which the server is conformant and whose major version is less 654 than or equal to the one received in the request. A server MUST NOT 655 send a version to which it is not conformant. A server MAY send a 656 505 (HTTP Version Not Supported) response if it cannot send a 657 response using the major version used in the client's request. 659 A server MAY send an HTTP/1.0 response to a request if it is known or 660 suspected that the client incorrectly implements the HTTP 661 specification and is incapable of correctly processing later version 662 responses, such as when a client fails to parse the version number 663 correctly or when an intermediary is known to blindly forward the 664 HTTP-version even when it doesn't conform to the given minor version 665 of the protocol. Such protocol downgrades SHOULD NOT be performed 666 unless triggered by specific client attributes, such as when one or 667 more of the request header fields (e.g., User-Agent) uniquely match 668 the values sent by a client known to be in error. 670 The intention of HTTP's versioning design is that the major number 671 will only be incremented if an incompatible message syntax is 672 introduced, and that the minor number will only be incremented when 673 changes made to the protocol have the effect of adding to the message 674 semantics or implying additional capabilities of the sender. 675 However, the minor version was not incremented for the changes 676 introduced between [RFC2068] and [RFC2616], and this revision has 677 specifically avoided any such changes to the protocol. 679 When an HTTP message is received with a major version number that the 680 recipient implements, but a higher minor version number than what the 681 recipient implements, the recipient SHOULD process the message as if 682 it were in the highest minor version within that major version to 683 which the recipient is conformant. A recipient can assume that a 684 message with a higher minor version, when sent to a recipient that 685 has not yet indicated support for that higher version, is 686 sufficiently backwards-compatible to be safely processed by any 687 implementation of the same major version. 689 2.7. Uniform Resource Identifiers 691 Uniform Resource Identifiers (URIs) [RFC3986] are used throughout 692 HTTP as the means for identifying resources (Section 2 of [Part2]). 693 URI references are used to target requests, indicate redirects, and 694 define relationships. 696 This specification adopts the definitions of "URI-reference", 697 "absolute-URI", "relative-part", "authority", "port", "host", "path- 698 abempty", "segment", "query", and "fragment" from the URI generic 699 syntax. In addition, we define an "absolute-path" rule (that differs 700 from RFC 3986's "path-absolute" in that it allows a leading "//") and 701 a "partial-URI" rule for protocol elements that allow a relative URI 702 but not a fragment. 704 URI-reference = 705 absolute-URI = 706 relative-part = 707 authority = 708 uri-host = 709 port = 710 path-abempty = 711 segment = 712 query = 713 fragment = 715 absolute-path = 1*( "/" segment ) 716 partial-URI = relative-part [ "?" query ] 718 Each protocol element in HTTP that allows a URI reference will 719 indicate in its ABNF production whether the element allows any form 720 of reference (URI-reference), only a URI in absolute form (absolute- 721 URI), only the path and optional query components, or some 722 combination of the above. Unless otherwise indicated, URI references 723 are parsed relative to the effective request URI (Section 5.5). 725 2.7.1. http URI scheme 727 The "http" URI scheme is hereby defined for the purpose of minting 728 identifiers according to their association with the hierarchical 729 namespace governed by a potential HTTP origin server listening for 730 TCP ([RFC0793]) connections on a given port. 732 http-URI = "http:" "//" authority path-abempty [ "?" query ] 733 [ "#" fragment ] 735 The HTTP origin server is identified by the generic syntax's 736 authority component, which includes a host identifier and optional 737 TCP port ([RFC3986], Section 3.2.2). The remainder of the URI, 738 consisting of both the hierarchical path component and optional query 739 component, serves as an identifier for a potential resource within 740 that origin server's name space. 742 If the host identifier is provided as an IP address, then the origin 743 server is any listener on the indicated TCP port at that IP address. 744 If host is a registered name, then that name is considered an 745 indirect identifier and the recipient might use a name resolution 746 service, such as DNS, to find the address of a listener for that 747 host. The host MUST NOT be empty; if an "http" URI is received with 748 an empty host, then it MUST be rejected as invalid. If the port 749 subcomponent is empty or not given, then TCP port 80 is assumed (the 750 default reserved port for WWW services). 752 Regardless of the form of host identifier, access to that host is not 753 implied by the mere presence of its name or address. The host might 754 or might not exist and, even when it does exist, might or might not 755 be running an HTTP server or listening to the indicated port. The 756 "http" URI scheme makes use of the delegated nature of Internet names 757 and addresses to establish a naming authority (whatever entity has 758 the ability to place an HTTP server at that Internet name or address) 759 and allows that authority to determine which names are valid and how 760 they might be used. 762 When an "http" URI is used within a context that calls for access to 763 the indicated resource, a client MAY attempt access by resolving the 764 host to an IP address, establishing a TCP connection to that address 765 on the indicated port, and sending an HTTP request message 766 (Section 3) containing the URI's identifying data (Section 5) to the 767 server. If the server responds to that request with a non-interim 768 HTTP response message, as described in Section 6 of [Part2], then 769 that response is considered an authoritative answer to the client's 770 request. 772 Although HTTP is independent of the transport protocol, the "http" 773 scheme is specific to TCP-based services because the name delegation 774 process depends on TCP for establishing authority. An HTTP service 775 based on some other underlying connection protocol would presumably 776 be identified using a different URI scheme, just as the "https" 777 scheme (below) is used for resources that require an end-to-end 778 secured connection. Other protocols might also be used to provide 779 access to "http" identified resources -- it is only the authoritative 780 interface that is specific to TCP. 782 The URI generic syntax for authority also includes a deprecated 783 userinfo subcomponent ([RFC3986], Section 3.2.1) for including user 784 authentication information in the URI. Some implementations make use 785 of the userinfo component for internal configuration of 786 authentication information, such as within command invocation 787 options, configuration files, or bookmark lists, even though such 788 usage might expose a user identifier or password. Senders MUST 789 exclude the userinfo subcomponent (and its "@" delimiter) when an 790 "http" URI is transmitted within a message as a request target or 791 header field value. Recipients of an "http" URI reference SHOULD 792 parse for userinfo and treat its presence as an error, since it is 793 likely being used to obscure the authority for the sake of phishing 794 attacks. 796 2.7.2. https URI scheme 798 The "https" URI scheme is hereby defined for the purpose of minting 799 identifiers according to their association with the hierarchical 800 namespace governed by a potential HTTP origin server listening to a 801 given TCP port for TLS-secured connections ([RFC0793], [RFC5246]). 803 All of the requirements listed above for the "http" scheme are also 804 requirements for the "https" scheme, except that a default TCP port 805 of 443 is assumed if the port subcomponent is empty or not given, and 806 the TCP connection MUST be secured, end-to-end, through the use of 807 strong encryption prior to sending the first HTTP request. 809 https-URI = "https:" "//" authority path-abempty [ "?" query ] 810 [ "#" fragment ] 812 Note that the "https" URI scheme depends on both TLS and TCP for 813 establishing authority. Resources made available via the "https" 814 scheme have no shared identity with the "http" scheme even if their 815 resource identifiers indicate the same authority (the same host 816 listening to the same TCP port). They are distinct name spaces and 817 are considered to be distinct origin servers. However, an extension 818 to HTTP that is defined to apply to entire host domains, such as the 819 Cookie protocol [RFC6265], can allow information set by one service 820 to impact communication with other services within a matching group 821 of host domains. 823 The process for authoritative access to an "https" identified 824 resource is defined in [RFC2818]. 826 2.7.3. http and https URI Normalization and Comparison 828 Since the "http" and "https" schemes conform to the URI generic 829 syntax, such URIs are normalized and compared according to the 830 algorithm defined in [RFC3986], Section 6, using the defaults 831 described above for each scheme. 833 If the port is equal to the default port for a scheme, the normal 834 form is to omit the port subcomponent. When not being used in 835 absolute form as the request target of an OPTIONS request, an empty 836 path component is equivalent to an absolute path of "/", so the 837 normal form is to provide a path of "/" instead. The scheme and host 838 are case-insensitive and normally provided in lowercase; all other 839 components are compared in a case-sensitive manner. Characters other 840 than those in the "reserved" set are equivalent to their percent- 841 encoded octets (see [RFC3986], Section 2.1): the normal form is to 842 not encode them. 844 For example, the following three URIs are equivalent: 846 http://example.com:80/~smith/home.html 847 http://EXAMPLE.com/%7Esmith/home.html 848 http://EXAMPLE.com:/%7esmith/home.html 850 3. Message Format 852 All HTTP/1.1 messages consist of a start-line followed by a sequence 853 of octets in a format similar to the Internet Message Format 854 [RFC5322]: zero or more header fields (collectively referred to as 855 the "headers" or the "header section"), an empty line indicating the 856 end of the header section, and an optional message body. 858 HTTP-message = start-line 859 *( header-field CRLF ) 860 CRLF 861 [ message-body ] 863 The normal procedure for parsing an HTTP message is to read the 864 start-line into a structure, read each header field into a hash table 865 by field name until the empty line, and then use the parsed data to 866 determine if a message body is expected. If a message body has been 867 indicated, then it is read as a stream until an amount of octets 868 equal to the message body length is read or the connection is closed. 870 Recipients MUST parse an HTTP message as a sequence of octets in an 871 encoding that is a superset of US-ASCII [USASCII]. Parsing an HTTP 872 message as a stream of Unicode characters, without regard for the 873 specific encoding, creates security vulnerabilities due to the 874 varying ways that string processing libraries handle invalid 875 multibyte character sequences that contain the octet LF (%x0A). 876 String-based parsers can only be safely used within protocol elements 877 after the element has been extracted from the message, such as within 878 a header field-value after message parsing has delineated the 879 individual fields. 881 An HTTP message can be parsed as a stream for incremental processing 882 or forwarding downstream. However, recipients cannot rely on 883 incremental delivery of partial messages, since some implementations 884 will buffer or delay message forwarding for the sake of network 885 efficiency, security checks, or payload transformations. 887 A sender MUST NOT send whitespace between the start-line and the 888 first header field. A recipient that receives whitespace between the 889 start-line and the first header field MUST either reject the message 890 as invalid or consume each whitespace-preceded line without further 891 processing of it (i.e., ignore the entire line, along with any 892 subsequent lines preceded by whitespace, until a properly formed 893 header field is received or the header block is terminated). 895 The presence of such whitespace in a request might be an attempt to 896 trick a server into ignoring that field or processing the line after 897 it as a new request, either of which might result in a security 898 vulnerability if other implementations within the request chain 899 interpret the same message differently. Likewise, the presence of 900 such whitespace in a response might be ignored by some clients or 901 cause others to cease parsing. 903 3.1. Start Line 905 An HTTP message can either be a request from client to server or a 906 response from server to client. Syntactically, the two types of 907 message differ only in the start-line, which is either a request-line 908 (for requests) or a status-line (for responses), and in the algorithm 909 for determining the length of the message body (Section 3.3). 911 In theory, a client could receive requests and a server could receive 912 responses, distinguishing them by their different start-line formats, 913 but in practice servers are implemented to only expect a request (a 914 response is interpreted as an unknown or invalid request method) and 915 clients are implemented to only expect a response. 917 start-line = request-line / status-line 919 3.1.1. Request Line 921 A request-line begins with a method token, followed by a single space 922 (SP), the request-target, another single space (SP), the protocol 923 version, and ending with CRLF. 925 request-line = method SP request-target SP HTTP-version CRLF 927 The method token indicates the request method to be performed on the 928 target resource. The request method is case-sensitive. 930 method = token 932 The methods defined by this specification can be found in Section 4 933 of [Part2], along with information regarding the HTTP method registry 934 and considerations for defining new methods. 936 The request-target identifies the target resource upon which to apply 937 the request, as defined in Section 5.3. 939 Recipients typically parse the request-line into its component parts 940 by splitting on whitespace (see Section 3.5), since no whitespace is 941 allowed in the three components. Unfortunately, some user agents 942 fail to properly encode or exclude whitespace found in hypertext 943 references, resulting in those disallowed characters being sent in a 944 request-target. 946 Recipients of an invalid request-line SHOULD respond with either a 947 400 (Bad Request) error or a 301 (Moved Permanently) redirect with 948 the request-target properly encoded. Recipients SHOULD NOT attempt 949 to autocorrect and then process the request without a redirect, since 950 the invalid request-line might be deliberately crafted to bypass 951 security filters along the request chain. 953 HTTP does not place a pre-defined limit on the length of a request- 954 line. A server that receives a method longer than any that it 955 implements SHOULD respond with a 501 (Not Implemented) status code. 956 A server MUST be prepared to receive URIs of unbounded length and 957 respond with the 414 (URI Too Long) status code if the received 958 request-target would be longer than the server wishes to handle (see 959 Section 6.5.12 of [Part2]). 961 Various ad-hoc limitations on request-line length are found in 962 practice. It is RECOMMENDED that all HTTP senders and recipients 963 support, at a minimum, request-line lengths of 8000 octets. 965 3.1.2. Status Line 967 The first line of a response message is the status-line, consisting 968 of the protocol version, a space (SP), the status code, another 969 space, a possibly-empty textual phrase describing the status code, 970 and ending with CRLF. 972 status-line = HTTP-version SP status-code SP reason-phrase CRLF 974 The status-code element is a 3-digit integer code describing the 975 result of the server's attempt to understand and satisfy the client's 976 corresponding request. The rest of the response message is to be 977 interpreted in light of the semantics defined for that status code. 978 See Section 6 of [Part2] for information about the semantics of 979 status codes, including the classes of status code (indicated by the 980 first digit), the status codes defined by this specification, 981 considerations for the definition of new status codes, and the IANA 982 registry. 984 status-code = 3DIGIT 986 The reason-phrase element exists for the sole purpose of providing a 987 textual description associated with the numeric status code, mostly 988 out of deference to earlier Internet application protocols that were 989 more frequently used with interactive text clients. A client SHOULD 990 ignore the reason-phrase content. 992 reason-phrase = *( HTAB / SP / VCHAR / obs-text ) 994 3.2. Header Fields 996 Each HTTP header field consists of a case-insensitive field name 997 followed by a colon (":"), optional leading whitespace, the field 998 value, and optional trailing whitespace. 1000 header-field = field-name ":" OWS field-value OWS 1001 field-name = token 1002 field-value = *( field-content / obs-fold ) 1003 field-content = *( HTAB / SP / VCHAR / obs-text ) 1004 obs-fold = CRLF ( SP / HTAB ) 1005 ; obsolete line folding 1006 ; see Section 3.2.4 1008 The field-name token labels the corresponding field-value as having 1009 the semantics defined by that header field. For example, the Date 1010 header field is defined in Section 7.1.1.2 of [Part2] as containing 1011 the origination timestamp for the message in which it appears. 1013 3.2.1. Field Extensibility 1015 HTTP header fields are fully extensible: there is no limit on the 1016 introduction of new field names, each presumably defining new 1017 semantics, nor on the number of header fields used in a given 1018 message. Existing fields are defined in each part of this 1019 specification and in many other specifications outside the core 1020 standard. New header fields can be introduced without changing the 1021 protocol version if their defined semantics allow them to be safely 1022 ignored by recipients that do not recognize them. 1024 New HTTP header fields ought to be registered with IANA in the 1025 Message Header Field Registry, as described in Section 8.3 of 1026 [Part2]. A proxy MUST forward unrecognized header fields unless the 1027 field-name is listed in the Connection header field (Section 6.1) or 1028 the proxy is specifically configured to block, or otherwise 1029 transform, such fields. Other recipients SHOULD ignore unrecognized 1030 header fields. 1032 3.2.2. Field Order 1034 The order in which header fields with differing field names are 1035 received is not significant. However, it is "good practice" to send 1036 header fields that contain control data first, such as Host on 1037 requests and Date on responses, so that implementations can decide 1038 when not to handle a message as early as possible. A server MUST 1039 wait until the entire header section is received before interpreting 1040 a request message, since later header fields might include 1041 conditionals, authentication credentials, or deliberately misleading 1042 duplicate header fields that would impact request processing. 1044 A sender MUST NOT generate multiple header fields with the same field 1045 name in a message unless either the entire field value for that 1046 header field is defined as a comma-separated list [i.e., #(values)] 1047 or the header field is a well-known exception (as noted below). 1049 Multiple header fields with the same field name can be combined into 1050 one "field-name: field-value" pair, without changing the semantics of 1051 the message, by appending each subsequent field value to the combined 1052 field value in order, separated by a comma. The order in which 1053 header fields with the same field name are received is therefore 1054 significant to the interpretation of the combined field value; a 1055 proxy MUST NOT change the order of these field values when forwarding 1056 a message. 1058 Note: In practice, the "Set-Cookie" header field ([RFC6265]) often 1059 appears multiple times in a response message and does not use the 1060 list syntax, violating the above requirements on multiple header 1061 fields with the same name. Since it cannot be combined into a 1062 single field-value, recipients ought to handle "Set-Cookie" as a 1063 special case while processing header fields. (See Appendix A.2.3 1064 of [Kri2001] for details.) 1066 3.2.3. Whitespace 1068 This specification uses three rules to denote the use of linear 1069 whitespace: OWS (optional whitespace), RWS (required whitespace), and 1070 BWS ("bad" whitespace). 1072 The OWS rule is used where zero or more linear whitespace octets 1073 might appear. For protocol elements where optional whitespace is 1074 preferred to improve readability, a sender SHOULD generate the 1075 optional whitespace as a single SP; otherwise, a sender SHOULD NOT 1076 generate optional whitespace except as needed to white-out invalid or 1077 unwanted protocol elements during in-place message filtering. 1079 The RWS rule is used when at least one linear whitespace octet is 1080 required to separate field tokens. A sender SHOULD generate RWS as a 1081 single SP. 1083 The BWS rule is used where the grammar allows optional whitespace 1084 only for historical reasons. A sender MUST NOT generate BWS in 1085 messages. A recipient MUST parse for such bad whitespace and remove 1086 it before interpreting the protocol element. 1088 OWS = *( SP / HTAB ) 1089 ; optional whitespace 1090 RWS = 1*( SP / HTAB ) 1091 ; required whitespace 1092 BWS = OWS 1093 ; "bad" whitespace 1095 3.2.4. Field Parsing 1097 No whitespace is allowed between the header field-name and colon. In 1098 the past, differences in the handling of such whitespace have led to 1099 security vulnerabilities in request routing and response handling. A 1100 server MUST reject any received request message that contains 1101 whitespace between a header field-name and colon with a response code 1102 of 400 (Bad Request). A proxy MUST remove any such whitespace from a 1103 response message before forwarding the message downstream. 1105 A field value is preceded by optional whitespace (OWS); a single SP 1106 is preferred. The field value does not include any leading or 1107 trailing white space: OWS occurring before the first non-whitespace 1108 octet of the field value or after the last non-whitespace octet of 1109 the field value ought to be excluded by parsers when extracting the 1110 field value from a header field. 1112 A recipient of field-content containing multiple sequential octets of 1113 optional (OWS) or required (RWS) whitespace SHOULD either replace the 1114 sequence with a single SP or transform any non-SP octets in the 1115 sequence to SP octets before interpreting the field value or 1116 forwarding the message downstream. 1118 Historically, HTTP header field values could be extended over 1119 multiple lines by preceding each extra line with at least one space 1120 or horizontal tab (obs-fold). This specification deprecates such 1121 line folding except within the message/http media type 1122 (Section 7.3.1). Senders MUST NOT generate messages that include 1123 line folding (i.e., that contain any field-value that contains a 1124 match to the obs-fold rule) unless the message is intended for 1125 packaging within the message/http media type. 1127 A server that receives an obs-fold in a request message that is not 1128 within a message/http container MUST either reject the message by 1129 sending a 400 (Bad Request), preferably with a representation 1130 explaining that obsolete line folding is unacceptable, or replace 1131 each received obs-fold with one or more SP octets prior to 1132 interpreting the field value or forwarding the message downstream. 1134 A proxy or gateway that receives an obs-fold in a response message 1135 that is not within a message/http container MUST either discard the 1136 message and replace it with a 502 (Bad Gateway) response, preferably 1137 with a representation explaining that unacceptable line folding was 1138 received, or replace each received obs-fold with one or more SP 1139 octets prior to interpreting the field value or forwarding the 1140 message downstream. 1142 A user agent that receives an obs-fold in a response message that is 1143 not within a message/http container MUST replace each received obs- 1144 fold with one or more SP octets prior to interpreting the field 1145 value. 1147 Historically, HTTP has allowed field content with text in the ISO- 1148 8859-1 [ISO-8859-1] charset, supporting other charsets only through 1149 use of [RFC2047] encoding. In practice, most HTTP header field 1150 values use only a subset of the US-ASCII charset [USASCII]. Newly 1151 defined header fields SHOULD limit their field values to US-ASCII 1152 octets. Recipients SHOULD treat other octets in field content (obs- 1153 text) as opaque data. 1155 3.2.5. Field Limits 1157 HTTP does not place a pre-defined limit on the length of each header 1158 field or on the length of the header block as a whole. Various ad- 1159 hoc limitations on individual header field length are found in 1160 practice, often depending on the specific field semantics. 1162 A server MUST be prepared to receive request header fields of 1163 unbounded length and respond with an appropriate 4xx (Client Error) 1164 status code if the received header field(s) are larger than the 1165 server wishes to process. 1167 A client MUST be prepared to receive response header fields of 1168 unbounded length. A client MAY discard or truncate received header 1169 fields that are larger than the client wishes to process if the field 1170 semantics are such that the dropped value(s) can be safely ignored 1171 without changing the response semantics. 1173 3.2.6. Field value components 1175 Many HTTP header field values consist of words (token or quoted- 1176 string) separated by whitespace or special characters. These special 1177 characters MUST be in a quoted string to be used within a parameter 1178 value (as defined in Section 4). 1180 word = token / quoted-string 1182 token = 1*tchar 1184 tchar = "!" / "#" / "$" / "%" / "&" / "'" / "*" 1185 / "+" / "-" / "." / "^" / "_" / "`" / "|" / "~" 1186 / DIGIT / ALPHA 1187 ; any VCHAR, except special 1189 special = "(" / ")" / "<" / ">" / "@" / "," 1190 / ";" / ":" / "\" / DQUOTE / "/" / "[" 1191 / "]" / "?" / "=" / "{" / "}" 1193 A string of text is parsed as a single word if it is quoted using 1194 double-quote marks. 1196 quoted-string = DQUOTE *( qdtext / quoted-pair ) DQUOTE 1197 qdtext = HTAB / SP /%x21 / %x23-5B / %x5D-7E / obs-text 1198 obs-text = %x80-FF 1200 The backslash octet ("\") can be used as a single-octet quoting 1201 mechanism within quoted-string constructs: 1203 quoted-pair = "\" ( HTAB / SP / VCHAR / obs-text ) 1205 Recipients that process the value of a quoted-string MUST handle a 1206 quoted-pair as if it were replaced by the octet following the 1207 backslash. 1209 Senders SHOULD NOT generate a quoted-pair in a quoted-string except 1210 where necessary to quote DQUOTE and backslash octets occurring within 1211 that string. 1213 Comments can be included in some HTTP header fields by surrounding 1214 the comment text with parentheses. Comments are only allowed in 1215 fields containing "comment" as part of their field value definition. 1217 comment = "(" *( ctext / quoted-cpair / comment ) ")" 1218 ctext = HTAB / SP / %x21-27 / %x2A-5B / %x5D-7E / obs-text 1220 The backslash octet ("\") can be used as a single-octet quoting 1221 mechanism within comment constructs: 1223 quoted-cpair = "\" ( HTAB / SP / VCHAR / obs-text ) 1225 Senders SHOULD NOT escape octets in comments that do not require 1226 escaping (i.e., other than the backslash octet "\" and the 1227 parentheses "(" and ")"). 1229 3.3. Message Body 1231 The message body (if any) of an HTTP message is used to carry the 1232 payload body of that request or response. The message body is 1233 identical to the payload body unless a transfer coding has been 1234 applied, as described in Section 3.3.1. 1236 message-body = *OCTET 1238 The rules for when a message body is allowed in a message differ for 1239 requests and responses. 1241 The presence of a message body in a request is signaled by a Content- 1242 Length or Transfer-Encoding header field. Request message framing is 1243 independent of method semantics, even if the method does not define 1244 any use for a message body. 1246 The presence of a message body in a response depends on both the 1247 request method to which it is responding and the response status code 1248 (Section 3.1.2). Responses to the HEAD request method never include 1249 a message body because the associated response header fields (e.g., 1250 Transfer-Encoding, Content-Length, etc.), if present, indicate only 1251 what their values would have been if the request method had been GET 1252 (Section 4.3.2 of [Part2]). 2xx (Successful) responses to CONNECT 1253 switch to tunnel mode instead of having a message body (Section 4.3.6 1254 of [Part2]). All 1xx (Informational), 204 (No Content), and 304 (Not 1255 Modified) responses do not include a message body. All other 1256 responses do include a message body, although the body might be of 1257 zero length. 1259 3.3.1. Transfer-Encoding 1261 The Transfer-Encoding header field lists the transfer coding names 1262 corresponding to the sequence of transfer codings that have been (or 1263 will be) applied to the payload body in order to form the message 1264 body. Transfer codings are defined in Section 4. 1266 Transfer-Encoding = 1#transfer-coding 1268 Transfer-Encoding is analogous to the Content-Transfer-Encoding field 1269 of MIME, which was designed to enable safe transport of binary data 1270 over a 7-bit transport service ([RFC2045], Section 6). However, safe 1271 transport has a different focus for an 8bit-clean transfer protocol. 1272 In HTTP's case, Transfer-Encoding is primarily intended to accurately 1273 delimit a dynamically generated payload and to distinguish payload 1274 encodings that are only applied for transport efficiency or security 1275 from those that are characteristics of the selected resource. 1277 All HTTP/1.1 recipients MUST implement the chunked transfer coding 1278 (Section 4.1) because it plays a crucial role in framing messages 1279 when the payload body size is not known in advance. If chunked is 1280 applied to a payload body, the sender MUST NOT apply chunked more 1281 than once (i.e., chunking an already chunked message is not allowed). 1282 If any transfer coding is applied to a request payload body, the 1283 sender MUST apply chunked as the final transfer coding to ensure that 1284 the message is properly framed. If any transfer coding is applied to 1285 a response payload body, the sender MUST either apply chunked as the 1286 final transfer coding or terminate the message by closing the 1287 connection. 1289 For example, 1291 Transfer-Encoding: gzip, chunked 1293 indicates that the payload body has been compressed using the gzip 1294 coding and then chunked using the chunked coding while forming the 1295 message body. 1297 Unlike Content-Encoding (Section 3.1.2.1 of [Part2]), Transfer- 1298 Encoding is a property of the message, not of the representation, and 1299 any recipient along the request/response chain MAY decode the 1300 received transfer coding(s) or apply additional transfer coding(s) to 1301 the message body, assuming that corresponding changes are made to the 1302 Transfer-Encoding field-value. Additional information about the 1303 encoding parameters MAY be provided by other header fields not 1304 defined by this specification. 1306 Transfer-Encoding MAY be sent in a response to a HEAD request or in a 1307 304 (Not Modified) response (Section 4.1 of [Part4]) to a GET 1308 request, neither of which includes a message body, to indicate that 1309 the origin server would have applied a transfer coding to the message 1310 body if the request had been an unconditional GET. This indication 1311 is not required, however, because any recipient on the response chain 1312 (including the origin server) can remove transfer codings when they 1313 are not needed. 1315 Transfer-Encoding was added in HTTP/1.1. It is generally assumed 1316 that implementations advertising only HTTP/1.0 support will not 1317 understand how to process a transfer-encoded payload. A client MUST 1318 NOT send a request containing Transfer-Encoding unless it knows the 1319 server will handle HTTP/1.1 (or later) requests; such knowledge might 1320 be in the form of specific user configuration or by remembering the 1321 version of a prior received response. A server MUST NOT send a 1322 response containing Transfer-Encoding unless the corresponding 1323 request indicates HTTP/1.1 (or later). 1325 A server that receives a request message with a transfer coding it 1326 does not understand SHOULD respond with 501 (Not Implemented). 1328 3.3.2. Content-Length 1330 When a message does not have a Transfer-Encoding header field, a 1331 Content-Length header field can provide the anticipated size, as a 1332 decimal number of octets, for a potential payload body. For messages 1333 that do include a payload body, the Content-Length field-value 1334 provides the framing information necessary for determining where the 1335 body (and message) ends. For messages that do not include a payload 1336 body, the Content-Length indicates the size of the selected 1337 representation (Section 3 of [Part2]). 1339 Content-Length = 1*DIGIT 1341 An example is 1343 Content-Length: 3495 1345 A sender MUST NOT send a Content-Length header field in any message 1346 that contains a Transfer-Encoding header field. 1348 A user agent SHOULD send a Content-Length in a request message when 1349 no Transfer-Encoding is sent and the request method defines a meaning 1350 for an enclosed payload body. For example, a Content-Length header 1351 field is normally sent in a POST request even when the value is 0 1352 (indicating an empty payload body). A user agent SHOULD NOT send a 1353 Content-Length header field when the request message does not contain 1354 a payload body and the method semantics do not anticipate such a 1355 body. 1357 A server MAY send a Content-Length header field in a response to a 1358 HEAD request (Section 4.3.2 of [Part2]); a server MUST NOT send 1359 Content-Length in such a response unless its field-value equals the 1360 decimal number of octets that would have been sent in the payload 1361 body of a response if the same request had used the GET method. 1363 A server MAY send a Content-Length header field in a 304 (Not 1364 Modified) response to a conditional GET request (Section 4.1 of 1365 [Part4]); a server MUST NOT send Content-Length in such a response 1366 unless its field-value equals the decimal number of octets that would 1367 have been sent in the payload body of a 200 (OK) response to the same 1368 request. 1370 A server MUST NOT send a Content-Length header field in any response 1371 with a status code of 1xx (Informational) or 204 (No Content). A 1372 server SHOULD NOT send a Content-Length header field in any 2xx 1373 (Successful) response to a CONNECT request (Section 4.3.6 of 1374 [Part2]). 1376 Aside from the cases defined above, in the absence of Transfer- 1377 Encoding, an origin server SHOULD send a Content-Length header field 1378 when the payload body size is known prior to sending the complete 1379 header block. This will allow downstream recipients to measure 1380 transfer progress, know when a received message is complete, and 1381 potentially reuse the connection for additional requests. 1383 Any Content-Length field value greater than or equal to zero is 1384 valid. Since there is no predefined limit to the length of a 1385 payload, recipients SHOULD anticipate potentially large decimal 1386 numerals and prevent parsing errors due to integer conversion 1387 overflows (Section 8.3). 1389 If a message is received that has multiple Content-Length header 1390 fields with field-values consisting of the same decimal value, or a 1391 single Content-Length header field with a field value containing a 1392 list of identical decimal values (e.g., "Content-Length: 42, 42"), 1393 indicating that duplicate Content-Length header fields have been 1394 generated or combined by an upstream message processor, then the 1395 recipient MUST either reject the message as invalid or replace the 1396 duplicated field-values with a single valid Content-Length field 1397 containing that decimal value prior to determining the message body 1398 length. 1400 Note: HTTP's use of Content-Length for message framing differs 1401 significantly from the same field's use in MIME, where it is an 1402 optional field used only within the "message/external-body" media- 1403 type. 1405 3.3.3. Message Body Length 1407 The length of a message body is determined by one of the following 1408 (in order of precedence): 1410 1. Any response to a HEAD request and any response with a 1xx 1411 (Informational), 204 (No Content), or 304 (Not Modified) status 1412 code is always terminated by the first empty line after the 1413 header fields, regardless of the header fields present in the 1414 message, and thus cannot contain a message body. 1416 2. Any 2xx (Successful) response to a CONNECT request implies that 1417 the connection will become a tunnel immediately after the empty 1418 line that concludes the header fields. A client MUST ignore any 1419 Content-Length or Transfer-Encoding header fields received in 1420 such a message. 1422 3. If a Transfer-Encoding header field is present and the chunked 1423 transfer coding (Section 4.1) is the final encoding, the message 1424 body length is determined by reading and decoding the chunked 1425 data until the transfer coding indicates the data is complete. 1427 If a Transfer-Encoding header field is present in a response and 1428 the chunked transfer coding is not the final encoding, the 1429 message body length is determined by reading the connection until 1430 it is closed by the server. If a Transfer-Encoding header field 1431 is present in a request and the chunked transfer coding is not 1432 the final encoding, the message body length cannot be determined 1433 reliably; the server MUST respond with the 400 (Bad Request) 1434 status code and then close the connection. 1436 If a message is received with both a Transfer-Encoding and a 1437 Content-Length header field, the Transfer-Encoding overrides the 1438 Content-Length. Such a message might indicate an attempt to 1439 perform request or response smuggling (bypass of security-related 1440 checks on message routing or content) and thus ought to be 1441 handled as an error. A sender MUST remove the received Content- 1442 Length field prior to forwarding such a message downstream. 1444 4. If a message is received without Transfer-Encoding and with 1445 either multiple Content-Length header fields having differing 1446 field-values or a single Content-Length header field having an 1447 invalid value, then the message framing is invalid and MUST be 1448 treated as an error to prevent request or response smuggling. If 1449 this is a request message, the server MUST respond with a 400 1450 (Bad Request) status code and then close the connection. If this 1451 is a response message received by a proxy, the proxy MUST close 1452 the connection to the server, discard the received response, and 1453 send a 502 (Bad Gateway) response to the client. If this is a 1454 response message received by a user agent, it MUST be treated as 1455 an error by discarding the message and closing the connection. 1457 5. If a valid Content-Length header field is present without 1458 Transfer-Encoding, its decimal value defines the expected message 1459 body length in octets. If the sender closes the connection or 1460 the recipient times out before the indicated number of octets are 1461 received, the recipient MUST consider the message to be 1462 incomplete and close the connection. 1464 6. If this is a request message and none of the above are true, then 1465 the message body length is zero (no message body is present). 1467 7. Otherwise, this is a response message without a declared message 1468 body length, so the message body length is determined by the 1469 number of octets received prior to the server closing the 1470 connection. 1472 Since there is no way to distinguish a successfully completed, close- 1473 delimited message from a partially-received message interrupted by 1474 network failure, a server SHOULD use encoding or length-delimited 1475 messages whenever possible. The close-delimiting feature exists 1476 primarily for backwards compatibility with HTTP/1.0. 1478 A server MAY reject a request that contains a message body but not a 1479 Content-Length by responding with 411 (Length Required). 1481 Unless a transfer coding other than chunked has been applied, a 1482 client that sends a request containing a message body SHOULD use a 1483 valid Content-Length header field if the message body length is known 1484 in advance, rather than the chunked transfer coding, since some 1485 existing services respond to chunked with a 411 (Length Required) 1486 status code even though they understand the chunked transfer coding. 1487 This is typically because such services are implemented via a gateway 1488 that requires a content-length in advance of being called and the 1489 server is unable or unwilling to buffer the entire request before 1490 processing. 1492 A user agent that sends a request containing a message body MUST send 1493 a valid Content-Length header field if it does not know the server 1494 will handle HTTP/1.1 (or later) requests; such knowledge can be in 1495 the form of specific user configuration or by remembering the version 1496 of a prior received response. 1498 If the final response to the last request on a connection has been 1499 completely received and there remains additional data to read, a user 1500 agent MAY discard the remaining data or attempt to determine if that 1501 data belongs as part of the prior response body, which might be the 1502 case if the prior message's Content-Length value is incorrect. A 1503 client MUST NOT process, cache, or forward such extra data as a 1504 separate response, since such behavior would be vulnerable to cache 1505 poisoning. 1507 3.4. Handling Incomplete Messages 1509 A server that receives an incomplete request message, usually due to 1510 a canceled request or a triggered time-out exception, MAY send an 1511 error response prior to closing the connection. 1513 A client that receives an incomplete response message, which can 1514 occur when a connection is closed prematurely or when decoding a 1515 supposedly chunked transfer coding fails, MUST record the message as 1516 incomplete. Cache requirements for incomplete responses are defined 1517 in Section 3 of [Part6]. 1519 If a response terminates in the middle of the header block (before 1520 the empty line is received) and the status code might rely on header 1521 fields to convey the full meaning of the response, then the client 1522 cannot assume that meaning has been conveyed; the client might need 1523 to repeat the request in order to determine what action to take next. 1525 A message body that uses the chunked transfer coding is incomplete if 1526 the zero-sized chunk that terminates the encoding has not been 1527 received. A message that uses a valid Content-Length is incomplete 1528 if the size of the message body received (in octets) is less than the 1529 value given by Content-Length. A response that has neither chunked 1530 transfer coding nor Content-Length is terminated by closure of the 1531 connection, and thus is considered complete regardless of the number 1532 of message body octets received, provided that the header block was 1533 received intact. 1535 3.5. Message Parsing Robustness 1537 Older HTTP/1.0 user agent implementations might send an extra CRLF 1538 after a POST request as a workaround for some early server 1539 applications that failed to read message body content that was not 1540 terminated by a line-ending. An HTTP/1.1 user agent MUST NOT preface 1541 or follow a request with an extra CRLF. If terminating the request 1542 message body with a line-ending is desired, then the user agent MUST 1543 count the terminating CRLF octets as part of the message body length. 1545 In the interest of robustness, servers SHOULD ignore at least one 1546 empty line received where a request-line is expected. In other 1547 words, if a server is reading the protocol stream at the beginning of 1548 a message and receives a CRLF first, the server SHOULD ignore the 1549 CRLF. 1551 Although the line terminator for the start-line and header fields is 1552 the sequence CRLF, recipients MAY recognize a single LF as a line 1553 terminator and ignore any preceding CR. 1555 Although the request-line and status-line grammar rules require that 1556 each of the component elements be separated by a single SP octet, 1557 recipients MAY instead parse on whitespace-delimited word boundaries 1558 and, aside from the CRLF terminator, treat any form of whitespace as 1559 the SP separator while ignoring preceding or trailing whitespace; 1560 such whitespace includes one or more of the following octets: SP, 1561 HTAB, VT (%x0B), FF (%x0C), or bare CR. 1563 When a server listening only for HTTP request messages, or processing 1564 what appears from the start-line to be an HTTP request message, 1565 receives a sequence of octets that does not match the HTTP-message 1566 grammar aside from the robustness exceptions listed above, the server 1567 SHOULD respond with a 400 (Bad Request) response. 1569 4. Transfer Codings 1571 Transfer coding names are used to indicate an encoding transformation 1572 that has been, can be, or might need to be applied to a payload body 1573 in order to ensure "safe transport" through the network. This 1574 differs from a content coding in that the transfer coding is a 1575 property of the message rather than a property of the representation 1576 that is being transferred. 1578 transfer-coding = "chunked" ; Section 4.1 1579 / "compress" ; Section 4.2.1 1580 / "deflate" ; Section 4.2.2 1581 / "gzip" ; Section 4.2.3 1582 / transfer-extension 1583 transfer-extension = token *( OWS ";" OWS transfer-parameter ) 1585 Parameters are in the form of attribute/value pairs. 1587 transfer-parameter = attribute BWS "=" BWS value 1588 attribute = token 1589 value = word 1591 All transfer-coding names are case-insensitive and ought to be 1592 registered within the HTTP Transfer Coding registry, as defined in 1593 Section 7.4. They are used in the TE (Section 4.3) and Transfer- 1594 Encoding (Section 3.3.1) header fields. 1596 4.1. Chunked Transfer Coding 1598 The chunked transfer coding modifies the body of a message in order 1599 to transfer it as a series of chunks, each with its own size 1600 indicator, followed by an OPTIONAL trailer containing header fields. 1601 This allows dynamically generated content to be transferred along 1602 with the information necessary for the recipient to verify that it 1603 has received the full message. 1605 chunked-body = *chunk 1606 last-chunk 1607 trailer-part 1608 CRLF 1610 chunk = chunk-size [ chunk-ext ] CRLF 1611 chunk-data CRLF 1612 chunk-size = 1*HEXDIG 1613 last-chunk = 1*("0") [ chunk-ext ] CRLF 1615 chunk-ext = *( ";" chunk-ext-name [ "=" chunk-ext-val ] ) 1616 chunk-ext-name = token 1617 chunk-ext-val = token / quoted-str-nf 1618 chunk-data = 1*OCTET ; a sequence of chunk-size octets 1619 trailer-part = *( header-field CRLF ) 1621 quoted-str-nf = DQUOTE *( qdtext-nf / quoted-pair ) DQUOTE 1622 ; like quoted-string, but disallowing line folding 1623 qdtext-nf = HTAB / SP / %x21 / %x23-5B / %x5D-7E / obs-text 1625 Chunk extensions within the chunked transfer coding are deprecated. 1626 Senders SHOULD NOT send chunk-ext. Definition of new chunk 1627 extensions is discouraged. 1629 The chunk-size field is a string of hex digits indicating the size of 1630 the chunk-data in octets. The chunked transfer coding is complete 1631 when a chunk with a chunk-size of zero is received, possibly followed 1632 by a trailer, and finally terminated by an empty line. 1634 4.1.1. Trailer 1636 A trailer allows the sender to include additional fields at the end 1637 of a chunked message in order to supply metadata that might be 1638 dynamically generated while the message body is sent, such as a 1639 message integrity check, digital signature, or post-processing 1640 status. The trailer MUST NOT contain fields that need to be known 1641 before a recipient processes the body, such as Transfer-Encoding, 1642 Content-Length, and Trailer. 1644 When a message includes a message body encoded with the chunked 1645 transfer coding and the sender desires to send metadata in the form 1646 of trailer fields at the end of the message, the sender SHOULD send a 1647 Trailer header field before the message body to indicate which fields 1648 will be present in the trailers. This allows the recipient to 1649 prepare for receipt of that metadata before it starts processing the 1650 body, which is useful if the message is being streamed and the 1651 recipient wishes to confirm an integrity check on the fly. 1653 Trailer = 1#field-name 1655 If no Trailer header field is present, the sender of a chunked 1656 message body SHOULD send an empty trailer. 1658 A server MUST send an empty trailer with the chunked transfer coding 1659 unless at least one of the following is true: 1661 1. the request included a TE header field that indicates "trailers" 1662 is acceptable in the transfer coding of the response, as 1663 described in Section 4.3; or, 1665 2. the trailer fields consist entirely of optional metadata and the 1666 recipient could use the message (in a manner acceptable to the 1667 server where the field originated) without receiving that 1668 metadata. In other words, the server that generated the header 1669 field is willing to accept the possibility that the trailer 1670 fields might be silently discarded along the path to the client. 1672 The above requirement prevents the need for an infinite buffer when a 1673 message is being received by an HTTP/1.1 (or later) proxy and 1674 forwarded to an HTTP/1.0 recipient. 1676 4.1.2. Decoding chunked 1678 A process for decoding the chunked transfer coding can be represented 1679 in pseudo-code as: 1681 length := 0 1682 read chunk-size, chunk-ext (if any), and CRLF 1683 while (chunk-size > 0) { 1684 read chunk-data and CRLF 1685 append chunk-data to decoded-body 1686 length := length + chunk-size 1687 read chunk-size, chunk-ext (if any), and CRLF 1688 } 1689 read header-field 1690 while (header-field not empty) { 1691 append header-field to existing header fields 1692 read header-field 1693 } 1694 Content-Length := length 1695 Remove "chunked" from Transfer-Encoding 1696 Remove Trailer from existing header fields 1698 All recipients MUST be able to receive and decode the chunked 1699 transfer coding and MUST ignore chunk-ext extensions they do not 1700 understand. 1702 4.2. Compression Codings 1704 The codings defined below can be used to compress the payload of a 1705 message. 1707 4.2.1. Compress Coding 1709 The "compress" coding is an adaptive Lempel-Ziv-Welch (LZW) coding 1710 [Welch] that is commonly produced by the UNIX file compression 1711 program "compress". Recipients SHOULD consider "x-compress" to be 1712 equivalent to "compress". 1714 4.2.2. Deflate Coding 1716 The "deflate" coding is a "zlib" data format [RFC1950] containing a 1717 "deflate" compressed data stream [RFC1951] that uses a combination of 1718 the Lempel-Ziv (LZ77) compression algorithm and Huffman coding. 1720 Note: Some incorrect implementations send the "deflate" compressed 1721 data without the zlib wrapper. 1723 4.2.3. Gzip Coding 1725 The "gzip" coding is an LZ77 coding with a 32 bit CRC that is 1726 commonly produced by the gzip file compression program [RFC1952]. 1727 Recipients SHOULD consider "x-gzip" to be equivalent to "gzip". 1729 4.3. TE 1731 The "TE" header field in a request indicates what transfer codings, 1732 besides chunked, the client is willing to accept in response, and 1733 whether or not the client is willing to accept trailer fields in a 1734 chunked transfer coding. 1736 The TE field-value consists of a comma-separated list of transfer 1737 coding names, each allowing for optional parameters (as described in 1738 Section 4), and/or the keyword "trailers". Clients MUST NOT send the 1739 chunked transfer coding name in TE; chunked is always acceptable for 1740 HTTP/1.1 recipients. 1742 TE = #t-codings 1743 t-codings = "trailers" / ( transfer-coding [ t-ranking ] ) 1744 t-ranking = OWS ";" OWS "q=" rank 1745 rank = ( "0" [ "." 0*3DIGIT ] ) 1746 / ( "1" [ "." 0*3("0") ] ) 1748 Three examples of TE use are below. 1750 TE: deflate 1751 TE: 1752 TE: trailers, deflate;q=0.5 1754 The presence of the keyword "trailers" indicates that the client is 1755 willing to accept trailer fields in a chunked transfer coding, as 1756 defined in Section 4.1, on behalf of itself and any downstream 1757 clients. For requests from an intermediary, this implies that 1758 either: (a) all downstream clients are willing to accept trailer 1759 fields in the forwarded response; or, (b) the intermediary will 1760 attempt to buffer the response on behalf of downstream recipients. 1761 Note that HTTP/1.1 does not define any means to limit the size of a 1762 chunked response such that an intermediary can be assured of 1763 buffering the entire response. 1765 When multiple transfer codings are acceptable, the client MAY rank 1766 the codings by preference using a case-insensitive "q" parameter 1767 (similar to the qvalues used in content negotiation fields, Section 1768 5.3.1 of [Part2]). The rank value is a real number in the range 0 1769 through 1, where 0.001 is the least preferred and 1 is the most 1770 preferred; a value of 0 means "not acceptable". 1772 If the TE field-value is empty or if no TE field is present, the only 1773 acceptable transfer coding is chunked. A message with no transfer 1774 coding is always acceptable. 1776 Since the TE header field only applies to the immediate connection, a 1777 sender of TE MUST also send a "TE" connection option within the 1778 Connection header field (Section 6.1) in order to prevent the TE 1779 field from being forwarded by intermediaries that do not support its 1780 semantics. 1782 5. Message Routing 1784 HTTP request message routing is determined by each client based on 1785 the target resource, the client's proxy configuration, and 1786 establishment or reuse of an inbound connection. The corresponding 1787 response routing follows the same connection chain back to the 1788 client. 1790 5.1. Identifying a Target Resource 1792 HTTP is used in a wide variety of applications, ranging from general- 1793 purpose computers to home appliances. In some cases, communication 1794 options are hard-coded in a client's configuration. However, most 1795 HTTP clients rely on the same resource identification mechanism and 1796 configuration techniques as general-purpose Web browsers. 1798 HTTP communication is initiated by a user agent for some purpose. 1799 The purpose is a combination of request semantics, which are defined 1800 in [Part2], and a target resource upon which to apply those 1801 semantics. A URI reference (Section 2.7) is typically used as an 1802 identifier for the "target resource", which a user agent would 1803 resolve to its absolute form in order to obtain the "target URI". 1804 The target URI excludes the reference's fragment component, if any, 1805 since fragment identifiers are reserved for client-side processing 1806 ([RFC3986], Section 3.5). 1808 5.2. Connecting Inbound 1810 Once the target URI is determined, a client needs to decide whether a 1811 network request is necessary to accomplish the desired semantics and, 1812 if so, where that request is to be directed. 1814 If the client has a cache [Part6] and the request can be satisfied by 1815 it, then the request is usually directed there first. 1817 If the request is not satisfied by a cache, then a typical client 1818 will check its configuration to determine whether a proxy is to be 1819 used to satisfy the request. Proxy configuration is implementation- 1820 dependent, but is often based on URI prefix matching, selective 1821 authority matching, or both, and the proxy itself is usually 1822 identified by an "http" or "https" URI. If a proxy is applicable, 1823 the client connects inbound by establishing (or reusing) a connection 1824 to that proxy. 1826 If no proxy is applicable, a typical client will invoke a handler 1827 routine, usually specific to the target URI's scheme, to connect 1828 directly to an authority for the target resource. How that is 1829 accomplished is dependent on the target URI scheme and defined by its 1830 associated specification, similar to how this specification defines 1831 origin server access for resolution of the "http" (Section 2.7.1) and 1832 "https" (Section 2.7.2) schemes. 1834 HTTP requirements regarding connection management are defined in 1835 Section 6. 1837 5.3. Request Target 1839 Once an inbound connection is obtained, the client sends an HTTP 1840 request message (Section 3) with a request-target derived from the 1841 target URI. There are four distinct formats for the request-target, 1842 depending on both the method being requested and whether the request 1843 is to a proxy. 1845 request-target = origin-form 1846 / absolute-form 1847 / authority-form 1848 / asterisk-form 1850 origin-form = absolute-path [ "?" query ] 1851 absolute-form = absolute-URI 1852 authority-form = authority 1853 asterisk-form = "*" 1855 origin-form 1857 The most common form of request-target is the origin-form. When 1858 making a request directly to an origin server, other than a CONNECT 1859 or server-wide OPTIONS request (as detailed below), a client MUST 1860 send only the absolute path and query components of the target URI as 1861 the request-target. If the target URI's path component is empty, 1862 then the client MUST send "/" as the path within the origin-form of 1863 request-target. A Host header field is also sent, as defined in 1864 Section 5.4, containing the target URI's authority component 1865 (excluding any userinfo). 1867 For example, a client wishing to retrieve a representation of the 1868 resource identified as 1870 http://www.example.org/where?q=now 1872 directly from the origin server would open (or reuse) a TCP 1873 connection to port 80 of the host "www.example.org" and send the 1874 lines: 1876 GET /where?q=now HTTP/1.1 1877 Host: www.example.org 1879 followed by the remainder of the request message. 1881 absolute-form 1883 When making a request to a proxy, other than a CONNECT or server-wide 1884 OPTIONS request (as detailed below), a client MUST send the target 1885 URI in absolute-form as the request-target. The proxy is requested 1886 to either service that request from a valid cache, if possible, or 1887 make the same request on the client's behalf to either the next 1888 inbound proxy server or directly to the origin server indicated by 1889 the request-target. Requirements on such "forwarding" of messages 1890 are defined in Section 5.7. 1892 An example absolute-form of request-line would be: 1894 GET http://www.example.org/pub/WWW/TheProject.html HTTP/1.1 1896 To allow for transition to the absolute-form for all requests in some 1897 future version of HTTP, HTTP/1.1 servers MUST accept the absolute- 1898 form in requests, even though HTTP/1.1 clients will only send them in 1899 requests to proxies. 1901 authority-form 1903 The authority-form of request-target is only used for CONNECT 1904 requests (Section 4.3.6 of [Part2]). When making a CONNECT request 1905 to establish a tunnel through one or more proxies, a client MUST send 1906 only the target URI's authority component (excluding any userinfo) as 1907 the request-target. For example, 1909 CONNECT www.example.com:80 HTTP/1.1 1911 asterisk-form 1913 The asterisk-form of request-target is only used for a server-wide 1914 OPTIONS request (Section 4.3.7 of [Part2]). When a client wishes to 1915 request OPTIONS for the server as a whole, as opposed to a specific 1916 named resource of that server, the client MUST send only "*" (%x2A) 1917 as the request-target. For example, 1919 OPTIONS * HTTP/1.1 1921 If a proxy receives an OPTIONS request with an absolute-form of 1922 request-target in which the URI has an empty path and no query 1923 component, then the last proxy on the request chain MUST send a 1924 request-target of "*" when it forwards the request to the indicated 1925 origin server. 1927 For example, the request 1929 OPTIONS http://www.example.org:8001 HTTP/1.1 1931 would be forwarded by the final proxy as 1933 OPTIONS * HTTP/1.1 1934 Host: www.example.org:8001 1936 after connecting to port 8001 of host "www.example.org". 1938 5.4. Host 1940 The "Host" header field in a request provides the host and port 1941 information from the target URI, enabling the origin server to 1942 distinguish among resources while servicing requests for multiple 1943 host names on a single IP address. Since the Host field-value is 1944 critical information for handling a request, it SHOULD be sent as the 1945 first header field following the request-line. 1947 Host = uri-host [ ":" port ] ; Section 2.7.1 1949 A client MUST send a Host header field in all HTTP/1.1 request 1950 messages. If the target URI includes an authority component, then 1951 the Host field-value MUST be identical to that authority component 1952 after excluding any userinfo (Section 2.7.1). If the authority 1953 component is missing or undefined for the target URI, then the Host 1954 header field MUST be sent with an empty field-value. 1956 For example, a GET request to the origin server for 1957 would begin with: 1959 GET /pub/WWW/ HTTP/1.1 1960 Host: www.example.org 1962 The Host header field MUST be sent in an HTTP/1.1 request even if the 1963 request-target is in the absolute-form, since this allows the Host 1964 information to be forwarded through ancient HTTP/1.0 proxies that 1965 might not have implemented Host. 1967 When a proxy receives a request with an absolute-form of request- 1968 target, the proxy MUST ignore the received Host header field (if any) 1969 and instead replace it with the host information of the request- 1970 target. If the proxy forwards the request, it MUST generate a new 1971 Host field-value based on the received request-target rather than 1972 forward the received Host field-value. 1974 Since the Host header field acts as an application-level routing 1975 mechanism, it is a frequent target for malware seeking to poison a 1976 shared cache or redirect a request to an unintended server. An 1977 interception proxy is particularly vulnerable if it relies on the 1978 Host field-value for redirecting requests to internal servers, or for 1979 use as a cache key in a shared cache, without first verifying that 1980 the intercepted connection is targeting a valid IP address for that 1981 host. 1983 A server MUST respond with a 400 (Bad Request) status code to any 1984 HTTP/1.1 request message that lacks a Host header field and to any 1985 request message that contains more than one Host header field or a 1986 Host header field with an invalid field-value. 1988 5.5. Effective Request URI 1990 A server that receives an HTTP request message MUST reconstruct the 1991 user agent's original target URI, based on the pieces of information 1992 learned from the request-target, Host header field, and connection 1993 context, in order to identify the intended target resource and 1994 properly service the request. The URI derived from this 1995 reconstruction process is referred to as the "effective request URI". 1997 For a user agent, the effective request URI is the target URI. 1999 If the request-target is in absolute-form, then the effective request 2000 URI is the same as the request-target. Otherwise, the effective 2001 request URI is constructed as follows. 2003 If the request is received over a TLS-secured TCP connection, then 2004 the effective request URI's scheme is "https"; otherwise, the scheme 2005 is "http". 2007 If the request-target is in authority-form, then the effective 2008 request URI's authority component is the same as the request-target. 2009 Otherwise, if a Host header field is supplied with a non-empty field- 2010 value, then the authority component is the same as the Host field- 2011 value. Otherwise, the authority component is the concatenation of 2012 the default host name configured for the server, a colon (":"), and 2013 the connection's incoming TCP port number in decimal form. 2015 If the request-target is in authority-form or asterisk-form, then the 2016 effective request URI's combined path and query component is empty. 2017 Otherwise, the combined path and query component is the same as the 2018 request-target. 2020 The components of the effective request URI, once determined as 2021 above, can be combined into absolute-URI form by concatenating the 2022 scheme, "://", authority, and combined path and query component. 2024 Example 1: the following message received over an insecure TCP 2025 connection 2027 GET /pub/WWW/TheProject.html HTTP/1.1 2028 Host: www.example.org:8080 2030 has an effective request URI of 2032 http://www.example.org:8080/pub/WWW/TheProject.html 2034 Example 2: the following message received over a TLS-secured TCP 2035 connection 2037 OPTIONS * HTTP/1.1 2038 Host: www.example.org 2040 has an effective request URI of 2042 https://www.example.org 2044 An origin server that does not allow resources to differ by requested 2045 host MAY ignore the Host field-value and instead replace it with a 2046 configured server name when constructing the effective request URI. 2048 Recipients of an HTTP/1.0 request that lacks a Host header field MAY 2049 attempt to use heuristics (e.g., examination of the URI path for 2050 something unique to a particular host) in order to guess the 2051 effective request URI's authority component. 2053 5.6. Associating a Response to a Request 2055 HTTP does not include a request identifier for associating a given 2056 request message with its corresponding one or more response messages. 2057 Hence, it relies on the order of response arrival to correspond 2058 exactly to the order in which requests are made on the same 2059 connection. More than one response message per request only occurs 2060 when one or more informational responses (1xx, see Section 6.2 of 2061 [Part2]) precede a final response to the same request. 2063 A client that has more than one outstanding request on a connection 2064 MUST maintain a list of outstanding requests in the order sent and 2065 MUST associate each received response message on that connection to 2066 the highest ordered request that has not yet received a final (non- 2067 1xx) response. 2069 5.7. Message Forwarding 2071 As described in Section 2.3, intermediaries can serve a variety of 2072 roles in the processing of HTTP requests and responses. Some 2073 intermediaries are used to improve performance or availability. 2074 Others are used for access control or to filter content. Since an 2075 HTTP stream has characteristics similar to a pipe-and-filter 2076 architecture, there are no inherent limits to the extent an 2077 intermediary can enhance (or interfere) with either direction of the 2078 stream. 2080 Intermediaries that forward a message MUST implement the Connection 2081 header field, as specified in Section 6.1, to exclude fields that are 2082 only intended for the incoming connection. 2084 In order to avoid request loops, a proxy that forwards requests to 2085 other proxies MUST be able to recognize and exclude all of its own 2086 server names, including any aliases, local variations, or literal IP 2087 addresses. 2089 5.7.1. Via 2091 The "Via" header field indicates the presence of intermediate 2092 protocols and recipients between the user agent and the server (on 2093 requests) or between the origin server and the client (on responses), 2094 similar to the "Received" header field in email (Section 3.6.7 of 2095 [RFC5322]). Via can be used for tracking message forwards, avoiding 2096 request loops, and identifying the protocol capabilities of senders 2097 along the request/response chain. 2099 Via = 1#( received-protocol RWS received-by [ RWS comment ] ) 2101 received-protocol = [ protocol-name "/" ] protocol-version 2102 ; see Section 6.7 2103 received-by = ( uri-host [ ":" port ] ) / pseudonym 2104 pseudonym = token 2106 Multiple Via field values represent each proxy or gateway that has 2107 forwarded the message. Each intermediary appends its own information 2108 about how the message was received, such that the end result is 2109 ordered according to the sequence of forwarding recipients. 2111 A proxy MUST send an appropriate Via header field, as described 2112 below, in each message that it forwards. An HTTP-to-HTTP gateway 2113 MUST send an appropriate Via header field in each inbound request 2114 message and MAY send a Via header field in forwarded response 2115 messages. 2117 For each intermediary, the received-protocol indicates the protocol 2118 and protocol version used by the upstream sender of the message. 2119 Hence, the Via field value records the advertised protocol 2120 capabilities of the request/response chain such that they remain 2121 visible to downstream recipients; this can be useful for determining 2122 what backwards-incompatible features might be safe to use in 2123 response, or within a later request, as described in Section 2.6. 2124 For brevity, the protocol-name is omitted when the received protocol 2125 is HTTP. 2127 The received-by field is normally the host and optional port number 2128 of a recipient server or client that subsequently forwarded the 2129 message. However, if the real host is considered to be sensitive 2130 information, it MAY be replaced by a pseudonym. If the port is not 2131 given, it MAY be assumed to be the default port of the received- 2132 protocol. 2134 Comments MAY be used in the Via header field to identify the software 2135 of each recipient, analogous to the User-Agent and Server header 2136 fields. However, all comments in the Via field are optional and MAY 2137 be removed by any recipient prior to forwarding the message. 2139 For example, a request message could be sent from an HTTP/1.0 user 2140 agent to an internal proxy code-named "fred", which uses HTTP/1.1 to 2141 forward the request to a public proxy at p.example.net, which 2142 completes the request by forwarding it to the origin server at 2143 www.example.com. The request received by www.example.com would then 2144 have the following Via header field: 2146 Via: 1.0 fred, 1.1 p.example.net 2148 A proxy or gateway used as a portal through a network firewall SHOULD 2149 NOT forward the names and ports of hosts within the firewall region 2150 unless it is explicitly enabled to do so. If not enabled, the 2151 received-by host of any host behind the firewall SHOULD be replaced 2152 by an appropriate pseudonym for that host. 2154 A proxy or gateway MAY combine an ordered subsequence of Via header 2155 field entries into a single such entry if the entries have identical 2156 received-protocol values. For example, 2158 Via: 1.0 ricky, 1.1 ethel, 1.1 fred, 1.0 lucy 2160 could be collapsed to 2162 Via: 1.0 ricky, 1.1 mertz, 1.0 lucy 2164 Senders SHOULD NOT combine multiple entries unless they are all under 2165 the same organizational control and the hosts have already been 2166 replaced by pseudonyms. Senders MUST NOT combine entries that have 2167 different received-protocol values. 2169 5.7.2. Transformations 2171 Some intermediaries include features for transforming messages and 2172 their payloads. A transforming proxy might, for example, convert 2173 between image formats in order to save cache space or to reduce the 2174 amount of traffic on a slow link. However, operational problems 2175 might occur when these transformations are applied to payloads 2176 intended for critical applications, such as medical imaging or 2177 scientific data analysis, particularly when integrity checks or 2178 digital signatures are used to ensure that the payload received is 2179 identical to the original. 2181 If a proxy receives a request-target with a host name that is not a 2182 fully qualified domain name, it MAY add its own domain to the host 2183 name it received when forwarding the request. A proxy MUST NOT 2184 change the host name if it is a fully qualified domain name. 2186 A proxy MUST NOT modify the "absolute-path" and "query" parts of the 2187 received request-target when forwarding it to the next inbound 2188 server, except as noted above to replace an empty path with "/" or 2189 "*". 2191 A proxy MUST NOT modify header fields that provide information about 2192 the end points of the communication chain, the resource state, or the 2193 selected representation. A proxy MAY change the message body through 2194 application or removal of a transfer coding (Section 4). 2196 A non-transforming proxy MUST NOT modify the message payload (Section 2197 3.3 of [Part2]). A transforming proxy MUST NOT modify the payload of 2198 a message that contains the no-transform cache-control directive. 2200 A transforming proxy MAY transform the payload of a message that does 2201 not contain the no-transform cache-control directive; if the payload 2202 is transformed, the transforming proxy MUST add a Warning header 2203 field with the warn-code of 214 ("Transformation Applied") if one 2204 does not already appear in the message (see Section 7.5 of [Part6]). 2205 If the payload of a 200 (OK) response is transformed, the 2206 transforming proxy can also inform downstream recipients that a 2207 transformation has been applied by changing the response status code 2208 to 203 (Non-Authoritative Information) (Section 6.3.4 of [Part2]). 2210 6. Connection Management 2212 HTTP messaging is independent of the underlying transport or session- 2213 layer connection protocol(s). HTTP only presumes a reliable 2214 transport with in-order delivery of requests and the corresponding 2215 in-order delivery of responses. The mapping of HTTP request and 2216 response structures onto the data units of an underlying transport 2217 protocol is outside the scope of this specification. 2219 As described in Section 5.2, the specific connection protocols to be 2220 used for an HTTP interaction are determined by client configuration 2221 and the target URI. For example, the "http" URI scheme 2222 (Section 2.7.1) indicates a default connection of TCP over IP, with a 2223 default TCP port of 80, but the client might be configured to use a 2224 proxy via some other connection, port, or protocol. 2226 HTTP implementations are expected to engage in connection management, 2227 which includes maintaining the state of current connections, 2228 establishing a new connection or reusing an existing connection, 2229 processing messages received on a connection, detecting connection 2230 failures, and closing each connection. Most clients maintain 2231 multiple connections in parallel, including more than one connection 2232 per server endpoint. Most servers are designed to maintain thousands 2233 of concurrent connections, while controlling request queues to enable 2234 fair use and detect denial of service attacks. 2236 6.1. Connection 2238 The "Connection" header field allows the sender to indicate desired 2239 control options for the current connection. In order to avoid 2240 confusing downstream recipients, a proxy or gateway MUST remove or 2241 replace any received connection options before forwarding the 2242 message. 2244 When a header field aside from Connection is used to supply control 2245 information for or about the current connection, the sender MUST list 2246 the corresponding field-name within the "Connection" header field. A 2247 proxy or gateway MUST parse a received Connection header field before 2248 a message is forwarded and, for each connection-option in this field, 2249 remove any header field(s) from the message with the same name as the 2250 connection-option, and then remove the Connection header field itself 2251 (or replace it with the intermediary's own connection options for the 2252 forwarded message). 2254 Hence, the Connection header field provides a declarative way of 2255 distinguishing header fields that are only intended for the immediate 2256 recipient ("hop-by-hop") from those fields that are intended for all 2257 recipients on the chain ("end-to-end"), enabling the message to be 2258 self-descriptive and allowing future connection-specific extensions 2259 to be deployed without fear that they will be blindly forwarded by 2260 older intermediaries. 2262 The Connection header field's value has the following grammar: 2264 Connection = 1#connection-option 2265 connection-option = token 2267 Connection options are case-insensitive. 2269 A sender MUST NOT send a connection option corresponding to a header 2270 field that is intended for all recipients of the payload. For 2271 example, Cache-Control is never appropriate as a connection option 2272 (Section 7.2 of [Part6]). 2274 The connection options do not have to correspond to a header field 2275 present in the message, since a connection-specific header field 2276 might not be needed if there are no parameters associated with that 2277 connection option. Recipients that trigger certain connection 2278 behavior based on the presence of connection options MUST do so based 2279 on the presence of the connection-option rather than only the 2280 presence of the optional header field. In other words, if the 2281 connection option is received as a header field but not indicated 2282 within the Connection field-value, then the recipient MUST ignore the 2283 connection-specific header field because it has likely been forwarded 2284 by an intermediary that is only partially conformant. 2286 When defining new connection options, specifications ought to 2287 carefully consider existing deployed header fields and ensure that 2288 the new connection option does not share the same name as an 2289 unrelated header field that might already be deployed. Defining a 2290 new connection option essentially reserves that potential field-name 2291 for carrying additional information related to the connection option, 2292 since it would be unwise for senders to use that field-name for 2293 anything else. 2295 The "close" connection option is defined for a sender to signal that 2296 this connection will be closed after completion of the response. For 2297 example, 2299 Connection: close 2301 in either the request or the response header fields indicates that 2302 the connection MUST be closed after the current request/response is 2303 complete (Section 6.6). 2305 A client that does not support persistent connections MUST send the 2306 "close" connection option in every request message. 2308 A server that does not support persistent connections MUST send the 2309 "close" connection option in every response message that does not 2310 have a 1xx (Informational) status code. 2312 6.2. Establishment 2314 It is beyond the scope of this specification to describe how 2315 connections are established via various transport or session-layer 2316 protocols. Each connection applies to only one transport link. 2318 6.3. Persistence 2320 HTTP/1.1 defaults to the use of "persistent connections", allowing 2321 multiple requests and responses to be carried over a single 2322 connection. The "close" connection-option is used to signal that a 2323 connection will not persist after the current request/response. HTTP 2324 implementations SHOULD support persistent connections. 2326 A recipient determines whether a connection is persistent or not 2327 based on the most recently received message's protocol version and 2328 Connection header field (if any): 2330 o If the close connection option is present, the connection will not 2331 persist after the current response; else, 2333 o If the received protocol is HTTP/1.1 (or later), the connection 2334 will persist after the current response; else, 2336 o If the received protocol is HTTP/1.0, the "keep-alive" connection 2337 option is present, the recipient is not a proxy, and the recipient 2338 wishes to honor the HTTP/1.0 "keep-alive" mechanism, the 2339 connection will persist after the current response; otherwise, 2341 o The connection will close after the current response. 2343 A server MAY assume that an HTTP/1.1 client intends to maintain a 2344 persistent connection until a close connection option is received in 2345 a request. 2347 A client MAY reuse a persistent connection until it sends or receives 2348 a close connection option or receives an HTTP/1.0 response without a 2349 "keep-alive" connection option. 2351 In order to remain persistent, all messages on a connection MUST have 2352 a self-defined message length (i.e., one not defined by closure of 2353 the connection), as described in Section 3.3. A server MUST read the 2354 entire request message body or close the connection after sending its 2355 response, since otherwise the remaining data on a persistent 2356 connection would be misinterpreted as the next request. Likewise, a 2357 client MUST read the entire response message body if it intends to 2358 reuse the same connection for a subsequent request. 2360 A proxy server MUST NOT maintain a persistent connection with an 2361 HTTP/1.0 client (see Section 19.7.1 of [RFC2068] for information and 2362 discussion of the problems with the Keep-Alive header field 2363 implemented by many HTTP/1.0 clients). 2365 Clients and servers SHOULD NOT assume that a persistent connection is 2366 maintained for HTTP versions less than 1.1 unless it is explicitly 2367 signaled. See Appendix A.1.2 for more information on backward 2368 compatibility with HTTP/1.0 clients. 2370 6.3.1. Retrying Requests 2372 Connections can be closed at any time, with or without intention. 2373 Implementations ought to anticipate the need to recover from 2374 asynchronous close events. 2376 When an inbound connection is closed prematurely, a client MAY open a 2377 new connection and automatically retransmit an aborted sequence of 2378 requests if all of those requests have idempotent methods (Section 2379 4.2.2 of [Part2]). A proxy MUST NOT automatically retry non- 2380 idempotent requests. 2382 A user agent MUST NOT automatically retry a request with a non- 2383 idempotent method unless it has some means to know that the request 2384 semantics are actually idempotent, regardless of the method, or some 2385 means to detect that the original request was never applied. For 2386 example, a user agent that knows (through design or configuration) 2387 that a POST request to a given resource is safe can repeat that 2388 request automatically. Likewise, a user agent designed specifically 2389 to operate on a version control repository might be able to recover 2390 from partial failure conditions by checking the target resource 2391 revision(s) after a failed connection, reverting or fixing any 2392 changes that were partially applied, and then automatically retrying 2393 the requests that failed. 2395 An automatic retry SHOULD NOT be repeated if it fails. 2397 6.3.2. Pipelining 2399 A client that supports persistent connections MAY "pipeline" its 2400 requests (i.e., send multiple requests without waiting for each 2401 response). A server MAY process a sequence of pipelined requests in 2402 parallel if they all have safe methods (Section 4.2.1 of [Part2]), 2403 but MUST send the corresponding responses in the same order that the 2404 requests were received. 2406 A client that pipelines requests MUST be prepared to retry those 2407 requests if the connection closes before it receives all of the 2408 corresponding responses. A client that assumes a persistent 2409 connection and pipelines immediately after connection establishment 2410 MUST NOT pipeline on a retry connection until it knows the connection 2411 is persistent. 2413 Idempotent methods (Section 4.2.2 of [Part2]) are significant to 2414 pipelining because they can be automatically retried after a 2415 connection failure. A user agent SHOULD NOT pipeline requests after 2416 a non-idempotent method until the final response status code for that 2417 method has been received, unless the user agent has a means to detect 2418 and recover from partial failure conditions involving the pipelined 2419 sequence. 2421 An intermediary that receives pipelined requests MAY pipeline those 2422 requests when forwarding them inbound, since it can rely on the 2423 outbound user agent(s) to determine what requests can be safely 2424 pipelined. If the inbound connection fails before receiving a 2425 response, the pipelining intermediary MAY attempt to retry a sequence 2426 of requests that have yet to receive a response if the requests all 2427 have idempotent methods; otherwise, the pipelining intermediary 2428 SHOULD forward any received responses and then close the 2429 corresponding outbound connection(s) so that the outbound user 2430 agent(s) can recover accordingly. 2432 6.4. Concurrency 2434 Clients SHOULD limit the number of simultaneous connections that they 2435 maintain to a given server. 2437 Previous revisions of HTTP gave a specific number of connections as a 2438 ceiling, but this was found to be impractical for many applications. 2439 As a result, this specification does not mandate a particular maximum 2440 number of connections, but instead encourages clients to be 2441 conservative when opening multiple connections. 2443 Multiple connections are typically used to avoid the "head-of-line 2444 blocking" problem, wherein a request that takes significant server- 2445 side processing and/or has a large payload blocks subsequent requests 2446 on the same connection. However, each connection consumes server 2447 resources. Furthermore, using multiple connections can cause 2448 undesirable side effects in congested networks. 2450 Note that servers might reject traffic that they deem abusive, 2451 including an excessive number of connections from a client. 2453 6.5. Failures and Time-outs 2455 Servers will usually have some time-out value beyond which they will 2456 no longer maintain an inactive connection. Proxy servers might make 2457 this a higher value since it is likely that the client will be making 2458 more connections through the same server. The use of persistent 2459 connections places no requirements on the length (or existence) of 2460 this time-out for either the client or the server. 2462 When a client or server wishes to time-out it SHOULD issue a graceful 2463 close on the transport connection. Clients and servers SHOULD both 2464 constantly watch for the other side of the transport close, and 2465 respond to it as appropriate. If a client or server does not detect 2466 the other side's close promptly it could cause unnecessary resource 2467 drain on the network. 2469 A client, server, or proxy MAY close the transport connection at any 2470 time. For example, a client might have started to send a new request 2471 at the same time that the server has decided to close the "idle" 2472 connection. From the server's point of view, the connection is being 2473 closed while it was idle, but from the client's point of view, a 2474 request is in progress. 2476 Servers SHOULD maintain persistent connections and allow the 2477 underlying transport's flow control mechanisms to resolve temporary 2478 overloads, rather than terminate connections with the expectation 2479 that clients will retry. The latter technique can exacerbate network 2480 congestion. 2482 A client sending a message body SHOULD monitor the network connection 2483 for an error response while it is transmitting the request. If the 2484 client sees an error response, it SHOULD immediately cease 2485 transmitting the body and close the connection. 2487 6.6. Tear-down 2489 The Connection header field (Section 6.1) provides a "close" 2490 connection option that a sender SHOULD send when it wishes to close 2491 the connection after the current request/response pair. 2493 A client that sends a close connection option MUST NOT send further 2494 requests on that connection (after the one containing close) and MUST 2495 close the connection after reading the final response message 2496 corresponding to this request. 2498 A server that receives a close connection option MUST initiate a 2499 close of the connection (see below) after it sends the final response 2500 to the request that contained close. The server SHOULD send a close 2501 connection option in its final response on that connection. The 2502 server MUST NOT process any further requests received on that 2503 connection. 2505 A server that sends a close connection option MUST initiate a close 2506 of the connection (see below) after it sends the response containing 2507 close. The server MUST NOT process any further requests received on 2508 that connection. 2510 A client that receives a close connection option MUST cease sending 2511 requests on that connection and close the connection after reading 2512 the response message containing the close; if additional pipelined 2513 requests had been sent on the connection, the client SHOULD NOT 2514 assume that they will be processed by the server. 2516 If a server performs an immediate close of a TCP connection, there is 2517 a significant risk that the client will not be able to read the last 2518 HTTP response. If the server receives additional data from the 2519 client on a fully-closed connection, such as another request that was 2520 sent by the client before receiving the server's response, the 2521 server's TCP stack will send a reset packet to the client; 2522 unfortunately, the reset packet might erase the client's 2523 unacknowledged input buffers before they can be read and interpreted 2524 by the client's HTTP parser. 2526 To avoid the TCP reset problem, servers typically close a connection 2527 in stages. First, the server performs a half-close by closing only 2528 the write side of the read/write connection. The server then 2529 continues to read from the connection until it receives a 2530 corresponding close by the client, or until the server is reasonably 2531 certain that its own TCP stack has received the client's 2532 acknowledgement of the packet(s) containing the server's last 2533 response. Finally, the server fully closes the connection. 2535 It is unknown whether the reset problem is exclusive to TCP or might 2536 also be found in other transport connection protocols. 2538 6.7. Upgrade 2540 The "Upgrade" header field is intended to provide a simple mechanism 2541 for transitioning from HTTP/1.1 to some other protocol on the same 2542 connection. A client MAY send a list of protocols in the Upgrade 2543 header field of a request to invite the server to switch to one or 2544 more of those protocols, in order of descending preference, before 2545 sending the final response. A server MAY ignore a received Upgrade 2546 header field if it wishes to continue using the current protocol on 2547 that connection. 2549 Upgrade = 1#protocol 2551 protocol = protocol-name ["/" protocol-version] 2552 protocol-name = token 2553 protocol-version = token 2555 A server that sends a 101 (Switching Protocols) response MUST send an 2556 Upgrade header field to indicate the new protocol(s) to which the 2557 connection is being switched; if multiple protocol layers are being 2558 switched, the new protocols MUST be listed in layer-ascending order. 2559 A server MUST NOT switch to a protocol that was not indicated by the 2560 client in the corresponding request's Upgrade header field. A server 2561 MAY choose to ignore the order of preference indicated by the client 2562 and select the new protocol(s) based on other factors, such as the 2563 nature of the request or the current load on the server. 2565 A server that sends a 426 (Upgrade Required) response MUST send an 2566 Upgrade header field to indicate the acceptable protocols, in order 2567 of descending preference. 2569 A server MAY send an Upgrade header field in any other response to 2570 advertise that it implements support for upgrading to the listed 2571 protocols, in order of descending preference, when appropriate for a 2572 future request. 2574 The following is a hypothetical example sent by a client: 2576 GET /hello.txt HTTP/1.1 2577 Host: www.example.com 2578 Connection: upgrade 2579 Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11 2581 Upgrade cannot be used to insist on a protocol change; its acceptance 2582 and use by the server is optional. The capabilities and nature of 2583 the application-level communication after the protocol change is 2584 entirely dependent upon the new protocol(s) chosen, although the 2585 first action after changing the protocol MUST be a response to the 2586 initial HTTP request that contained the Upgrade header field. 2588 For example, if the Upgrade header field is received in a GET request 2589 and the server decides to switch protocols, it first responds with a 2590 101 (Switching Protocols) message in HTTP/1.1 and then immediately 2591 follows that with the new protocol's equivalent of a response to a 2592 GET on the target resource. This allows a connection to be upgraded 2593 to protocols with the same semantics as HTTP without the latency cost 2594 of an additional round-trip. A server MUST NOT switch protocols 2595 unless the received message semantics can be honored by the new 2596 protocol; an OPTIONS request can be honored by any protocol. 2598 The following is an example response to the above hypothetical 2599 request: 2601 HTTP/1.1 101 Switching Protocols 2602 Connection: upgrade 2603 Upgrade: HTTP/2.0 2605 [... data stream switches to HTTP/2.0 with an appropriate response 2606 (as defined by new protocol) to the "GET /hello.txt" request ...] 2608 When Upgrade is sent, the sender MUST also send a Connection header 2609 field (Section 6.1) that contains an "upgrade" connection option, in 2610 order to prevent Upgrade from being accidentally forwarded by 2611 intermediaries that might not implement the listed protocols. A 2612 server MUST ignore an Upgrade header field that is received in an 2613 HTTP/1.0 request. 2615 The Upgrade header field only applies to switching protocols on top 2616 of the existing connection; it cannot be used to switch the 2617 underlying connection (transport) protocol, nor to switch the 2618 existing communication to a different connection. For those 2619 purposes, it is more appropriate to use a 3xx (Redirection) response 2620 (Section 6.4 of [Part2]). 2622 This specification only defines the protocol name "HTTP" for use by 2623 the family of Hypertext Transfer Protocols, as defined by the HTTP 2624 version rules of Section 2.6 and future updates to this 2625 specification. Additional tokens ought to be registered with IANA 2626 using the registration procedure defined in Section 7.5. 2628 7. IANA Considerations 2630 7.1. Header Field Registration 2632 HTTP header fields are registered within the Message Header Field 2633 Registry maintained at . 2636 This document defines the following HTTP header fields, so their 2637 associated registry entries shall be updated according to the 2638 permanent registrations below (see [BCP90]): 2640 +-------------------+----------+----------+---------------+ 2641 | Header Field Name | Protocol | Status | Reference | 2642 +-------------------+----------+----------+---------------+ 2643 | Connection | http | standard | Section 6.1 | 2644 | Content-Length | http | standard | Section 3.3.2 | 2645 | Host | http | standard | Section 5.4 | 2646 | TE | http | standard | Section 4.3 | 2647 | Trailer | http | standard | Section 4.1.1 | 2648 | Transfer-Encoding | http | standard | Section 3.3.1 | 2649 | Upgrade | http | standard | Section 6.7 | 2650 | Via | http | standard | Section 5.7.1 | 2651 +-------------------+----------+----------+---------------+ 2653 Furthermore, the header field-name "Close" shall be registered as 2654 "reserved", since using that name as an HTTP header field might 2655 conflict with the "close" connection option of the "Connection" 2656 header field (Section 6.1). 2658 +-------------------+----------+----------+-------------+ 2659 | Header Field Name | Protocol | Status | Reference | 2660 +-------------------+----------+----------+-------------+ 2661 | Close | http | reserved | Section 7.1 | 2662 +-------------------+----------+----------+-------------+ 2664 The change controller is: "IETF (iesg@ietf.org) - Internet 2665 Engineering Task Force". 2667 7.2. URI Scheme Registration 2669 IANA maintains the registry of URI Schemes [BCP115] at 2670 . 2672 This document defines the following URI schemes, so their associated 2673 registry entries shall be updated according to the permanent 2674 registrations below: 2676 +------------+------------------------------------+---------------+ 2677 | URI Scheme | Description | Reference | 2678 +------------+------------------------------------+---------------+ 2679 | http | Hypertext Transfer Protocol | Section 2.7.1 | 2680 | https | Hypertext Transfer Protocol Secure | Section 2.7.2 | 2681 +------------+------------------------------------+---------------+ 2683 7.3. Internet Media Type Registration 2685 This document serves as the specification for the Internet media 2686 types "message/http" and "application/http". The following is to be 2687 registered with IANA (see [BCP13]). 2689 7.3.1. Internet Media Type message/http 2691 The message/http type can be used to enclose a single HTTP request or 2692 response message, provided that it obeys the MIME restrictions for 2693 all "message" types regarding line length and encodings. 2695 Type name: message 2697 Subtype name: http 2699 Required parameters: none 2701 Optional parameters: version, msgtype 2702 version: The HTTP-version number of the enclosed message (e.g., 2703 "1.1"). If not present, the version can be determined from the 2704 first line of the body. 2706 msgtype: The message type -- "request" or "response". If not 2707 present, the type can be determined from the first line of the 2708 body. 2710 Encoding considerations: only "7bit", "8bit", or "binary" are 2711 permitted 2713 Security considerations: none 2715 Interoperability considerations: none 2717 Published specification: This specification (see Section 7.3.1). 2719 Applications that use this media type: 2721 Additional information: 2723 Magic number(s): none 2725 File extension(s): none 2727 Macintosh file type code(s): none 2729 Person and email address to contact for further information: See 2730 Authors Section. 2732 Intended usage: COMMON 2734 Restrictions on usage: none 2736 Author: See Authors Section. 2738 Change controller: IESG 2740 7.3.2. Internet Media Type application/http 2742 The application/http type can be used to enclose a pipeline of one or 2743 more HTTP request or response messages (not intermixed). 2745 Type name: application 2746 Subtype name: http 2748 Required parameters: none 2750 Optional parameters: version, msgtype 2752 version: The HTTP-version number of the enclosed messages (e.g., 2753 "1.1"). If not present, the version can be determined from the 2754 first line of the body. 2756 msgtype: The message type -- "request" or "response". If not 2757 present, the type can be determined from the first line of the 2758 body. 2760 Encoding considerations: HTTP messages enclosed by this type are in 2761 "binary" format; use of an appropriate Content-Transfer-Encoding 2762 is required when transmitted via E-mail. 2764 Security considerations: none 2766 Interoperability considerations: none 2768 Published specification: This specification (see Section 7.3.2). 2770 Applications that use this media type: 2772 Additional information: 2774 Magic number(s): none 2776 File extension(s): none 2778 Macintosh file type code(s): none 2780 Person and email address to contact for further information: See 2781 Authors Section. 2783 Intended usage: COMMON 2785 Restrictions on usage: none 2787 Author: See Authors Section. 2789 Change controller: IESG 2791 7.4. Transfer Coding Registry 2793 The HTTP Transfer Coding Registry defines the name space for transfer 2794 coding names. It is maintained at 2795 . 2797 7.4.1. Procedure 2799 Registrations MUST include the following fields: 2801 o Name 2803 o Description 2805 o Pointer to specification text 2807 Names of transfer codings MUST NOT overlap with names of content 2808 codings (Section 3.1.2.1 of [Part2]) unless the encoding 2809 transformation is identical, as is the case for the compression 2810 codings defined in Section 4.2. 2812 Values to be added to this name space require IETF Review (see 2813 Section 4.1 of [RFC5226]), and MUST conform to the purpose of 2814 transfer coding defined in this specification. 2816 Use of program names for the identification of encoding formats is 2817 not desirable and is discouraged for future encodings. 2819 7.4.2. Registration 2821 The HTTP Transfer Coding Registry shall be updated with the 2822 registrations below: 2824 +------------+--------------------------------------+---------------+ 2825 | Name | Description | Reference | 2826 +------------+--------------------------------------+---------------+ 2827 | chunked | Transfer in a series of chunks | Section 4.1 | 2828 | compress | UNIX "compress" data format [Welch] | Section 4.2.1 | 2829 | deflate | "deflate" compressed data | Section 4.2.2 | 2830 | | ([RFC1951]) inside the "zlib" data | | 2831 | | format ([RFC1950]) | | 2832 | gzip | GZIP file format [RFC1952] | Section 4.2.3 | 2833 | x-compress | Deprecated (alias for compress) | Section 4.2.1 | 2834 | x-gzip | Deprecated (alias for gzip) | Section 4.2.3 | 2835 +------------+--------------------------------------+---------------+ 2837 7.5. Upgrade Token Registry 2839 The HTTP Upgrade Token Registry defines the name space for protocol- 2840 name tokens used to identify protocols in the Upgrade header field. 2841 The registry is maintained at 2842 . 2844 7.5.1. Procedure 2846 Each registered protocol name is associated with contact information 2847 and an optional set of specifications that details how the connection 2848 will be processed after it has been upgraded. 2850 Registrations happen on a "First Come First Served" basis (see 2851 Section 4.1 of [RFC5226]) and are subject to the following rules: 2853 1. A protocol-name token, once registered, stays registered forever. 2855 2. The registration MUST name a responsible party for the 2856 registration. 2858 3. The registration MUST name a point of contact. 2860 4. The registration MAY name a set of specifications associated with 2861 that token. Such specifications need not be publicly available. 2863 5. The registration SHOULD name a set of expected "protocol-version" 2864 tokens associated with that token at the time of registration. 2866 6. The responsible party MAY change the registration at any time. 2867 The IANA will keep a record of all such changes, and make them 2868 available upon request. 2870 7. The IESG MAY reassign responsibility for a protocol token. This 2871 will normally only be used in the case when a responsible party 2872 cannot be contacted. 2874 This registration procedure for HTTP Upgrade Tokens replaces that 2875 previously defined in Section 7.2 of [RFC2817]. 2877 7.5.2. Upgrade Token Registration 2879 The HTTP Upgrade Token Registry shall be updated with the 2880 registration below: 2882 +-------+----------------------+----------------------+-------------+ 2883 | Value | Description | Expected Version | Reference | 2884 | | | Tokens | | 2885 +-------+----------------------+----------------------+-------------+ 2886 | HTTP | Hypertext Transfer | any DIGIT.DIGIT | Section 2.6 | 2887 | | Protocol | (e.g, "2.0") | | 2888 +-------+----------------------+----------------------+-------------+ 2890 The responsible party is: "IETF (iesg@ietf.org) - Internet 2891 Engineering Task Force". 2893 8. Security Considerations 2895 This section is meant to inform developers, information providers, 2896 and users of known security concerns relevant to HTTP/1.1 message 2897 syntax, parsing, and routing. 2899 8.1. DNS-related Attacks 2901 HTTP clients rely heavily on the Domain Name Service (DNS), and are 2902 thus generally prone to security attacks based on the deliberate 2903 misassociation of IP addresses and DNS names not protected by DNSSEC. 2904 Clients need to be cautious in assuming the validity of an IP number/ 2905 DNS name association unless the response is protected by DNSSEC 2906 ([RFC4033]). 2908 8.2. Intermediaries and Caching 2910 By their very nature, HTTP intermediaries are men-in-the-middle, and 2911 represent an opportunity for man-in-the-middle attacks. Compromise 2912 of the systems on which the intermediaries run can result in serious 2913 security and privacy problems. Intermediaries have access to 2914 security-related information, personal information about individual 2915 users and organizations, and proprietary information belonging to 2916 users and content providers. A compromised intermediary, or an 2917 intermediary implemented or configured without regard to security and 2918 privacy considerations, might be used in the commission of a wide 2919 range of potential attacks. 2921 Intermediaries that contain a shared cache are especially vulnerable 2922 to cache poisoning attacks. 2924 Implementers need to consider the privacy and security implications 2925 of their design and coding decisions, and of the configuration 2926 options they provide to operators (especially the default 2927 configuration). 2929 Users need to be aware that intermediaries are no more trustworthy 2930 than the people who run them; HTTP itself cannot solve this problem. 2932 8.3. Buffer Overflows 2934 Because HTTP uses mostly textual, character-delimited fields, 2935 attackers can overflow buffers in implementations, and/or perform a 2936 Denial of Service against implementations that accept fields with 2937 unlimited lengths. 2939 To promote interoperability, this specification makes specific 2940 recommendations for minimum size limits on request-line 2941 (Section 3.1.1) and blocks of header fields (Section 3.2). These are 2942 minimum recommendations, chosen to be supportable even by 2943 implementations with limited resources; it is expected that most 2944 implementations will choose substantially higher limits. 2946 This specification also provides a way for servers to reject messages 2947 that have request-targets that are too long (Section 6.5.12 of 2948 [Part2]) or request entities that are too large (Section 6.5 of 2949 [Part2]). Additional status codes related to capacity limits have 2950 been defined by extensions to HTTP [RFC6585]. 2952 Recipients SHOULD carefully limit the extent to which they read other 2953 fields, including (but not limited to) request methods, response 2954 status phrases, header field-names, and body chunks, so as to avoid 2955 denial of service attacks without impeding interoperability. 2957 8.4. Message Integrity 2959 HTTP does not define a specific mechanism for ensuring message 2960 integrity, instead relying on the error-detection ability of 2961 underlying transport protocols and the use of length or chunk- 2962 delimited framing to detect completeness. Additional integrity 2963 mechanisms, such as hash functions or digital signatures applied to 2964 the content, can be selectively added to messages via extensible 2965 metadata header fields. Historically, the lack of a single integrity 2966 mechanism has been justified by the informal nature of most HTTP 2967 communication. However, the prevalence of HTTP as an information 2968 access mechanism has resulted in its increasing use within 2969 environments where verification of message integrity is crucial. 2971 User agents are encouraged to implement configurable means for 2972 detecting and reporting failures of message integrity such that those 2973 means can be enabled within environments for which integrity is 2974 necessary. For example, a browser being used to view medical history 2975 or drug interaction information needs to indicate to the user when 2976 such information is detected by the protocol to be incomplete, 2977 expired, or corrupted during transfer. Such mechanisms might be 2978 selectively enabled via user agent extensions or the presence of 2979 message integrity metadata in a response. At a minimum, user agents 2980 ought to provide some indication that allows a user to distinguish 2981 between a complete and incomplete response message (Section 3.4) when 2982 such verification is desired. 2984 8.5. Server Log Information 2986 A server is in the position to save personal data about a user's 2987 requests over time, which might identify their reading patterns or 2988 subjects of interest. In particular, log information gathered at an 2989 intermediary often contains a history of user agent interaction, 2990 across a multitude of sites, that can be traced to individual users. 2992 HTTP log information is confidential in nature; its handling is often 2993 constrained by laws and regulations. Log information needs to be 2994 securely stored and appropriate guidelines followed for its analysis. 2995 Anonymization of personal information within individual entries 2996 helps, but is generally not sufficient to prevent real log traces 2997 from being re-identified based on correlation with other access 2998 characteristics. As such, access traces that are keyed to a specific 2999 client should not be published even if the key is pseudonymous. 3001 To minimize the risk of theft or accidental publication, log 3002 information should be purged of personally identifiable information, 3003 including user identifiers, IP addresses, and user-provided query 3004 parameters, as soon as that information is no longer necessary to 3005 support operational needs for security, auditing, or fraud control. 3007 9. Acknowledgments 3009 This edition of HTTP/1.1 builds on the many contributions that went 3010 into RFC 1945, RFC 2068, RFC 2145, and RFC 2616, including 3011 substantial contributions made by the previous authors, editors, and 3012 working group chairs: Tim Berners-Lee, Ari Luotonen, Roy T. Fielding, 3013 Henrik Frystyk Nielsen, Jim Gettys, Jeffrey C. Mogul, Larry Masinter, 3014 and Paul J. Leach. Mark Nottingham oversaw this effort as working 3015 group chair. 3017 Since 1999, the following contributors have helped improve the HTTP 3018 specification by reporting bugs, asking smart questions, drafting or 3019 reviewing text, and evaluating open issues: 3021 Adam Barth, Adam Roach, Addison Phillips, Adrian Chadd, Adrien W. de 3022 Croy, Alan Ford, Alan Ruttenberg, Albert Lunde, Alek Storm, Alex 3023 Rousskov, Alexandre Morgaut, Alexey Melnikov, Alisha Smith, Amichai 3024 Rothman, Amit Klein, Amos Jeffries, Andreas Maier, Andreas Petersson, 3025 Anil Sharma, Anne van Kesteren, Anthony Bryan, Asbjorn Ulsberg, Ashok 3026 Kumar, Balachander Krishnamurthy, Barry Leiba, Ben Laurie, Benjamin 3027 Carlyle, Benjamin Niven-Jenkins, Bil Corry, Bill Burke, Bjoern 3028 Hoehrmann, Bob Scheifler, Boris Zbarsky, Brett Slatkin, Brian Kell, 3029 Brian McBarron, Brian Pane, Brian Raymor, Brian Smith, Bryce Nesbitt, 3030 Cameron Heavon-Jones, Carl Kugler, Carsten Bormann, Charles Fry, 3031 Chris Newman, Cyrus Daboo, Dale Robert Anderson, Dan Wing, Dan 3032 Winship, Daniel Stenberg, Darrel Miller, Dave Cridland, Dave Crocker, 3033 Dave Kristol, Dave Thaler, David Booth, David Singer, David W. 3034 Morris, Diwakar Shetty, Dmitry Kurochkin, Drummond Reed, Duane 3035 Wessels, Edward Lee, Eitan Adler, Eliot Lear, Eran Hammer-Lahav, Eric 3036 D. Williams, Eric J. Bowman, Eric Lawrence, Eric Rescorla, Erik 3037 Aronesty, Evan Prodromou, Felix Geisendoerfer, Florian Weimer, Frank 3038 Ellermann, Fred Akalin, Fred Bohle, Frederic Kayser, Gabor Molnar, 3039 Gabriel Montenegro, Geoffrey Sneddon, Gervase Markham, Gili Tzabari, 3040 Grahame Grieve, Greg Wilkins, Grzegorz Calkowski, Harald Tveit 3041 Alvestrand, Harry Halpin, Helge Hess, Henrik Nordstrom, Henry S. 3042 Thompson, Henry Story, Herbert van de Sompel, Herve Ruellan, Howard 3043 Melman, Hugo Haas, Ian Fette, Ian Hickson, Ido Safruti, Ilari 3044 Liusvaara, Ilya Grigorik, Ingo Struck, J. Ross Nicoll, James Cloos, 3045 James H. Manger, James Lacey, James M. Snell, Jamie Lokier, Jan 3046 Algermissen, Jeff Hodges (who came up with the term 'effective 3047 Request-URI'), Jeff Pinner, Jeff Walden, Jim Luther, Jitu Padhye, Joe 3048 D. Williams, Joe Gregorio, Joe Orton, John C. Klensin, John C. 3049 Mallery, John Cowan, John Kemp, John Panzer, John Schneider, John 3050 Stracke, John Sullivan, Jonas Sicking, Jonathan A. Rees, Jonathan 3051 Billington, Jonathan Moore, Jonathan Silvera, Jordi Ros, Joris 3052 Dobbelsteen, Josh Cohen, Julien Pierre, Jungshik Shin, Justin 3053 Chapweske, Justin Erenkrantz, Justin James, Kalvinder Singh, Karl 3054 Dubost, Keith Hoffman, Keith Moore, Ken Murchison, Koen Holtman, 3055 Konstantin Voronkov, Kris Zyp, Lisa Dusseault, Maciej Stachowiak, 3056 Manu Sporny, Marc Schneider, Marc Slemko, Mark Baker, Mark Pauley, 3057 Mark Watson, Markus Isomaki, Markus Lanthaler, Martin J. Duerst, 3058 Martin Musatov, Martin Nilsson, Martin Thomson, Matt Lynch, Matthew 3059 Cox, Max Clark, Michael Burrows, Michael Hausenblas, Michael Sweet, 3060 Mike Amundsen, Mike Belshe, Mike Bishop, Mike Kelly, Mike Schinkel, 3061 Miles Sabin, Murray S. Kucherawy, Mykyta Yevstifeyev, Nathan Rixham, 3062 Nicholas Shanks, Nico Williams, Nicolas Alvarez, Nicolas Mailhot, 3063 Noah Slater, Osama Mazahir, Pablo Castro, Pat Hayes, Patrick R. 3064 McManus, Paul E. Jones, Paul Hoffman, Paul Marquess, Peter Lepeska, 3065 Peter Occil, Peter Saint-Andre, Peter Watkins, Phil Archer, Philippe 3066 Mougin, Phillip Hallam-Baker, Piotr Dobrogost, Poul-Henning Kamp, 3067 Preethi Natarajan, Rajeev Bector, Ray Polk, Reto Bachmann-Gmuer, 3068 Richard Cyganiak, Robby Simpson, Robert Brewer, Robert Collins, 3069 Robert Mattson, Robert O'Callahan, Robert Olofsson, Robert Sayre, 3070 Robert Siemer, Robert de Wilde, Roberto Javier Godoy, Roberto Peon, 3071 Roland Zink, Ronny Widjaja, S. Mike Dierken, Salvatore Loreto, Sam 3072 Johnston, Sam Pullara, Sam Ruby, Scott Lawrence (who maintained the 3073 original issues list), Sean B. Palmer, Shane McCarron, Shigeki Ohtsu, 3074 Stefan Eissing, Stefan Tilkov, Stefanos Harhalakis, Stephane 3075 Bortzmeyer, Stephen Farrell, Stephen Ludin, Stuart Williams, Subbu 3076 Allamaraju, Sylvain Hellegouarch, Tapan Divekar, Tatsuya Hayashi, Ted 3077 Hardie, Thomas Broyer, Thomas Fossati, Thomas Maslen, Thomas Nordin, 3078 Thomas Roessler, Tim Bray, Tim Morgan, Tim Olsen, Tom Zhou, Travis 3079 Snoozy, Tyler Close, Vincent Murphy, Wenbo Zhu, Werner Baumann, 3080 Wilbur Streett, Wilfredo Sanchez Vega, William A. Rowe Jr., William 3081 Chan, Willy Tarreau, Xiaoshu Wang, Yaron Goland, Yngve Nysaeter 3082 Pettersen, Yoav Nir, Yogesh Bang, Yutaka Oiwa, Yves Lafon (long-time 3083 member of the editor team), Zed A. Shaw, and Zhong Yu. 3085 See Section 16 of [RFC2616] for additional acknowledgements from 3086 prior revisions. 3088 10. References 3090 10.1. Normative References 3092 [Part2] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext 3093 Transfer Protocol (HTTP/1.1): Semantics and Content", 3094 draft-ietf-httpbis-p2-semantics-23 (work in progress), 3095 July 2013. 3097 [Part4] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext 3098 Transfer Protocol (HTTP/1.1): Conditional Requests", 3099 draft-ietf-httpbis-p4-conditional-23 (work in 3100 progress), July 2013. 3102 [Part5] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., 3103 "Hypertext Transfer Protocol (HTTP/1.1): Range 3104 Requests", draft-ietf-httpbis-p5-range-23 (work in 3105 progress), July 2013. 3107 [Part6] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, 3108 Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", 3109 draft-ietf-httpbis-p6-cache-23 (work in progress), 3110 July 2013. 3112 [Part7] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext 3113 Transfer Protocol (HTTP/1.1): Authentication", 3114 draft-ietf-httpbis-p7-auth-23 (work in progress), 3115 July 2013. 3117 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 3118 RFC 793, September 1981. 3120 [RFC1950] Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data 3121 Format Specification version 3.3", RFC 1950, May 1996. 3123 [RFC1951] Deutsch, P., "DEFLATE Compressed Data Format 3124 Specification version 1.3", RFC 1951, May 1996. 3126 [RFC1952] Deutsch, P., Gailly, J-L., Adler, M., Deutsch, L., and 3127 G. Randers-Pehrson, "GZIP file format specification 3128 version 4.3", RFC 1952, May 1996. 3130 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3131 Requirement Levels", BCP 14, RFC 2119, March 1997. 3133 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, 3134 "Uniform Resource Identifier (URI): Generic Syntax", 3135 STD 66, RFC 3986, January 2005. 3137 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for 3138 Syntax Specifications: ABNF", STD 68, RFC 5234, 3139 January 2008. 3141 [USASCII] American National Standards Institute, "Coded Character 3142 Set -- 7-bit American Standard Code for Information 3143 Interchange", ANSI X3.4, 1986. 3145 [Welch] Welch, T., "A Technique for High Performance Data 3146 Compression", IEEE Computer 17(6), June 1984. 3148 10.2. Informative References 3150 [BCP115] Hansen, T., Hardie, T., and L. Masinter, "Guidelines 3151 and Registration Procedures for New URI Schemes", 3152 BCP 115, RFC 4395, February 2006. 3154 [BCP13] Freed, N., Klensin, J., and T. Hansen, "Media Type 3155 Specifications and Registration Procedures", BCP 13, 3156 RFC 6838, January 2013. 3158 [BCP90] Klyne, G., Nottingham, M., and J. Mogul, "Registration 3159 Procedures for Message Header Fields", BCP 90, 3160 RFC 3864, September 2004. 3162 [ISO-8859-1] International Organization for Standardization, 3163 "Information technology -- 8-bit single-byte coded 3164 graphic character sets -- Part 1: Latin alphabet No. 3165 1", ISO/IEC 8859-1:1998, 1998. 3167 [Kri2001] Kristol, D., "HTTP Cookies: Standards, Privacy, and 3168 Politics", ACM Transactions on Internet 3169 Technology 1(2), November 2001, 3170 . 3172 [RFC1919] Chatel, M., "Classical versus Transparent IP Proxies", 3173 RFC 1919, March 1996. 3175 [RFC1945] Berners-Lee, T., Fielding, R., and H. Nielsen, 3176 "Hypertext Transfer Protocol -- HTTP/1.0", RFC 1945, 3177 May 1996. 3179 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet 3180 Mail Extensions (MIME) Part One: Format of Internet 3181 Message Bodies", RFC 2045, November 1996. 3183 [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail 3184 Extensions) Part Three: Message Header Extensions for 3185 Non-ASCII Text", RFC 2047, November 1996. 3187 [RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and 3188 T. Berners-Lee, "Hypertext Transfer Protocol -- 3189 HTTP/1.1", RFC 2068, January 1997. 3191 [RFC2145] Mogul, J., Fielding, R., Gettys, J., and H. Nielsen, 3192 "Use and Interpretation of HTTP Version Numbers", 3193 RFC 2145, May 1997. 3195 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 3196 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 3197 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 3199 [RFC2817] Khare, R. and S. Lawrence, "Upgrading to TLS Within 3200 HTTP/1.1", RFC 2817, May 2000. 3202 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 3204 [RFC3040] Cooper, I., Melve, I., and G. Tomlinson, "Internet Web 3205 Replication and Caching Taxonomy", RFC 3040, 3206 January 2001. 3208 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 3209 Rose, "DNS Security Introduction and Requirements", 3210 RFC 4033, March 2005. 3212 [RFC4559] Jaganathan, K., Zhu, L., and J. Brezak, "SPNEGO-based 3213 Kerberos and NTLM HTTP Authentication in Microsoft 3214 Windows", RFC 4559, June 2006. 3216 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing 3217 an IANA Considerations Section in RFCs", BCP 26, 3218 RFC 5226, May 2008. 3220 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer 3221 Security (TLS) Protocol Version 1.2", RFC 5246, 3222 August 2008. 3224 [RFC5322] Resnick, P., "Internet Message Format", RFC 5322, 3225 October 2008. 3227 [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, 3228 April 2011. 3230 [RFC6585] Nottingham, M. and R. Fielding, "Additional HTTP Status 3231 Codes", RFC 6585, April 2012. 3233 Appendix A. HTTP Version History 3235 HTTP has been in use by the World-Wide Web global information 3236 initiative since 1990. The first version of HTTP, later referred to 3237 as HTTP/0.9, was a simple protocol for hypertext data transfer across 3238 the Internet with only a single request method (GET) and no metadata. 3239 HTTP/1.0, as defined by [RFC1945], added a range of request methods 3240 and MIME-like messaging that could include metadata about the data 3241 transferred and modifiers on the request/response semantics. 3242 However, HTTP/1.0 did not sufficiently take into consideration the 3243 effects of hierarchical proxies, caching, the need for persistent 3244 connections, or name-based virtual hosts. The proliferation of 3245 incompletely-implemented applications calling themselves "HTTP/1.0" 3246 further necessitated a protocol version change in order for two 3247 communicating applications to determine each other's true 3248 capabilities. 3250 HTTP/1.1 remains compatible with HTTP/1.0 by including more stringent 3251 requirements that enable reliable implementations, adding only those 3252 new features that will either be safely ignored by an HTTP/1.0 3253 recipient or only sent when communicating with a party advertising 3254 conformance with HTTP/1.1. 3256 It is beyond the scope of a protocol specification to mandate 3257 conformance with previous versions. HTTP/1.1 was deliberately 3258 designed, however, to make supporting previous versions easy. We 3259 would expect a general-purpose HTTP/1.1 server to understand any 3260 valid request in the format of HTTP/1.0 and respond appropriately 3261 with an HTTP/1.1 message that only uses features understood (or 3262 safely ignored) by HTTP/1.0 clients. Likewise, we would expect an 3263 HTTP/1.1 client to understand any valid HTTP/1.0 response. 3265 Since HTTP/0.9 did not support header fields in a request, there is 3266 no mechanism for it to support name-based virtual hosts (selection of 3267 resource by inspection of the Host header field). Any server that 3268 implements name-based virtual hosts ought to disable support for 3269 HTTP/0.9. Most requests that appear to be HTTP/0.9 are, in fact, 3270 badly constructed HTTP/1.x requests wherein a buggy client failed to 3271 properly encode linear whitespace found in a URI reference and placed 3272 in the request-target. 3274 A.1. Changes from HTTP/1.0 3276 This section summarizes major differences between versions HTTP/1.0 3277 and HTTP/1.1. 3279 A.1.1. Multi-homed Web Servers 3281 The requirements that clients and servers support the Host header 3282 field (Section 5.4), report an error if it is missing from an 3283 HTTP/1.1 request, and accept absolute URIs (Section 5.3) are among 3284 the most important changes defined by HTTP/1.1. 3286 Older HTTP/1.0 clients assumed a one-to-one relationship of IP 3287 addresses and servers; there was no other established mechanism for 3288 distinguishing the intended server of a request than the IP address 3289 to which that request was directed. The Host header field was 3290 introduced during the development of HTTP/1.1 and, though it was 3291 quickly implemented by most HTTP/1.0 browsers, additional 3292 requirements were placed on all HTTP/1.1 requests in order to ensure 3293 complete adoption. At the time of this writing, most HTTP-based 3294 services are dependent upon the Host header field for targeting 3295 requests. 3297 A.1.2. Keep-Alive Connections 3299 In HTTP/1.0, each connection is established by the client prior to 3300 the request and closed by the server after sending the response. 3301 However, some implementations implement the explicitly negotiated 3302 ("Keep-Alive") version of persistent connections described in Section 3303 19.7.1 of [RFC2068]. 3305 Some clients and servers might wish to be compatible with these 3306 previous approaches to persistent connections, by explicitly 3307 negotiating for them with a "Connection: keep-alive" request header 3308 field. However, some experimental implementations of HTTP/1.0 3309 persistent connections are faulty; for example, if an HTTP/1.0 proxy 3310 server doesn't understand Connection, it will erroneously forward 3311 that header field to the next inbound server, which would result in a 3312 hung connection. 3314 One attempted solution was the introduction of a Proxy-Connection 3315 header field, targeted specifically at proxies. In practice, this 3316 was also unworkable, because proxies are often deployed in multiple 3317 layers, bringing about the same problem discussed above. 3319 As a result, clients are encouraged not to send the Proxy-Connection 3320 header field in any requests. 3322 Clients are also encouraged to consider the use of Connection: keep- 3323 alive in requests carefully; while they can enable persistent 3324 connections with HTTP/1.0 servers, clients using them will need to 3325 monitor the connection for "hung" requests (which indicate that the 3326 client ought stop sending the header field), and this mechanism ought 3327 not be used by clients at all when a proxy is being used. 3329 A.1.3. Introduction of Transfer-Encoding 3331 HTTP/1.1 introduces the Transfer-Encoding header field 3332 (Section 3.3.1). Transfer codings need to be decoded prior to 3333 forwarding an HTTP message over a MIME-compliant protocol. 3335 A.2. Changes from RFC 2616 3337 HTTP's approach to error handling has been explained. (Section 2.5) 3339 The expectation to support HTTP/0.9 requests has been removed. 3341 The term "Effective Request URI" has been introduced. (Section 5.5) 3343 HTTP messages can be (and often are) buffered by implementations; 3344 despite it sometimes being available as a stream, HTTP is 3345 fundamentally a message-oriented protocol. (Section 3) 3347 Minimum supported sizes for various protocol elements have been 3348 suggested, to improve interoperability. 3350 Header fields that span multiple lines ("line folding") are 3351 deprecated. (Section 3.2.4) 3353 The HTTP-version ABNF production has been clarified to be case- 3354 sensitive. Additionally, version numbers has been restricted to 3355 single digits, due to the fact that implementations are known to 3356 handle multi-digit version numbers incorrectly. (Section 2.6) 3358 The HTTPS URI scheme is now defined by this specification; 3359 previously, it was done in Section 2.4 of [RFC2818]. (Section 2.7.2) 3361 The HTTPS URI scheme implies end-to-end security. (Section 2.7.2) 3363 Userinfo (i.e., username and password) are now disallowed in HTTP and 3364 HTTPS URIs, because of security issues related to their transmission 3365 on the wire. (Section 2.7.1) 3367 Invalid whitespace around field-names is now required to be rejected, 3368 because accepting it represents a security vulnerability. 3369 (Section 3.2) 3371 The ABNF productions defining header fields now only list the field 3372 value. (Section 3.2) 3374 Rules about implicit linear whitespace between certain grammar 3375 productions have been removed; now whitespace is only allowed where 3376 specifically defined in the ABNF. (Section 3.2.3) 3378 The NUL octet is no longer allowed in comment and quoted-string text, 3379 and handling of backslash-escaping in them has been clarified. 3380 (Section 3.2.6) 3382 The quoted-pair rule no longer allows escaping control characters 3383 other than HTAB. (Section 3.2.6) 3385 Non-ASCII content in header fields and the reason phrase has been 3386 obsoleted and made opaque (the TEXT rule was removed). 3387 (Section 3.2.6) 3389 Bogus "Content-Length" header fields are now required to be handled 3390 as errors by recipients. (Section 3.3.2) 3392 The "identity" transfer coding token has been removed. (Sections 3.3 3393 and 4) 3395 The algorithm for determining the message body length has been 3396 clarified to indicate all of the special cases (e.g., driven by 3397 methods or status codes) that affect it, and that new protocol 3398 elements cannot define such special cases. (Section 3.3.3) 3400 "multipart/byteranges" is no longer a way of determining message body 3401 length detection. (Section 3.3.3) 3403 CONNECT is a new, special case in determining message body length. 3404 (Section 3.3.3) 3406 Chunk length does not include the count of the octets in the chunk 3407 header and trailer. (Section 4.1) 3409 Use of chunk extensions is deprecated, and line folding in them is 3410 disallowed. (Section 4.1) 3411 The segment + query components of RFC3986 have been used to define 3412 the request-target, instead of abs_path from RFC 1808. (Section 5.3) 3414 The asterisk form of the request-target is only allowed in the 3415 OPTIONS method. (Section 5.3) 3417 Exactly when "close" connection options have to be sent has been 3418 clarified. (Section 6.1) 3420 "hop-by-hop" header fields are required to appear in the Connection 3421 header field; just because they're defined as hop-by-hop in this 3422 specification doesn't exempt them. (Section 6.1) 3424 The limit of two connections per server has been removed. 3425 (Section 6.3) 3427 An idempotent sequence of requests is no longer required to be 3428 retried. (Section 6.3) 3430 The requirement to retry requests under certain circumstances when 3431 the server prematurely closes the connection has been removed. 3432 (Section 6.3) 3434 Some extraneous requirements about when servers are allowed to close 3435 connections prematurely have been removed. (Section 6.3) 3437 The semantics of the Upgrade header field is now defined in responses 3438 other than 101 (this was incorporated from [RFC2817]). (Section 6.7) 3440 Registration of Transfer Codings now requires IETF Review 3441 (Section 7.4) 3443 The meaning of the "deflate" content coding has been clarified. 3444 (Section 4.2.2) 3446 This specification now defines the Upgrade Token Registry, previously 3447 defined in Section 7.2 of [RFC2817]. (Section 7.5) 3449 Issues with the Keep-Alive and Proxy-Connection header fields in 3450 requests are pointed out, with use of the latter being discouraged 3451 altogether. (Appendix A.1.2) 3453 Empty list elements in list productions (e.g., a list header field 3454 containing ", ,") have been deprecated. (Appendix B) 3456 Appendix B. ABNF list extension: #rule 3458 A #rule extension to the ABNF rules of [RFC5234] is used to improve 3459 readability in the definitions of some header field values. 3461 A construct "#" is defined, similar to "*", for defining comma- 3462 delimited lists of elements. The full form is "#element" 3463 indicating at least and at most elements, each separated by a 3464 single comma (",") and optional whitespace (OWS). 3466 Thus, 3468 1#element => element *( OWS "," OWS element ) 3470 and: 3472 #element => [ 1#element ] 3474 and for n >= 1 and m > 1: 3476 #element => element *( OWS "," OWS element ) 3478 For compatibility with legacy list rules, recipients SHOULD accept 3479 empty list elements. In other words, consumers would follow the list 3480 productions: 3482 #element => [ ( "," / element ) *( OWS "," [ OWS element ] ) ] 3484 1#element => *( "," OWS ) element *( OWS "," [ OWS element ] ) 3486 Note that empty elements do not contribute to the count of elements 3487 present, though. 3489 For example, given these ABNF productions: 3491 example-list = 1#example-list-elmt 3492 example-list-elmt = token ; see Section 3.2.6 3494 Then these are valid values for example-list (not including the 3495 double quotes, which are present for delimitation only): 3497 "foo,bar" 3498 "foo ,bar," 3499 "foo , ,bar,charlie " 3501 But these values would be invalid, as at least one non-empty element 3502 is required: 3504 "" 3505 "," 3506 ", ," 3508 Appendix C shows the collected ABNF, with the list rules expanded as 3509 explained above. 3511 Appendix C. Collected ABNF 3513 BWS = OWS 3515 Connection = *( "," OWS ) connection-option *( OWS "," [ OWS 3516 connection-option ] ) 3517 Content-Length = 1*DIGIT 3519 HTTP-message = start-line *( header-field CRLF ) CRLF [ message-body 3520 ] 3521 HTTP-name = %x48.54.54.50 ; HTTP 3522 HTTP-version = HTTP-name "/" DIGIT "." DIGIT 3523 Host = uri-host [ ":" port ] 3525 OWS = *( SP / HTAB ) 3527 RWS = 1*( SP / HTAB ) 3529 TE = [ ( "," / t-codings ) *( OWS "," [ OWS t-codings ] ) ] 3530 Trailer = *( "," OWS ) field-name *( OWS "," [ OWS field-name ] ) 3531 Transfer-Encoding = *( "," OWS ) transfer-coding *( OWS "," [ OWS 3532 transfer-coding ] ) 3534 URI-reference = 3535 Upgrade = *( "," OWS ) protocol *( OWS "," [ OWS protocol ] ) 3537 Via = *( "," OWS ) ( received-protocol RWS received-by [ RWS comment 3538 ] ) *( OWS "," [ OWS ( received-protocol RWS received-by [ RWS 3539 comment ] ) ] ) 3541 absolute-URI = 3542 absolute-form = absolute-URI 3543 absolute-path = 1*( "/" segment ) 3544 asterisk-form = "*" 3545 attribute = token 3546 authority = 3547 authority-form = authority 3549 chunk = chunk-size [ chunk-ext ] CRLF chunk-data CRLF 3550 chunk-data = 1*OCTET 3551 chunk-ext = *( ";" chunk-ext-name [ "=" chunk-ext-val ] ) 3552 chunk-ext-name = token 3553 chunk-ext-val = token / quoted-str-nf 3554 chunk-size = 1*HEXDIG 3555 chunked-body = *chunk last-chunk trailer-part CRLF 3556 comment = "(" *( ctext / quoted-cpair / comment ) ")" 3557 connection-option = token 3558 ctext = HTAB / SP / %x21-27 ; '!'-''' 3559 / %x2A-5B ; '*'-'[' 3560 / %x5D-7E ; ']'-'~' 3561 / obs-text 3563 field-content = *( HTAB / SP / VCHAR / obs-text ) 3564 field-name = token 3565 field-value = *( field-content / obs-fold ) 3566 fragment = 3568 header-field = field-name ":" OWS field-value OWS 3569 http-URI = "http://" authority path-abempty [ "?" query ] [ "#" 3570 fragment ] 3571 https-URI = "https://" authority path-abempty [ "?" query ] [ "#" 3572 fragment ] 3574 last-chunk = 1*"0" [ chunk-ext ] CRLF 3576 message-body = *OCTET 3577 method = token 3579 obs-fold = CRLF ( SP / HTAB ) 3580 obs-text = %x80-FF 3581 origin-form = absolute-path [ "?" query ] 3583 partial-URI = relative-part [ "?" query ] 3584 path-abempty = 3585 port = 3586 protocol = protocol-name [ "/" protocol-version ] 3587 protocol-name = token 3588 protocol-version = token 3589 pseudonym = token 3591 qdtext = HTAB / SP / "!" / %x23-5B ; '#'-'[' 3592 / %x5D-7E ; ']'-'~' 3593 / obs-text 3594 qdtext-nf = HTAB / SP / "!" / %x23-5B ; '#'-'[' 3595 / %x5D-7E ; ']'-'~' 3596 / obs-text 3597 query = 3598 quoted-cpair = "\" ( HTAB / SP / VCHAR / obs-text ) 3599 quoted-pair = "\" ( HTAB / SP / VCHAR / obs-text ) 3600 quoted-str-nf = DQUOTE *( qdtext-nf / quoted-pair ) DQUOTE 3601 quoted-string = DQUOTE *( qdtext / quoted-pair ) DQUOTE 3603 rank = ( "0" [ "." *3DIGIT ] ) / ( "1" [ "." *3"0" ] ) 3604 reason-phrase = *( HTAB / SP / VCHAR / obs-text ) 3605 received-by = ( uri-host [ ":" port ] ) / pseudonym 3606 received-protocol = [ protocol-name "/" ] protocol-version 3607 relative-part = 3608 request-line = method SP request-target SP HTTP-version CRLF 3609 request-target = origin-form / absolute-form / authority-form / 3610 asterisk-form 3612 segment = 3613 special = "(" / ")" / "<" / ">" / "@" / "," / ";" / ":" / "\" / 3614 DQUOTE / "/" / "[" / "]" / "?" / "=" / "{" / "}" 3615 start-line = request-line / status-line 3616 status-code = 3DIGIT 3617 status-line = HTTP-version SP status-code SP reason-phrase CRLF 3619 t-codings = "trailers" / ( transfer-coding [ t-ranking ] ) 3620 t-ranking = OWS ";" OWS "q=" rank 3621 tchar = "!" / "#" / "$" / "%" / "&" / "'" / "*" / "+" / "-" / "." / 3622 "^" / "_" / "`" / "|" / "~" / DIGIT / ALPHA 3623 token = 1*tchar 3624 trailer-part = *( header-field CRLF ) 3625 transfer-coding = "chunked" / "compress" / "deflate" / "gzip" / 3626 transfer-extension 3627 transfer-extension = token *( OWS ";" OWS transfer-parameter ) 3628 transfer-parameter = attribute BWS "=" BWS value 3630 uri-host = 3632 value = word 3634 word = token / quoted-string 3636 Appendix D. Change Log (to be removed by RFC Editor before publication) 3638 D.1. Since RFC 2616 3640 Changes up to the first Working Group Last Call draft are summarized 3641 in . 3644 D.2. Since draft-ietf-httpbis-p1-messaging-21 3646 Closed issues: 3648 o : "Cite HTTPS 3649 URI scheme definition" (the spec now includes the HTTPs scheme 3650 definition and thus updates RFC 2818) 3652 o : "mention of 3653 'proxies' in section about caches" 3655 o : "use of ABNF 3656 terms from RFC 3986" 3658 o : "transferring 3659 URIs with userinfo in payload" 3661 o : "editorial 3662 improvements to message length definition" 3664 o : "Connection 3665 header field MUST vs SHOULD" 3667 o : "editorial 3668 improvements to persistent connections section" 3670 o : "URI 3671 normalization vs empty path" 3673 o : "p1 feedback" 3675 o : "is parsing 3676 OBS-FOLD mandatory?" 3678 o : "HTTPS and 3679 Shared Caching" 3681 o : "Requirements 3682 for recipients of ws between start-line and first header field" 3684 o : "SP and HT 3685 when being tolerant" 3687 o : "Message 3688 Parsing Strictness" 3690 o : "'Render'" 3692 o : "No-Transform" 3694 o : "p2 editorial 3695 feedback" 3697 o : "Content- 3698 Length SHOULD be sent" 3700 o : "origin-form 3701 does not allow path starting with "//"" 3703 o : "ambiguity in 3704 part 1 example" 3706 D.3. Since draft-ietf-httpbis-p1-messaging-22 3708 Closed issues: 3710 o : "Part1 should 3711 have a reference to TCP (RFC 793)" 3713 o : "media type 3714 registration template issues" 3716 o : "BWS" (vs 3717 conformance) 3719 o : "obs-fold 3720 language" 3722 o : "Ordering in 3723 Upgrade" 3725 o : "p1 editorial 3726 feedback" 3728 o : "HTTP and TCP 3729 name delegation" 3731 o : "Receiving a 3732 higher minor HTTP version number" 3734 o : "HTTP(S) URIs 3735 and fragids" 3737 o : "Registering 3738 x-gzip and x-deflate" 3740 o : "Via and 3741 gateways" 3743 o : "Mention 203 3744 Non-Authoritative Information in p1" 3746 o : "SHOULD and 3747 conformance" 3749 o : "Pipelining 3750 language" 3752 o : "proxy 3753 handling of a really bad Content-Length" 3755 Index 3757 A 3758 absolute-form (of request-target) 40 3759 accelerator 10 3760 application/http Media Type 58 3761 asterisk-form (of request-target) 41 3762 authority-form (of request-target) 41 3764 B 3765 browser 7 3767 C 3768 cache 11 3769 cacheable 12 3770 captive portal 11 3771 chunked (Coding Format) 27, 30, 34 3772 client 7 3773 close 48, 53 3774 compress (Coding Format) 37 3775 connection 7 3776 Connection header field 48, 53 3777 Content-Length header field 29 3779 D 3780 deflate (Coding Format) 37 3781 downstream 9 3783 E 3784 effective request URI 43 3786 G 3787 gateway 10 3788 Grammar 3789 absolute-form 40 3790 absolute-path 16 3791 absolute-URI 16 3792 ALPHA 6 3793 asterisk-form 40 3794 attribute 34 3795 authority 16 3796 authority-form 40 3797 BWS 24 3798 chunk 35 3799 chunk-data 35 3800 chunk-ext 35 3801 chunk-ext-name 35 3802 chunk-ext-val 35 3803 chunk-size 35 3804 chunked-body 35 3805 comment 26 3806 Connection 48 3807 connection-option 48 3808 Content-Length 29 3809 CR 6 3810 CRLF 6 3811 ctext 26 3812 CTL 6 3813 date2 34 3814 date3 34 3815 DIGIT 6 3816 DQUOTE 6 3817 field-content 22 3818 field-name 22 3819 field-value 22 3820 fragment 16 3821 header-field 22 3822 HEXDIG 6 3823 Host 42 3824 HTAB 6 3825 HTTP-message 19 3826 HTTP-name 13 3827 http-URI 16 3828 HTTP-version 13 3829 https-URI 18 3830 last-chunk 35 3831 LF 6 3832 message-body 27 3833 method 20 3834 obs-fold 22 3835 obs-text 26 3836 OCTET 6 3837 origin-form 40 3838 OWS 24 3839 partial-URI 16 3840 port 16 3841 protocol-name 45 3842 protocol-version 45 3843 pseudonym 45 3844 qdtext 26 3845 qdtext-nf 35 3846 query 16 3847 quoted-cpair 26 3848 quoted-pair 26 3849 quoted-str-nf 35 3850 quoted-string 26 3851 rank 37 3852 reason-phrase 21 3853 received-by 45 3854 received-protocol 45 3855 request-line 20 3856 request-target 40 3857 RWS 24 3858 segment 16 3859 SP 6 3860 special 26 3861 start-line 20 3862 status-code 21 3863 status-line 21 3864 t-codings 37 3865 t-ranking 37 3866 tchar 26 3867 TE 37 3868 token 26 3869 Trailer 35 3870 trailer-part 35 3871 transfer-coding 34 3872 Transfer-Encoding 27 3873 transfer-extension 34 3874 transfer-parameter 34 3875 Upgrade 54 3876 uri-host 16 3877 URI-reference 16 3878 value 34 3879 VCHAR 6 3880 Via 45 3881 word 26 3882 gzip (Coding Format) 37 3884 H 3885 header field 19 3886 header section 19 3887 headers 19 3888 Host header field 41 3889 http URI scheme 16 3890 https URI scheme 17 3892 I 3893 inbound 9 3894 interception proxy 11 3895 intermediary 9 3897 M 3898 Media Type 3899 application/http 58 3900 message/http 57 3901 message 7 3902 message/http Media Type 57 3903 method 20 3905 N 3906 non-transforming proxy 10 3908 O 3909 origin server 7 3910 origin-form (of request-target) 40 3911 outbound 9 3913 P 3914 proxy 10 3916 R 3917 recipient 7 3918 request 7 3919 request-target 20 3920 resource 15 3921 response 7 3922 reverse proxy 10 3924 S 3925 sender 7 3926 server 7 3927 spider 7 3929 T 3930 target resource 38 3931 target URI 38 3932 TE header field 37 3933 Trailer header field 35 3934 Transfer-Encoding header field 27 3935 transforming proxy 10 3936 transparent proxy 11 3937 tunnel 11 3939 U 3940 Upgrade header field 54 3941 upstream 9 3942 URI scheme 3943 http 16 3944 https 17 3945 user agent 7 3947 V 3948 Via header field 45 3950 Authors' Addresses 3952 Roy T. Fielding (editor) 3953 Adobe Systems Incorporated 3954 345 Park Ave 3955 San Jose, CA 95110 3956 USA 3958 EMail: fielding@gbiv.com 3959 URI: http://roy.gbiv.com/ 3961 Julian F. Reschke (editor) 3962 greenbytes GmbH 3963 Hafenweg 16 3964 Muenster, NW 48155 3965 Germany 3967 EMail: julian.reschke@greenbytes.de 3968 URI: http://greenbytes.de/tech/webdav/