idnits 2.17.1 draft-ietf-httpbis-p1-messaging-26.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 (February 6, 2014) is 3704 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 3419, but no explicit reference was found in the text == Unused Reference: 'RFC2145' is defined on line 3525, but no explicit reference was found in the text ** 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 (~~), 3 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 February 6, 2014 7 Expires: August 10, 2014 9 Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing 10 draft-ietf-httpbis-p1-messaging-26 12 Abstract 14 The Hypertext Transfer Protocol (HTTP) is a stateless application- 15 level protocol for distributed, collaborative, hypertext information 16 systems. This document provides an overview of HTTP architecture and 17 its associated terminology, defines the "http" and "https" Uniform 18 Resource Identifier (URI) schemes, defines the HTTP/1.1 message 19 syntax and parsing requirements, and describes related security 20 concerns for implementations. 22 Editorial Note (To be removed by RFC Editor) 24 Discussion of this draft takes place on the HTTPBIS working group 25 mailing list (ietf-http-wg@w3.org), which is archived at 26 . 28 The current issues list is at 29 and related 30 documents (including fancy diffs) can be found at 31 . 33 The changes in this draft are summarized in Appendix C.3. 35 Status of This Memo 37 This Internet-Draft is submitted in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF). Note that other groups may also distribute 42 working documents as Internet-Drafts. The list of current Internet- 43 Drafts is at http://datatracker.ietf.org/drafts/current/. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 This Internet-Draft will expire on August 10, 2014. 51 Copyright Notice 53 Copyright (c) 2014 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (http://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with respect 61 to this document. Code Components extracted from this document must 62 include Simplified BSD License text as described in Section 4.e of 63 the Trust Legal Provisions and are provided without warranty as 64 described in the Simplified BSD License. 66 This document may contain material from IETF Documents or IETF 67 Contributions published or made publicly available before November 68 10, 2008. The person(s) controlling the copyright in some of this 69 material may not have granted the IETF Trust the right to allow 70 modifications of such material outside the IETF Standards Process. 71 Without obtaining an adequate license from the person(s) controlling 72 the copyright in such materials, this document may not be modified 73 outside the IETF Standards Process, and derivative works of it may 74 not be created outside the IETF Standards Process, except to format 75 it for publication as an RFC or to translate it into languages other 76 than English. 78 Table of Contents 80 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 81 1.1. Requirement Notation . . . . . . . . . . . . . . . . . . . 6 82 1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 6 83 2. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 6 84 2.1. Client/Server Messaging . . . . . . . . . . . . . . . . . 7 85 2.2. Implementation Diversity . . . . . . . . . . . . . . . . . 8 86 2.3. Intermediaries . . . . . . . . . . . . . . . . . . . . . . 9 87 2.4. Caches . . . . . . . . . . . . . . . . . . . . . . . . . . 11 88 2.5. Conformance and Error Handling . . . . . . . . . . . . . . 12 89 2.6. Protocol Versioning . . . . . . . . . . . . . . . . . . . 13 90 2.7. Uniform Resource Identifiers . . . . . . . . . . . . . . . 16 91 2.7.1. http URI scheme . . . . . . . . . . . . . . . . . . . 16 92 2.7.2. https URI scheme . . . . . . . . . . . . . . . . . . . 18 93 2.7.3. http and https URI Normalization and Comparison . . . 19 94 3. Message Format . . . . . . . . . . . . . . . . . . . . . . . . 19 95 3.1. Start Line . . . . . . . . . . . . . . . . . . . . . . . . 20 96 3.1.1. Request Line . . . . . . . . . . . . . . . . . . . . . 21 97 3.1.2. Status Line . . . . . . . . . . . . . . . . . . . . . 22 98 3.2. Header Fields . . . . . . . . . . . . . . . . . . . . . . 22 99 3.2.1. Field Extensibility . . . . . . . . . . . . . . . . . 23 100 3.2.2. Field Order . . . . . . . . . . . . . . . . . . . . . 23 101 3.2.3. Whitespace . . . . . . . . . . . . . . . . . . . . . . 24 102 3.2.4. Field Parsing . . . . . . . . . . . . . . . . . . . . 25 103 3.2.5. Field Limits . . . . . . . . . . . . . . . . . . . . . 26 104 3.2.6. Field value components . . . . . . . . . . . . . . . . 26 105 3.3. Message Body . . . . . . . . . . . . . . . . . . . . . . . 27 106 3.3.1. Transfer-Encoding . . . . . . . . . . . . . . . . . . 28 107 3.3.2. Content-Length . . . . . . . . . . . . . . . . . . . . 30 108 3.3.3. Message Body Length . . . . . . . . . . . . . . . . . 31 109 3.4. Handling Incomplete Messages . . . . . . . . . . . . . . . 33 110 3.5. Message Parsing Robustness . . . . . . . . . . . . . . . . 34 111 4. Transfer Codings . . . . . . . . . . . . . . . . . . . . . . . 35 112 4.1. Chunked Transfer Coding . . . . . . . . . . . . . . . . . 35 113 4.1.1. Chunk Extensions . . . . . . . . . . . . . . . . . . . 36 114 4.1.2. Chunked Trailer Part . . . . . . . . . . . . . . . . . 36 115 4.1.3. Decoding Chunked . . . . . . . . . . . . . . . . . . . 37 116 4.2. Compression Codings . . . . . . . . . . . . . . . . . . . 38 117 4.2.1. Compress Coding . . . . . . . . . . . . . . . . . . . 38 118 4.2.2. Deflate Coding . . . . . . . . . . . . . . . . . . . . 38 119 4.2.3. Gzip Coding . . . . . . . . . . . . . . . . . . . . . 38 120 4.3. TE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 121 4.4. Trailer . . . . . . . . . . . . . . . . . . . . . . . . . 39 122 5. Message Routing . . . . . . . . . . . . . . . . . . . . . . . 40 123 5.1. Identifying a Target Resource . . . . . . . . . . . . . . 40 124 5.2. Connecting Inbound . . . . . . . . . . . . . . . . . . . . 40 125 5.3. Request Target . . . . . . . . . . . . . . . . . . . . . . 41 126 5.3.1. origin-form . . . . . . . . . . . . . . . . . . . . . 41 127 5.3.2. absolute-form . . . . . . . . . . . . . . . . . . . . 42 128 5.3.3. authority-form . . . . . . . . . . . . . . . . . . . . 42 129 5.3.4. asterisk-form . . . . . . . . . . . . . . . . . . . . 42 130 5.4. Host . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 131 5.5. Effective Request URI . . . . . . . . . . . . . . . . . . 44 132 5.6. Associating a Response to a Request . . . . . . . . . . . 46 133 5.7. Message Forwarding . . . . . . . . . . . . . . . . . . . . 46 134 5.7.1. Via . . . . . . . . . . . . . . . . . . . . . . . . . 47 135 5.7.2. Transformations . . . . . . . . . . . . . . . . . . . 48 136 6. Connection Management . . . . . . . . . . . . . . . . . . . . 49 137 6.1. Connection . . . . . . . . . . . . . . . . . . . . . . . . 50 138 6.2. Establishment . . . . . . . . . . . . . . . . . . . . . . 51 139 6.3. Persistence . . . . . . . . . . . . . . . . . . . . . . . 52 140 6.3.1. Retrying Requests . . . . . . . . . . . . . . . . . . 53 141 6.3.2. Pipelining . . . . . . . . . . . . . . . . . . . . . . 53 142 6.4. Concurrency . . . . . . . . . . . . . . . . . . . . . . . 54 143 6.5. Failures and Time-outs . . . . . . . . . . . . . . . . . . 54 144 6.6. Tear-down . . . . . . . . . . . . . . . . . . . . . . . . 55 145 6.7. Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . 56 146 7. ABNF list extension: #rule . . . . . . . . . . . . . . . . . . 58 147 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 60 148 8.1. Header Field Registration . . . . . . . . . . . . . . . . 60 149 8.2. URI Scheme Registration . . . . . . . . . . . . . . . . . 60 150 8.3. Internet Media Type Registration . . . . . . . . . . . . . 61 151 8.3.1. Internet Media Type message/http . . . . . . . . . . . 61 152 8.3.2. Internet Media Type application/http . . . . . . . . . 62 153 8.4. Transfer Coding Registry . . . . . . . . . . . . . . . . . 63 154 8.4.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 63 155 8.4.2. Registration . . . . . . . . . . . . . . . . . . . . . 64 156 8.5. Content Coding Registration . . . . . . . . . . . . . . . 64 157 8.6. Upgrade Token Registry . . . . . . . . . . . . . . . . . . 65 158 8.6.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 65 159 8.6.2. Upgrade Token Registration . . . . . . . . . . . . . . 66 160 9. Security Considerations . . . . . . . . . . . . . . . . . . . 66 161 9.1. Establishing Authority . . . . . . . . . . . . . . . . . . 66 162 9.2. Risks of Intermediaries . . . . . . . . . . . . . . . . . 67 163 9.3. Attacks via Protocol Element Length . . . . . . . . . . . 68 164 9.4. Response Splitting . . . . . . . . . . . . . . . . . . . . 68 165 9.5. Request Smuggling . . . . . . . . . . . . . . . . . . . . 69 166 9.6. Message Integrity . . . . . . . . . . . . . . . . . . . . 69 167 9.7. Message Confidentiality . . . . . . . . . . . . . . . . . 70 168 9.8. Privacy of Server Log Information . . . . . . . . . . . . 70 169 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 71 170 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 72 171 11.1. Normative References . . . . . . . . . . . . . . . . . . . 72 172 11.2. Informative References . . . . . . . . . . . . . . . . . . 74 173 Appendix A. HTTP Version History . . . . . . . . . . . . . . . . 76 174 A.1. Changes from HTTP/1.0 . . . . . . . . . . . . . . . . . . 77 175 A.1.1. Multi-homed Web Servers . . . . . . . . . . . . . . . 77 176 A.1.2. Keep-Alive Connections . . . . . . . . . . . . . . . . 77 177 A.1.3. Introduction of Transfer-Encoding . . . . . . . . . . 78 178 A.2. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 78 179 Appendix B. Collected ABNF . . . . . . . . . . . . . . . . . . . 80 180 Appendix C. Change Log (to be removed by RFC Editor before 181 publication) . . . . . . . . . . . . . . . . . . . . 82 182 C.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 82 183 C.2. Since draft-ietf-httpbis-p1-messaging-24 . . . . . . . . . 83 184 C.3. Since draft-ietf-httpbis-p1-messaging-25 . . . . . . . . . 83 185 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 187 1. Introduction 189 The Hypertext Transfer Protocol (HTTP) is a stateless application- 190 level request/response protocol that uses extensible semantics and 191 self-descriptive message payloads for flexible interaction with 192 network-based hypertext information systems. This document is the 193 first in a series of documents that collectively form the HTTP/1.1 194 specification: 196 RFC xxx1: Message Syntax and Routing 198 RFC xxx2: Semantics and Content 200 RFC xxx3: Conditional Requests 202 RFC xxx4: Range Requests 204 RFC xxx5: Caching 206 RFC xxx6: Authentication 208 This HTTP/1.1 specification obsoletes RFC 2616 and RFC 2145 (on HTTP 209 versioning). This specification also updates the use of CONNECT to 210 establish a tunnel, previously defined in RFC 2817, and defines the 211 "https" URI scheme that was described informally in RFC 2818. 213 HTTP is a generic interface protocol for information systems. It is 214 designed to hide the details of how a service is implemented by 215 presenting a uniform interface to clients that is independent of the 216 types of resources provided. Likewise, servers do not need to be 217 aware of each client's purpose: an HTTP request can be considered in 218 isolation rather than being associated with a specific type of client 219 or a predetermined sequence of application steps. The result is a 220 protocol that can be used effectively in many different contexts and 221 for which implementations can evolve independently over time. 223 HTTP is also designed for use as an intermediation protocol for 224 translating communication to and from non-HTTP information systems. 225 HTTP proxies and gateways can provide access to alternative 226 information services by translating their diverse protocols into a 227 hypertext format that can be viewed and manipulated by clients in the 228 same way as HTTP services. 230 One consequence of this flexibility is that the protocol cannot be 231 defined in terms of what occurs behind the interface. Instead, we 232 are limited to defining the syntax of communication, the intent of 233 received communication, and the expected behavior of recipients. If 234 the communication is considered in isolation, then successful actions 235 ought to be reflected in corresponding changes to the observable 236 interface provided by servers. However, since multiple clients might 237 act in parallel and perhaps at cross-purposes, we cannot require that 238 such changes be observable beyond the scope of a single response. 240 This document describes the architectural elements that are used or 241 referred to in HTTP, defines the "http" and "https" URI schemes, 242 describes overall network operation and connection management, and 243 defines HTTP message framing and forwarding requirements. Our goal 244 is to define all of the mechanisms necessary for HTTP message 245 handling that are independent of message semantics, thereby defining 246 the complete set of requirements for message parsers and message- 247 forwarding intermediaries. 249 1.1. Requirement Notation 251 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 252 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 253 document are to be interpreted as described in [RFC2119]. 255 Conformance criteria and considerations regarding error handling are 256 defined in Section 2.5. 258 1.2. Syntax Notation 260 This specification uses the Augmented Backus-Naur Form (ABNF) 261 notation of [RFC5234] with a list extension, defined in Section 7, 262 that allows for compact definition of comma-separated lists using a 263 '#' operator (similar to how the '*' operator indicates repetition). 264 Appendix B shows the collected grammar with all list operators 265 expanded to standard ABNF notation. 267 The following core rules are included by reference, as defined in 268 [RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF 269 (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote), 270 HEXDIG (hexadecimal 0-9/A-F/a-f), HTAB (horizontal tab), LF (line 271 feed), OCTET (any 8-bit sequence of data), SP (space), and VCHAR (any 272 visible [USASCII] character). 274 As a convention, ABNF rule names prefixed with "obs-" denote 275 "obsolete" grammar rules that appear for historical reasons. 277 2. Architecture 279 HTTP was created for the World Wide Web (WWW) architecture and has 280 evolved over time to support the scalability needs of a worldwide 281 hypertext system. Much of that architecture is reflected in the 282 terminology and syntax productions used to define HTTP. 284 2.1. Client/Server Messaging 286 HTTP is a stateless request/response protocol that operates by 287 exchanging messages (Section 3) across a reliable transport or 288 session-layer "connection" (Section 6). An HTTP "client" is a 289 program that establishes a connection to a server for the purpose of 290 sending one or more HTTP requests. An HTTP "server" is a program 291 that accepts connections in order to service HTTP requests by sending 292 HTTP responses. 294 The terms client and server refer only to the roles that these 295 programs perform for a particular connection. The same program might 296 act as a client on some connections and a server on others. The term 297 "user agent" refers to any of the various client programs that 298 initiate a request, including (but not limited to) browsers, spiders 299 (web-based robots), command-line tools, custom applications, and 300 mobile apps. The term "origin server" refers to the program that can 301 originate authoritative responses for a given target resource. The 302 terms "sender" and "recipient" refer to any implementation that sends 303 or receives a given message, respectively. 305 HTTP relies upon the Uniform Resource Identifier (URI) standard 306 [RFC3986] to indicate the target resource (Section 5.1) and 307 relationships between resources. Messages are passed in a format 308 similar to that used by Internet mail [RFC5322] and the Multipurpose 309 Internet Mail Extensions (MIME) [RFC2045] (see Appendix A of [Part2] 310 for the differences between HTTP and MIME messages). 312 Most HTTP communication consists of a retrieval request (GET) for a 313 representation of some resource identified by a URI. In the simplest 314 case, this might be accomplished via a single bidirectional 315 connection (===) between the user agent (UA) and the origin server 316 (O). 318 request > 319 UA ======================================= O 320 < response 322 A client sends an HTTP request to a server in the form of a request 323 message, beginning with a request-line that includes a method, URI, 324 and protocol version (Section 3.1.1), followed by header fields 325 containing request modifiers, client information, and representation 326 metadata (Section 3.2), an empty line to indicate the end of the 327 header section, and finally a message body containing the payload 328 body (if any, Section 3.3). 330 A server responds to a client's request by sending one or more HTTP 331 response messages, each beginning with a status line that includes 332 the protocol version, a success or error code, and textual reason 333 phrase (Section 3.1.2), possibly followed by header fields containing 334 server information, resource metadata, and representation metadata 335 (Section 3.2), an empty line to indicate the end of the header 336 section, and finally a message body containing the payload body (if 337 any, Section 3.3). 339 A connection might be used for multiple request/response exchanges, 340 as defined in Section 6.3. 342 The following example illustrates a typical message exchange for a 343 GET request (Section 4.3.1 of [Part2]) on the URI 344 "http://www.example.com/hello.txt": 346 Client request: 348 GET /hello.txt HTTP/1.1 349 User-Agent: curl/7.16.3 libcurl/7.16.3 OpenSSL/0.9.7l zlib/1.2.3 350 Host: www.example.com 351 Accept-Language: en, mi 353 Server response: 355 HTTP/1.1 200 OK 356 Date: Mon, 27 Jul 2009 12:28:53 GMT 357 Server: Apache 358 Last-Modified: Wed, 22 Jul 2009 19:15:56 GMT 359 ETag: "34aa387-d-1568eb00" 360 Accept-Ranges: bytes 361 Content-Length: 51 362 Vary: Accept-Encoding 363 Content-Type: text/plain 365 Hello World! My payload includes a trailing CRLF. 367 2.2. Implementation Diversity 369 When considering the design of HTTP, it is easy to fall into a trap 370 of thinking that all user agents are general-purpose browsers and all 371 origin servers are large public websites. That is not the case in 372 practice. Common HTTP user agents include household appliances, 373 stereos, scales, firmware update scripts, command-line programs, 374 mobile apps, and communication devices in a multitude of shapes and 375 sizes. Likewise, common HTTP origin servers include home automation 376 units, configurable networking components, office machines, 377 autonomous robots, news feeds, traffic cameras, ad selectors, and 378 video delivery platforms. 380 The term "user agent" does not imply that there is a human user 381 directly interacting with the software agent at the time of a 382 request. In many cases, a user agent is installed or configured to 383 run in the background and save its results for later inspection (or 384 save only a subset of those results that might be interesting or 385 erroneous). Spiders, for example, are typically given a start URI 386 and configured to follow certain behavior while crawling the Web as a 387 hypertext graph. 389 The implementation diversity of HTTP means that not all user agents 390 can make interactive suggestions to their user or provide adequate 391 warning for security or privacy concerns. In the few cases where 392 this specification requires reporting of errors to the user, it is 393 acceptable for such reporting to only be observable in an error 394 console or log file. Likewise, requirements that an automated action 395 be confirmed by the user before proceeding might be met via advance 396 configuration choices, run-time options, or simple avoidance of the 397 unsafe action; confirmation does not imply any specific user 398 interface or interruption of normal processing if the user has 399 already made that choice. 401 2.3. Intermediaries 403 HTTP enables the use of intermediaries to satisfy requests through a 404 chain of connections. There are three common forms of HTTP 405 intermediary: proxy, gateway, and tunnel. In some cases, a single 406 intermediary might act as an origin server, proxy, gateway, or 407 tunnel, switching behavior based on the nature of each request. 409 > > > > 410 UA =========== A =========== B =========== C =========== O 411 < < < < 413 The figure above shows three intermediaries (A, B, and C) between the 414 user agent and origin server. A request or response message that 415 travels the whole chain will pass through four separate connections. 416 Some HTTP communication options might apply only to the connection 417 with the nearest, non-tunnel neighbor, only to the end-points of the 418 chain, or to all connections along the chain. Although the diagram 419 is linear, each participant might be engaged in multiple, 420 simultaneous communications. For example, B might be receiving 421 requests from many clients other than A, and/or forwarding requests 422 to servers other than C, at the same time that it is handling A's 423 request. Likewise, later requests might be sent through a different 424 path of connections, often based on dynamic configuration for load 425 balancing. 427 The terms "upstream" and "downstream" are used to describe 428 directional requirements in relation to the message flow: all 429 messages flow from upstream to downstream. The terms inbound and 430 outbound are used to describe directional requirements in relation to 431 the request route: "inbound" means toward the origin server and 432 "outbound" means toward the user agent. 434 A "proxy" is a message forwarding agent that is selected by the 435 client, usually via local configuration rules, to receive requests 436 for some type(s) of absolute URI and attempt to satisfy those 437 requests via translation through the HTTP interface. Some 438 translations are minimal, such as for proxy requests for "http" URIs, 439 whereas other requests might require translation to and from entirely 440 different application-level protocols. Proxies are often used to 441 group an organization's HTTP requests through a common intermediary 442 for the sake of security, annotation services, or shared caching. 443 Some proxies are designed to apply transformations to selected 444 messages or payloads while they are being forwarded, as described in 445 Section 5.7.2. 447 A "gateway" (a.k.a., "reverse proxy") is an intermediary that acts as 448 an origin server for the outbound connection, but translates received 449 requests and forwards them inbound to another server or servers. 450 Gateways are often used to encapsulate legacy or untrusted 451 information services, to improve server performance through 452 "accelerator" caching, and to enable partitioning or load balancing 453 of HTTP services across multiple machines. 455 All HTTP requirements applicable to an origin server also apply to 456 the outbound communication of a gateway. A gateway communicates with 457 inbound servers using any protocol that it desires, including private 458 extensions to HTTP that are outside the scope of this specification. 459 However, an HTTP-to-HTTP gateway that wishes to interoperate with 460 third-party HTTP servers ought to conform to user agent requirements 461 on the gateway's inbound connection. 463 A "tunnel" acts as a blind relay between two connections without 464 changing the messages. Once active, a tunnel is not considered a 465 party to the HTTP communication, though the tunnel might have been 466 initiated by an HTTP request. A tunnel ceases to exist when both 467 ends of the relayed connection are closed. Tunnels are used to 468 extend a virtual connection through an intermediary, such as when 469 Transport Layer Security (TLS, [RFC5246]) is used to establish 470 confidential communication through a shared firewall proxy. 472 The above categories for intermediary only consider those acting as 473 participants in the HTTP communication. There are also 474 intermediaries that can act on lower layers of the network protocol 475 stack, filtering or redirecting HTTP traffic without the knowledge or 476 permission of message senders. Network intermediaries are 477 indistinguishable (at a protocol level) from a man-in-the-middle 478 attack, often introducing security flaws or interoperability problems 479 due to mistakenly violating HTTP semantics. 481 For example, an "interception proxy" [RFC3040] (also commonly known 482 as a "transparent proxy" [RFC1919] or "captive portal") differs from 483 an HTTP proxy because it is not selected by the client. Instead, an 484 interception proxy filters or redirects outgoing TCP port 80 packets 485 (and occasionally other common port traffic). Interception proxies 486 are commonly found on public network access points, as a means of 487 enforcing account subscription prior to allowing use of non-local 488 Internet services, and within corporate firewalls to enforce network 489 usage policies. 491 HTTP is defined as a stateless protocol, meaning that each request 492 message can be understood in isolation. Many implementations depend 493 on HTTP's stateless design in order to reuse proxied connections or 494 dynamically load-balance requests across multiple servers. Hence, a 495 server MUST NOT assume that two requests on the same connection are 496 from the same user agent unless the connection is secured and 497 specific to that agent. Some non-standard HTTP extensions (e.g., 498 [RFC4559]) have been known to violate this requirement, resulting in 499 security and interoperability problems. 501 2.4. Caches 503 A "cache" is a local store of previous response messages and the 504 subsystem that controls its message storage, retrieval, and deletion. 505 A cache stores cacheable responses in order to reduce the response 506 time and network bandwidth consumption on future, equivalent 507 requests. Any client or server MAY employ a cache, though a cache 508 cannot be used by a server while it is acting as a tunnel. 510 The effect of a cache is that the request/response chain is shortened 511 if one of the participants along the chain has a cached response 512 applicable to that request. The following illustrates the resulting 513 chain if B has a cached copy of an earlier response from O (via C) 514 for a request that has not been cached by UA or A. 516 > > 517 UA =========== A =========== B - - - - - - C - - - - - - O 518 < < 520 A response is "cacheable" if a cache is allowed to store a copy of 521 the response message for use in answering subsequent requests. Even 522 when a response is cacheable, there might be additional constraints 523 placed by the client or by the origin server on when that cached 524 response can be used for a particular request. HTTP requirements for 525 cache behavior and cacheable responses are defined in Section 2 of 526 [Part6]. 528 There are a wide variety of architectures and configurations of 529 caches deployed across the World Wide Web and inside large 530 organizations. These include national hierarchies of proxy caches to 531 save transoceanic bandwidth, collaborative systems that broadcast or 532 multicast cache entries, archives of pre-fetched cache entries for 533 use in off-line or high-latency environments, and so on. 535 2.5. Conformance and Error Handling 537 This specification targets conformance criteria according to the role 538 of a participant in HTTP communication. Hence, HTTP requirements are 539 placed on senders, recipients, clients, servers, user agents, 540 intermediaries, origin servers, proxies, gateways, or caches, 541 depending on what behavior is being constrained by the requirement. 542 Additional (social) requirements are placed on implementations, 543 resource owners, and protocol element registrations when they apply 544 beyond the scope of a single communication. 546 The verb "generate" is used instead of "send" where a requirement 547 differentiates between creating a protocol element and merely 548 forwarding a received element downstream. 550 An implementation is considered conformant if it complies with all of 551 the requirements associated with the roles it partakes in HTTP. 553 Conformance includes both the syntax and semantics of protocol 554 elements. A sender MUST NOT generate protocol elements that convey a 555 meaning that is known by that sender to be false. A sender MUST NOT 556 generate protocol elements that do not match the grammar defined by 557 the corresponding ABNF rules. Within a given message, a sender MUST 558 NOT generate protocol elements or syntax alternatives that are only 559 allowed to be generated by participants in other roles (i.e., a role 560 that the sender does not have for that message). 562 When a received protocol element is parsed, the recipient MUST be 563 able to parse any value of reasonable length that is applicable to 564 the recipient's role and matches the grammar defined by the 565 corresponding ABNF rules. Note, however, that some received protocol 566 elements might not be parsed. For example, an intermediary 567 forwarding a message might parse a header-field into generic field- 568 name and field-value components, but then forward the header field 569 without further parsing inside the field-value. 571 HTTP does not have specific length limitations for many of its 572 protocol elements because the lengths that might be appropriate will 573 vary widely, depending on the deployment context and purpose of the 574 implementation. Hence, interoperability between senders and 575 recipients depends on shared expectations regarding what is a 576 reasonable length for each protocol element. Furthermore, what is 577 commonly understood to be a reasonable length for some protocol 578 elements has changed over the course of the past two decades of HTTP 579 use, and is expected to continue changing in the future. 581 At a minimum, a recipient MUST be able to parse and process protocol 582 element lengths that are at least as long as the values that it 583 generates for those same protocol elements in other messages. For 584 example, an origin server that publishes very long URI references to 585 its own resources needs to be able to parse and process those same 586 references when received as a request target. 588 A recipient MUST interpret a received protocol element according to 589 the semantics defined for it by this specification, including 590 extensions to this specification, unless the recipient has determined 591 (through experience or configuration) that the sender incorrectly 592 implements what is implied by those semantics. For example, an 593 origin server might disregard the contents of a received Accept- 594 Encoding header field if inspection of the User-Agent header field 595 indicates a specific implementation version that is known to fail on 596 receipt of certain content codings. 598 Unless noted otherwise, a recipient MAY attempt to recover a usable 599 protocol element from an invalid construct. HTTP does not define 600 specific error handling mechanisms except when they have a direct 601 impact on security, since different applications of the protocol 602 require different error handling strategies. For example, a Web 603 browser might wish to transparently recover from a response where the 604 Location header field doesn't parse according to the ABNF, whereas a 605 systems control client might consider any form of error recovery to 606 be dangerous. 608 2.6. Protocol Versioning 610 HTTP uses a "." numbering scheme to indicate versions 611 of the protocol. This specification defines version "1.1". The 612 protocol version as a whole indicates the sender's conformance with 613 the set of requirements laid out in that version's corresponding 614 specification of HTTP. 616 The version of an HTTP message is indicated by an HTTP-version field 617 in the first line of the message. HTTP-version is case-sensitive. 619 HTTP-version = HTTP-name "/" DIGIT "." DIGIT 620 HTTP-name = %x48.54.54.50 ; "HTTP", case-sensitive 622 The HTTP version number consists of two decimal digits separated by a 623 "." (period or decimal point). The first digit ("major version") 624 indicates the HTTP messaging syntax, whereas the second digit ("minor 625 version") indicates the highest minor version within that major 626 version to which the sender is conformant and able to understand for 627 future communication. The minor version advertises the sender's 628 communication capabilities even when the sender is only using a 629 backwards-compatible subset of the protocol, thereby letting the 630 recipient know that more advanced features can be used in response 631 (by servers) or in future requests (by clients). 633 When an HTTP/1.1 message is sent to an HTTP/1.0 recipient [RFC1945] 634 or a recipient whose version is unknown, the HTTP/1.1 message is 635 constructed such that it can be interpreted as a valid HTTP/1.0 636 message if all of the newer features are ignored. This specification 637 places recipient-version requirements on some new features so that a 638 conformant sender will only use compatible features until it has 639 determined, through configuration or the receipt of a message, that 640 the recipient supports HTTP/1.1. 642 The interpretation of a header field does not change between minor 643 versions of the same major HTTP version, though the default behavior 644 of a recipient in the absence of such a field can change. Unless 645 specified otherwise, header fields defined in HTTP/1.1 are defined 646 for all versions of HTTP/1.x. In particular, the Host and Connection 647 header fields ought to be implemented by all HTTP/1.x implementations 648 whether or not they advertise conformance with HTTP/1.1. 650 New header fields can be introduced without changing the protocol 651 version if their defined semantics allow them to be safely ignored by 652 recipients that do not recognize them. Header field extensibility is 653 discussed in Section 3.2.1. 655 Intermediaries that process HTTP messages (i.e., all intermediaries 656 other than those acting as tunnels) MUST send their own HTTP-version 657 in forwarded messages. In other words, they are not allowed to 658 blindly forward the first line of an HTTP message without ensuring 659 that the protocol version in that message matches a version to which 660 that intermediary is conformant for both the receiving and sending of 661 messages. Forwarding an HTTP message without rewriting the HTTP- 662 version might result in communication errors when downstream 663 recipients use the message sender's version to determine what 664 features are safe to use for later communication with that sender. 666 A client SHOULD send a request version equal to the highest version 667 to which the client is conformant and whose major version is no 668 higher than the highest version supported by the server, if this is 669 known. A client MUST NOT send a version to which it is not 670 conformant. 672 A client MAY send a lower request version if it is known that the 673 server incorrectly implements the HTTP specification, but only after 674 the client has attempted at least one normal request and determined 675 from the response status code or header fields (e.g., Server) that 676 the server improperly handles higher request versions. 678 A server SHOULD send a response version equal to the highest version 679 to which the server is conformant that has a major version less than 680 or equal to the one received in the request. A server MUST NOT send 681 a version to which it is not conformant. A server can send a 505 682 (HTTP Version Not Supported) response if it wishes, for any reason, 683 to refuse service of the client's major protocol version. 685 A server MAY send an HTTP/1.0 response to a request if it is known or 686 suspected that the client incorrectly implements the HTTP 687 specification and is incapable of correctly processing later version 688 responses, such as when a client fails to parse the version number 689 correctly or when an intermediary is known to blindly forward the 690 HTTP-version even when it doesn't conform to the given minor version 691 of the protocol. Such protocol downgrades SHOULD NOT be performed 692 unless triggered by specific client attributes, such as when one or 693 more of the request header fields (e.g., User-Agent) uniquely match 694 the values sent by a client known to be in error. 696 The intention of HTTP's versioning design is that the major number 697 will only be incremented if an incompatible message syntax is 698 introduced, and that the minor number will only be incremented when 699 changes made to the protocol have the effect of adding to the message 700 semantics or implying additional capabilities of the sender. 701 However, the minor version was not incremented for the changes 702 introduced between [RFC2068] and [RFC2616], and this revision has 703 specifically avoided any such changes to the protocol. 705 When an HTTP message is received with a major version number that the 706 recipient implements, but a higher minor version number than what the 707 recipient implements, the recipient SHOULD process the message as if 708 it were in the highest minor version within that major version to 709 which the recipient is conformant. A recipient can assume that a 710 message with a higher minor version, when sent to a recipient that 711 has not yet indicated support for that higher version, is 712 sufficiently backwards-compatible to be safely processed by any 713 implementation of the same major version. 715 2.7. Uniform Resource Identifiers 717 Uniform Resource Identifiers (URIs) [RFC3986] are used throughout 718 HTTP as the means for identifying resources (Section 2 of [Part2]). 719 URI references are used to target requests, indicate redirects, and 720 define relationships. 722 The definitions of "URI-reference", "absolute-URI", "relative-part", 723 "scheme", "authority", "port", "host", "path-abempty", "segment", 724 "query", and "fragment" are adopted from the URI generic syntax. An 725 "absolute-path" rule is defined for protocol elements that can 726 contain a non-empty path component. (This rule differs slightly from 727 RFC 3986's path-abempty rule, which allows for an empty path to be 728 used in references, and path-absolute rule, which does not allow 729 paths that begin with "//".) A "partial-URI" rule is defined for 730 protocol elements that can contain a relative URI but not a fragment 731 component. 733 URI-reference = 734 absolute-URI = 735 relative-part = 736 scheme = 737 authority = 738 uri-host = 739 port = 740 path-abempty = 741 segment = 742 query = 743 fragment = 745 absolute-path = 1*( "/" segment ) 746 partial-URI = relative-part [ "?" query ] 748 Each protocol element in HTTP that allows a URI reference will 749 indicate in its ABNF production whether the element allows any form 750 of reference (URI-reference), only a URI in absolute form (absolute- 751 URI), only the path and optional query components, or some 752 combination of the above. Unless otherwise indicated, URI references 753 are parsed relative to the effective request URI (Section 5.5). 755 2.7.1. http URI scheme 757 The "http" URI scheme is hereby defined for the purpose of minting 758 identifiers according to their association with the hierarchical 759 namespace governed by a potential HTTP origin server listening for 760 TCP ([RFC0793]) connections on a given port. 762 http-URI = "http:" "//" authority path-abempty [ "?" query ] 764 [ "#" fragment ] 766 The origin server for an "http" URI is identified by the authority 767 component, which includes a host identifier and optional TCP port 768 ([RFC3986], Section 3.2.2). The hierarchical path component and 769 optional query component serve as an identifier for a potential 770 target resource within that origin server's name space. The optional 771 fragment component allows for indirect identification of a secondary 772 resource, independent of the URI scheme, as defined in Section 3.5 of 773 [RFC3986]. 775 A sender MUST NOT generate an "http" URI with an empty host 776 identifier. A recipient that processes such a URI reference MUST 777 reject it as invalid. 779 If the host identifier is provided as an IP address, the origin 780 server is the listener (if any) on the indicated TCP port at that IP 781 address. If host is a registered name, the registered name is an 782 indirect identifier for use with a name resolution service, such as 783 DNS, to find an address for that origin server. If the port 784 subcomponent is empty or not given, TCP port 80 (the reserved port 785 for WWW services) is the default. 787 Note that the presence of a URI with a given authority component does 788 not imply that there is always an HTTP server listening for 789 connections on that host and port. Anyone can mint a URI. What the 790 authority component determines is who has the right to respond 791 authoritatively to requests that target the identified resource. The 792 delegated nature of registered names and IP addresses creates a 793 federated namespace, based on control over the indicated host and 794 port, whether or not an HTTP server is present. See Section 9.1 for 795 security considerations related to establishing authority. 797 When an "http" URI is used within a context that calls for access to 798 the indicated resource, a client MAY attempt access by resolving the 799 host to an IP address, establishing a TCP connection to that address 800 on the indicated port, and sending an HTTP request message 801 (Section 3) containing the URI's identifying data (Section 5) to the 802 server. If the server responds to that request with a non-interim 803 HTTP response message, as described in Section 6 of [Part2], then 804 that response is considered an authoritative answer to the client's 805 request. 807 Although HTTP is independent of the transport protocol, the "http" 808 scheme is specific to TCP-based services because the name delegation 809 process depends on TCP for establishing authority. An HTTP service 810 based on some other underlying connection protocol would presumably 811 be identified using a different URI scheme, just as the "https" 812 scheme (below) is used for resources that require an end-to-end 813 secured connection. Other protocols might also be used to provide 814 access to "http" identified resources -- it is only the authoritative 815 interface that is specific to TCP. 817 The URI generic syntax for authority also includes a deprecated 818 userinfo subcomponent ([RFC3986], Section 3.2.1) for including user 819 authentication information in the URI. Some implementations make use 820 of the userinfo component for internal configuration of 821 authentication information, such as within command invocation 822 options, configuration files, or bookmark lists, even though such 823 usage might expose a user identifier or password. A sender MUST NOT 824 generate the userinfo subcomponent (and its "@" delimiter) when an 825 "http" URI reference is generated within a message as a request 826 target or header field value. Before making use of an "http" URI 827 reference received from an untrusted source, a recipient SHOULD parse 828 for userinfo and treat its presence as an error; it is likely being 829 used to obscure the authority for the sake of phishing attacks. 831 2.7.2. https URI scheme 833 The "https" URI scheme is hereby defined for the purpose of minting 834 identifiers according to their association with the hierarchical 835 namespace governed by a potential HTTP origin server listening to a 836 given TCP port for TLS-secured connections ([RFC5246]). 838 All of the requirements listed above for the "http" scheme are also 839 requirements for the "https" scheme, except that TCP port 443 is the 840 default if the port subcomponent is empty or not given, and the user 841 agent MUST ensure that its connection to the origin server is secured 842 through the use of strong encryption, end-to-end, prior to sending 843 the first HTTP request. 845 https-URI = "https:" "//" authority path-abempty [ "?" query ] 846 [ "#" fragment ] 848 Note that the "https" URI scheme depends on both TLS and TCP for 849 establishing authority. Resources made available via the "https" 850 scheme have no shared identity with the "http" scheme even if their 851 resource identifiers indicate the same authority (the same host 852 listening to the same TCP port). They are distinct name spaces and 853 are considered to be distinct origin servers. However, an extension 854 to HTTP that is defined to apply to entire host domains, such as the 855 Cookie protocol [RFC6265], can allow information set by one service 856 to impact communication with other services within a matching group 857 of host domains. 859 The process for authoritative access to an "https" identified 860 resource is defined in [RFC2818]. 862 2.7.3. http and https URI Normalization and Comparison 864 Since the "http" and "https" schemes conform to the URI generic 865 syntax, such URIs are normalized and compared according to the 866 algorithm defined in Section 6 of [RFC3986], using the defaults 867 described above for each scheme. 869 If the port is equal to the default port for a scheme, the normal 870 form is to omit the port subcomponent. When not being used in 871 absolute form as the request target of an OPTIONS request, an empty 872 path component is equivalent to an absolute path of "/", so the 873 normal form is to provide a path of "/" instead. The scheme and host 874 are case-insensitive and normally provided in lowercase; all other 875 components are compared in a case-sensitive manner. Characters other 876 than those in the "reserved" set are equivalent to their percent- 877 encoded octets: the normal form is to not encode them (see Sections 878 2.1 and 2.2 of [RFC3986]). 880 For example, the following three URIs are equivalent: 882 http://example.com:80/~smith/home.html 883 http://EXAMPLE.com/%7Esmith/home.html 884 http://EXAMPLE.com:/%7esmith/home.html 886 3. Message Format 888 All HTTP/1.1 messages consist of a start-line followed by a sequence 889 of octets in a format similar to the Internet Message Format 890 [RFC5322]: zero or more header fields (collectively referred to as 891 the "headers" or the "header section"), an empty line indicating the 892 end of the header section, and an optional message body. 894 HTTP-message = start-line 895 *( header-field CRLF ) 896 CRLF 897 [ message-body ] 899 The normal procedure for parsing an HTTP message is to read the 900 start-line into a structure, read each header field into a hash table 901 by field name until the empty line, and then use the parsed data to 902 determine if a message body is expected. If a message body has been 903 indicated, then it is read as a stream until an amount of octets 904 equal to the message body length is read or the connection is closed. 906 A recipient MUST parse an HTTP message as a sequence of octets in an 907 encoding that is a superset of US-ASCII [USASCII]. Parsing an HTTP 908 message as a stream of Unicode characters, without regard for the 909 specific encoding, creates security vulnerabilities due to the 910 varying ways that string processing libraries handle invalid 911 multibyte character sequences that contain the octet LF (%x0A). 912 String-based parsers can only be safely used within protocol elements 913 after the element has been extracted from the message, such as within 914 a header field-value after message parsing has delineated the 915 individual fields. 917 An HTTP message can be parsed as a stream for incremental processing 918 or forwarding downstream. However, recipients cannot rely on 919 incremental delivery of partial messages, since some implementations 920 will buffer or delay message forwarding for the sake of network 921 efficiency, security checks, or payload transformations. 923 A sender MUST NOT send whitespace between the start-line and the 924 first header field. A recipient that receives whitespace between the 925 start-line and the first header field MUST either reject the message 926 as invalid or consume each whitespace-preceded line without further 927 processing of it (i.e., ignore the entire line, along with any 928 subsequent lines preceded by whitespace, until a properly formed 929 header field is received or the header section is terminated). 931 The presence of such whitespace in a request might be an attempt to 932 trick a server into ignoring that field or processing the line after 933 it as a new request, either of which might result in a security 934 vulnerability if other implementations within the request chain 935 interpret the same message differently. Likewise, the presence of 936 such whitespace in a response might be ignored by some clients or 937 cause others to cease parsing. 939 3.1. Start Line 941 An HTTP message can either be a request from client to server or a 942 response from server to client. Syntactically, the two types of 943 message differ only in the start-line, which is either a request-line 944 (for requests) or a status-line (for responses), and in the algorithm 945 for determining the length of the message body (Section 3.3). 947 In theory, a client could receive requests and a server could receive 948 responses, distinguishing them by their different start-line formats, 949 but in practice servers are implemented to only expect a request (a 950 response is interpreted as an unknown or invalid request method) and 951 clients are implemented to only expect a response. 953 start-line = request-line / status-line 955 3.1.1. Request Line 957 A request-line begins with a method token, followed by a single space 958 (SP), the request-target, another single space (SP), the protocol 959 version, and ending with CRLF. 961 request-line = method SP request-target SP HTTP-version CRLF 963 The method token indicates the request method to be performed on the 964 target resource. The request method is case-sensitive. 966 method = token 968 The request methods defined by this specification can be found in 969 Section 4 of [Part2], along with information regarding the HTTP 970 method registry and considerations for defining new methods. 972 The request-target identifies the target resource upon which to apply 973 the request, as defined in Section 5.3. 975 Recipients typically parse the request-line into its component parts 976 by splitting on whitespace (see Section 3.5), since no whitespace is 977 allowed in the three components. Unfortunately, some user agents 978 fail to properly encode or exclude whitespace found in hypertext 979 references, resulting in those disallowed characters being sent in a 980 request-target. 982 Recipients of an invalid request-line SHOULD respond with either a 983 400 (Bad Request) error or a 301 (Moved Permanently) redirect with 984 the request-target properly encoded. A recipient SHOULD NOT attempt 985 to autocorrect and then process the request without a redirect, since 986 the invalid request-line might be deliberately crafted to bypass 987 security filters along the request chain. 989 HTTP does not place a pre-defined limit on the length of a request- 990 line, as described in Section 2.5. A server that receives a method 991 longer than any that it implements SHOULD respond with a 501 (Not 992 Implemented) status code. A server that receives a request-target 993 longer than any URI it wishes to parse MUST respond with a 414 (URI 994 Too Long) status code (see Section 6.5.12 of [Part2]). 996 Various ad-hoc limitations on request-line length are found in 997 practice. It is RECOMMENDED that all HTTP senders and recipients 998 support, at a minimum, request-line lengths of 8000 octets. 1000 3.1.2. Status Line 1002 The first line of a response message is the status-line, consisting 1003 of the protocol version, a space (SP), the status code, another 1004 space, a possibly-empty textual phrase describing the status code, 1005 and ending with CRLF. 1007 status-line = HTTP-version SP status-code SP reason-phrase CRLF 1009 The status-code element is a 3-digit integer code describing the 1010 result of the server's attempt to understand and satisfy the client's 1011 corresponding request. The rest of the response message is to be 1012 interpreted in light of the semantics defined for that status code. 1013 See Section 6 of [Part2] for information about the semantics of 1014 status codes, including the classes of status code (indicated by the 1015 first digit), the status codes defined by this specification, 1016 considerations for the definition of new status codes, and the IANA 1017 registry. 1019 status-code = 3DIGIT 1021 The reason-phrase element exists for the sole purpose of providing a 1022 textual description associated with the numeric status code, mostly 1023 out of deference to earlier Internet application protocols that were 1024 more frequently used with interactive text clients. A client SHOULD 1025 ignore the reason-phrase content. 1027 reason-phrase = *( HTAB / SP / VCHAR / obs-text ) 1029 3.2. Header Fields 1031 Each header field consists of a case-insensitive field name followed 1032 by a colon (":"), optional leading whitespace, the field value, and 1033 optional trailing whitespace. 1035 header-field = field-name ":" OWS field-value OWS 1037 field-name = token 1038 field-value = *( field-content / obs-fold ) 1039 field-content = field-vchar [ 1*( SP / HTAB ) field-vchar ] 1040 field-vchar = VCHAR / obs-text 1042 obs-fold = CRLF 1*( SP / HTAB ) 1043 ; obsolete line folding 1044 ; see Section 3.2.4 1046 The field-name token labels the corresponding field-value as having 1047 the semantics defined by that header field. For example, the Date 1048 header field is defined in Section 7.1.1.2 of [Part2] as containing 1049 the origination timestamp for the message in which it appears. 1051 3.2.1. Field Extensibility 1053 Header fields are fully extensible: there is no limit on the 1054 introduction of new field names, each presumably defining new 1055 semantics, nor on the number of header fields used in a given 1056 message. Existing fields are defined in each part of this 1057 specification and in many other specifications outside this document 1058 set. 1060 New header fields can be defined such that, when they are understood 1061 by a recipient, they might override or enhance the interpretation of 1062 previously defined header fields, define preconditions on request 1063 evaluation, or refine the meaning of responses. 1065 A proxy MUST forward unrecognized header fields unless the field-name 1066 is listed in the Connection header field (Section 6.1) or the proxy 1067 is specifically configured to block, or otherwise transform, such 1068 fields. Other recipients SHOULD ignore unrecognized header fields. 1069 These requirements allow HTTP's functionality to be enhanced without 1070 requiring prior update of deployed intermediaries. 1072 All defined header fields ought to be registered with IANA in the 1073 Message Header Field Registry, as described in Section 8.3 of 1074 [Part2]. 1076 3.2.2. Field Order 1078 The order in which header fields with differing field names are 1079 received is not significant. However, it is good practice to send 1080 header fields that contain control data first, such as Host on 1081 requests and Date on responses, so that implementations can decide 1082 when not to handle a message as early as possible. A server MUST NOT 1083 apply a request to the target resource until the entire request 1084 header section is received, since later header fields might include 1085 conditionals, authentication credentials, or deliberately misleading 1086 duplicate header fields that would impact request processing. 1088 A sender MUST NOT generate multiple header fields with the same field 1089 name in a message unless either the entire field value for that 1090 header field is defined as a comma-separated list [i.e., #(values)] 1091 or the header field is a well-known exception (as noted below). 1093 A recipient MAY combine multiple header fields with the same field 1094 name into one "field-name: field-value" pair, without changing the 1095 semantics of the message, by appending each subsequent field value to 1096 the combined field value in order, separated by a comma. The order 1097 in which header fields with the same field name are received is 1098 therefore significant to the interpretation of the combined field 1099 value; a proxy MUST NOT change the order of these field values when 1100 forwarding a message. 1102 Note: In practice, the "Set-Cookie" header field ([RFC6265]) often 1103 appears multiple times in a response message and does not use the 1104 list syntax, violating the above requirements on multiple header 1105 fields with the same name. Since it cannot be combined into a 1106 single field-value, recipients ought to handle "Set-Cookie" as a 1107 special case while processing header fields. (See Appendix A.2.3 1108 of [Kri2001] for details.) 1110 3.2.3. Whitespace 1112 This specification uses three rules to denote the use of linear 1113 whitespace: OWS (optional whitespace), RWS (required whitespace), and 1114 BWS ("bad" whitespace). 1116 The OWS rule is used where zero or more linear whitespace octets 1117 might appear. For protocol elements where optional whitespace is 1118 preferred to improve readability, a sender SHOULD generate the 1119 optional whitespace as a single SP; otherwise, a sender SHOULD NOT 1120 generate optional whitespace except as needed to white-out invalid or 1121 unwanted protocol elements during in-place message filtering. 1123 The RWS rule is used when at least one linear whitespace octet is 1124 required to separate field tokens. A sender SHOULD generate RWS as a 1125 single SP. 1127 The BWS rule is used where the grammar allows optional whitespace 1128 only for historical reasons. A sender MUST NOT generate BWS in 1129 messages. A recipient MUST parse for such bad whitespace and remove 1130 it before interpreting the protocol element. 1132 OWS = *( SP / HTAB ) 1133 ; optional whitespace 1134 RWS = 1*( SP / HTAB ) 1135 ; required whitespace 1136 BWS = OWS 1137 ; "bad" whitespace 1139 3.2.4. Field Parsing 1141 Messages are parsed using a generic algorithm, independent of the 1142 individual header field names. The contents within a given field 1143 value are not parsed until a later stage of message interpretation 1144 (usually after the message's entire header section has been 1145 processed). Consequently, this specification does not use ABNF rules 1146 to define each "Field-Name: Field Value" pair, as was done in 1147 previous editions. Instead, this specification uses ABNF rules which 1148 are named according to each registered field name, wherein the rule 1149 defines the valid grammar for that field's corresponding field values 1150 (i.e., after the field-value has been extracted from the header 1151 section by a generic field parser). 1153 No whitespace is allowed between the header field-name and colon. In 1154 the past, differences in the handling of such whitespace have led to 1155 security vulnerabilities in request routing and response handling. A 1156 server MUST reject any received request message that contains 1157 whitespace between a header field-name and colon with a response code 1158 of 400 (Bad Request). A proxy MUST remove any such whitespace from a 1159 response message before forwarding the message downstream. 1161 A field value might be preceded and/or followed by optional 1162 whitespace (OWS); a single SP preceding the field-value is preferred 1163 for consistent readability by humans. The field value does not 1164 include any leading or trailing white space: OWS occurring before the 1165 first non-whitespace octet of the field value or after the last non- 1166 whitespace octet of the field value ought to be excluded by parsers 1167 when extracting the field value from a header field. 1169 Historically, HTTP header field values could be extended over 1170 multiple lines by preceding each extra line with at least one space 1171 or horizontal tab (obs-fold). This specification deprecates such 1172 line folding except within the message/http media type 1173 (Section 8.3.1). A sender MUST NOT generate a message that includes 1174 line folding (i.e., that has any field-value that contains a match to 1175 the obs-fold rule) unless the message is intended for packaging 1176 within the message/http media type. 1178 A server that receives an obs-fold in a request message that is not 1179 within a message/http container MUST either reject the message by 1180 sending a 400 (Bad Request), preferably with a representation 1181 explaining that obsolete line folding is unacceptable, or replace 1182 each received obs-fold with one or more SP octets prior to 1183 interpreting the field value or forwarding the message downstream. 1185 A proxy or gateway that receives an obs-fold in a response message 1186 that is not within a message/http container MUST either discard the 1187 message and replace it with a 502 (Bad Gateway) response, preferably 1188 with a representation explaining that unacceptable line folding was 1189 received, or replace each received obs-fold with one or more SP 1190 octets prior to interpreting the field value or forwarding the 1191 message downstream. 1193 A user agent that receives an obs-fold in a response message that is 1194 not within a message/http container MUST replace each received obs- 1195 fold with one or more SP octets prior to interpreting the field 1196 value. 1198 Historically, HTTP has allowed field content with text in the ISO- 1199 8859-1 [ISO-8859-1] charset, supporting other charsets only through 1200 use of [RFC2047] encoding. In practice, most HTTP header field 1201 values use only a subset of the US-ASCII charset [USASCII]. Newly 1202 defined header fields SHOULD limit their field values to US-ASCII 1203 octets. A recipient SHOULD treat other octets in field content (obs- 1204 text) as opaque data. 1206 3.2.5. Field Limits 1208 HTTP does not place a pre-defined limit on the length of each header 1209 field or on the length of the header section as a whole, as described 1210 in Section 2.5. Various ad-hoc limitations on individual header 1211 field length are found in practice, often depending on the specific 1212 field semantics. 1214 A server that receives a request header field, or set of fields, 1215 larger than it wishes to process MUST respond with an appropriate 4xx 1216 (Client Error) status code. Ignoring such header fields would 1217 increase the server's vulnerability to request smuggling attacks 1218 (Section 9.5). 1220 A client MAY discard or truncate received header fields that are 1221 larger than the client wishes to process if the field semantics are 1222 such that the dropped value(s) can be safely ignored without changing 1223 the message framing or response semantics. 1225 3.2.6. Field value components 1227 Most HTTP header field values are defined using common syntax 1228 components (token, quoted-string, and comment) separated by 1229 whitespace or specific delimiting characters. Delimiters are chosen 1230 from the set of US-ASCII visual characters not allowed in a token 1231 (DQUOTE and "(),/:;<=>?@[\]{}"). 1233 token = 1*tchar 1235 tchar = "!" / "#" / "$" / "%" / "&" / "'" / "*" 1236 / "+" / "-" / "." / "^" / "_" / "`" / "|" / "~" 1237 / DIGIT / ALPHA 1238 ; any VCHAR, except delimiters 1240 A string of text is parsed as a single value if it is quoted using 1241 double-quote marks. 1243 quoted-string = DQUOTE *( qdtext / quoted-pair ) DQUOTE 1244 qdtext = HTAB / SP /%x21 / %x23-5B / %x5D-7E / obs-text 1245 obs-text = %x80-FF 1247 Comments can be included in some HTTP header fields by surrounding 1248 the comment text with parentheses. Comments are only allowed in 1249 fields containing "comment" as part of their field value definition. 1251 comment = "(" *( ctext / quoted-pair / comment ) ")" 1252 ctext = HTAB / SP / %x21-27 / %x2A-5B / %x5D-7E / obs-text 1254 The backslash octet ("\") can be used as a single-octet quoting 1255 mechanism within quoted-string and comment constructs. Recipients 1256 that process the value of a quoted-string MUST handle a quoted-pair 1257 as if it were replaced by the octet following the backslash. 1259 quoted-pair = "\" ( HTAB / SP / VCHAR / obs-text ) 1261 A sender SHOULD NOT generate a quoted-pair in a quoted-string except 1262 where necessary to quote DQUOTE and backslash octets occurring within 1263 that string. A sender SHOULD NOT generate a quoted-pair in a comment 1264 except where necessary to quote parentheses ["(" and ")"] and 1265 backslash octets occurring within that comment. 1267 3.3. Message Body 1269 The message body (if any) of an HTTP message is used to carry the 1270 payload body of that request or response. The message body is 1271 identical to the payload body unless a transfer coding has been 1272 applied, as described in Section 3.3.1. 1274 message-body = *OCTET 1276 The rules for when a message body is allowed in a message differ for 1277 requests and responses. 1279 The presence of a message body in a request is signaled by a Content- 1280 Length or Transfer-Encoding header field. Request message framing is 1281 independent of method semantics, even if the method does not define 1282 any use for a message body. 1284 The presence of a message body in a response depends on both the 1285 request method to which it is responding and the response status code 1286 (Section 3.1.2). Responses to the HEAD request method (Section 4.3.2 1287 of [Part2]) never include a message body because the associated 1288 response header fields (e.g., Transfer-Encoding, Content-Length, 1289 etc.), if present, indicate only what their values would have been if 1290 the request method had been GET (Section 4.3.1 of [Part2]). 2xx 1291 (Successful) responses to a CONNECT request method (Section 4.3.6 of 1292 [Part2]) switch to tunnel mode instead of having a message body. All 1293 1xx (Informational), 204 (No Content), and 304 (Not Modified) 1294 responses do not include a message body. All other responses do 1295 include a message body, although the body might be of zero length. 1297 3.3.1. Transfer-Encoding 1299 The Transfer-Encoding header field lists the transfer coding names 1300 corresponding to the sequence of transfer codings that have been (or 1301 will be) applied to the payload body in order to form the message 1302 body. Transfer codings are defined in Section 4. 1304 Transfer-Encoding = 1#transfer-coding 1306 Transfer-Encoding is analogous to the Content-Transfer-Encoding field 1307 of MIME, which was designed to enable safe transport of binary data 1308 over a 7-bit transport service ([RFC2045], Section 6). However, safe 1309 transport has a different focus for an 8bit-clean transfer protocol. 1310 In HTTP's case, Transfer-Encoding is primarily intended to accurately 1311 delimit a dynamically generated payload and to distinguish payload 1312 encodings that are only applied for transport efficiency or security 1313 from those that are characteristics of the selected resource. 1315 A recipient MUST be able to parse the chunked transfer coding 1316 (Section 4.1) because it plays a crucial role in framing messages 1317 when the payload body size is not known in advance. A sender MUST 1318 NOT apply chunked more than once to a message body (i.e., chunking an 1319 already chunked message is not allowed). If any transfer coding 1320 other than chunked is applied to a request payload body, the sender 1321 MUST apply chunked as the final transfer coding to ensure that the 1322 message is properly framed. If any transfer coding other than 1323 chunked is applied to a response payload body, the sender MUST either 1324 apply chunked as the final transfer coding or terminate the message 1325 by closing the connection. 1327 For example, 1329 Transfer-Encoding: gzip, chunked 1331 indicates that the payload body has been compressed using the gzip 1332 coding and then chunked using the chunked coding while forming the 1333 message body. 1335 Unlike Content-Encoding (Section 3.1.2.1 of [Part2]), Transfer- 1336 Encoding is a property of the message, not of the representation, and 1337 any recipient along the request/response chain MAY decode the 1338 received transfer coding(s) or apply additional transfer coding(s) to 1339 the message body, assuming that corresponding changes are made to the 1340 Transfer-Encoding field-value. Additional information about the 1341 encoding parameters can be provided by other header fields not 1342 defined by this specification. 1344 Transfer-Encoding MAY be sent in a response to a HEAD request or in a 1345 304 (Not Modified) response (Section 4.1 of [Part4]) to a GET 1346 request, neither of which includes a message body, to indicate that 1347 the origin server would have applied a transfer coding to the message 1348 body if the request had been an unconditional GET. This indication 1349 is not required, however, because any recipient on the response chain 1350 (including the origin server) can remove transfer codings when they 1351 are not needed. 1353 A server MUST NOT send a Transfer-Encoding header field in any 1354 response with a status code of 1xx (Informational) or 204 (No 1355 Content). A server MUST NOT send a Transfer-Encoding header field in 1356 any 2xx (Successful) response to a CONNECT request (Section 4.3.6 of 1357 [Part2]). 1359 Transfer-Encoding was added in HTTP/1.1. It is generally assumed 1360 that implementations advertising only HTTP/1.0 support will not 1361 understand how to process a transfer-encoded payload. A client MUST 1362 NOT send a request containing Transfer-Encoding unless it knows the 1363 server will handle HTTP/1.1 (or later) requests; such knowledge might 1364 be in the form of specific user configuration or by remembering the 1365 version of a prior received response. A server MUST NOT send a 1366 response containing Transfer-Encoding unless the corresponding 1367 request indicates HTTP/1.1 (or later). 1369 A server that receives a request message with a transfer coding it 1370 does not understand SHOULD respond with 501 (Not Implemented). 1372 3.3.2. Content-Length 1374 When a message does not have a Transfer-Encoding header field, a 1375 Content-Length header field can provide the anticipated size, as a 1376 decimal number of octets, for a potential payload body. For messages 1377 that do include a payload body, the Content-Length field-value 1378 provides the framing information necessary for determining where the 1379 body (and message) ends. For messages that do not include a payload 1380 body, the Content-Length indicates the size of the selected 1381 representation (Section 3 of [Part2]). 1383 Content-Length = 1*DIGIT 1385 An example is 1387 Content-Length: 3495 1389 A sender MUST NOT send a Content-Length header field in any message 1390 that contains a Transfer-Encoding header field. 1392 A user agent SHOULD send a Content-Length in a request message when 1393 no Transfer-Encoding is sent and the request method defines a meaning 1394 for an enclosed payload body. For example, a Content-Length header 1395 field is normally sent in a POST request even when the value is 0 1396 (indicating an empty payload body). A user agent SHOULD NOT send a 1397 Content-Length header field when the request message does not contain 1398 a payload body and the method semantics do not anticipate such a 1399 body. 1401 A server MAY send a Content-Length header field in a response to a 1402 HEAD request (Section 4.3.2 of [Part2]); a server MUST NOT send 1403 Content-Length in such a response unless its field-value equals the 1404 decimal number of octets that would have been sent in the payload 1405 body of a response if the same request had used the GET method. 1407 A server MAY send a Content-Length header field in a 304 (Not 1408 Modified) response to a conditional GET request (Section 4.1 of 1409 [Part4]); a server MUST NOT send Content-Length in such a response 1410 unless its field-value equals the decimal number of octets that would 1411 have been sent in the payload body of a 200 (OK) response to the same 1412 request. 1414 A server MUST NOT send a Content-Length header field in any response 1415 with a status code of 1xx (Informational) or 204 (No Content). A 1416 server MUST NOT send a Content-Length header field in any 2xx 1417 (Successful) response to a CONNECT request (Section 4.3.6 of 1418 [Part2]). 1420 Aside from the cases defined above, in the absence of Transfer- 1421 Encoding, an origin server SHOULD send a Content-Length header field 1422 when the payload body size is known prior to sending the complete 1423 header section. This will allow downstream recipients to measure 1424 transfer progress, know when a received message is complete, and 1425 potentially reuse the connection for additional requests. 1427 Any Content-Length field value greater than or equal to zero is 1428 valid. Since there is no predefined limit to the length of a 1429 payload, a recipient MUST anticipate potentially large decimal 1430 numerals and prevent parsing errors due to integer conversion 1431 overflows (Section 9.3). 1433 If a message is received that has multiple Content-Length header 1434 fields with field-values consisting of the same decimal value, or a 1435 single Content-Length header field with a field value containing a 1436 list of identical decimal values (e.g., "Content-Length: 42, 42"), 1437 indicating that duplicate Content-Length header fields have been 1438 generated or combined by an upstream message processor, then the 1439 recipient MUST either reject the message as invalid or replace the 1440 duplicated field-values with a single valid Content-Length field 1441 containing that decimal value prior to determining the message body 1442 length or forwarding the message. 1444 Note: HTTP's use of Content-Length for message framing differs 1445 significantly from the same field's use in MIME, where it is an 1446 optional field used only within the "message/external-body" media- 1447 type. 1449 3.3.3. Message Body Length 1451 The length of a message body is determined by one of the following 1452 (in order of precedence): 1454 1. Any response to a HEAD request and any response with a 1xx 1455 (Informational), 204 (No Content), or 304 (Not Modified) status 1456 code is always terminated by the first empty line after the 1457 header fields, regardless of the header fields present in the 1458 message, and thus cannot contain a message body. 1460 2. Any 2xx (Successful) response to a CONNECT request implies that 1461 the connection will become a tunnel immediately after the empty 1462 line that concludes the header fields. A client MUST ignore any 1463 Content-Length or Transfer-Encoding header fields received in 1464 such a message. 1466 3. If a Transfer-Encoding header field is present and the chunked 1467 transfer coding (Section 4.1) is the final encoding, the message 1468 body length is determined by reading and decoding the chunked 1469 data until the transfer coding indicates the data is complete. 1471 If a Transfer-Encoding header field is present in a response and 1472 the chunked transfer coding is not the final encoding, the 1473 message body length is determined by reading the connection until 1474 it is closed by the server. If a Transfer-Encoding header field 1475 is present in a request and the chunked transfer coding is not 1476 the final encoding, the message body length cannot be determined 1477 reliably; the server MUST respond with the 400 (Bad Request) 1478 status code and then close the connection. 1480 If a message is received with both a Transfer-Encoding and a 1481 Content-Length header field, the Transfer-Encoding overrides the 1482 Content-Length. Such a message might indicate an attempt to 1483 perform request smuggling (Section 9.5) or response splitting 1484 (Section 9.4) and ought to be handled as an error. A sender MUST 1485 remove the received Content-Length field prior to forwarding such 1486 a message downstream. 1488 4. If a message is received without Transfer-Encoding and with 1489 either multiple Content-Length header fields having differing 1490 field-values or a single Content-Length header field having an 1491 invalid value, then the message framing is invalid and the 1492 recipient MUST treat it as an unrecoverable error. If this is a 1493 request message, the server MUST respond with a 400 (Bad Request) 1494 status code and then close the connection. If this is a response 1495 message received by a proxy, the proxy MUST close the connection 1496 to the server, discard the received response, and send a 502 (Bad 1497 Gateway) response to the client. If this is a response message 1498 received by a user agent, the user agent MUST close the 1499 connection to the server and discard the received response. 1501 5. If a valid Content-Length header field is present without 1502 Transfer-Encoding, its decimal value defines the expected message 1503 body length in octets. If the sender closes the connection or 1504 the recipient times out before the indicated number of octets are 1505 received, the recipient MUST consider the message to be 1506 incomplete and close the connection. 1508 6. If this is a request message and none of the above are true, then 1509 the message body length is zero (no message body is present). 1511 7. Otherwise, this is a response message without a declared message 1512 body length, so the message body length is determined by the 1513 number of octets received prior to the server closing the 1514 connection. 1516 Since there is no way to distinguish a successfully completed, close- 1517 delimited message from a partially-received message interrupted by 1518 network failure, a server SHOULD generate encoding or length- 1519 delimited messages whenever possible. The close-delimiting feature 1520 exists primarily for backwards compatibility with HTTP/1.0. 1522 A server MAY reject a request that contains a message body but not a 1523 Content-Length by responding with 411 (Length Required). 1525 Unless a transfer coding other than chunked has been applied, a 1526 client that sends a request containing a message body SHOULD use a 1527 valid Content-Length header field if the message body length is known 1528 in advance, rather than the chunked transfer coding, since some 1529 existing services respond to chunked with a 411 (Length Required) 1530 status code even though they understand the chunked transfer coding. 1531 This is typically because such services are implemented via a gateway 1532 that requires a content-length in advance of being called and the 1533 server is unable or unwilling to buffer the entire request before 1534 processing. 1536 A user agent that sends a request containing a message body MUST send 1537 a valid Content-Length header field if it does not know the server 1538 will handle HTTP/1.1 (or later) requests; such knowledge can be in 1539 the form of specific user configuration or by remembering the version 1540 of a prior received response. 1542 If the final response to the last request on a connection has been 1543 completely received and there remains additional data to read, a user 1544 agent MAY discard the remaining data or attempt to determine if that 1545 data belongs as part of the prior response body, which might be the 1546 case if the prior message's Content-Length value is incorrect. A 1547 client MUST NOT process, cache, or forward such extra data as a 1548 separate response, since such behavior would be vulnerable to cache 1549 poisoning. 1551 3.4. Handling Incomplete Messages 1553 A server that receives an incomplete request message, usually due to 1554 a canceled request or a triggered time-out exception, MAY send an 1555 error response prior to closing the connection. 1557 A client that receives an incomplete response message, which can 1558 occur when a connection is closed prematurely or when decoding a 1559 supposedly chunked transfer coding fails, MUST record the message as 1560 incomplete. Cache requirements for incomplete responses are defined 1561 in Section 3 of [Part6]. 1563 If a response terminates in the middle of the header section (before 1564 the empty line is received) and the status code might rely on header 1565 fields to convey the full meaning of the response, then the client 1566 cannot assume that meaning has been conveyed; the client might need 1567 to repeat the request in order to determine what action to take next. 1569 A message body that uses the chunked transfer coding is incomplete if 1570 the zero-sized chunk that terminates the encoding has not been 1571 received. A message that uses a valid Content-Length is incomplete 1572 if the size of the message body received (in octets) is less than the 1573 value given by Content-Length. A response that has neither chunked 1574 transfer coding nor Content-Length is terminated by closure of the 1575 connection, and thus is considered complete regardless of the number 1576 of message body octets received, provided that the header section was 1577 received intact. 1579 3.5. Message Parsing Robustness 1581 Older HTTP/1.0 user agent implementations might send an extra CRLF 1582 after a POST request as a workaround for some early server 1583 applications that failed to read message body content that was not 1584 terminated by a line-ending. An HTTP/1.1 user agent MUST NOT preface 1585 or follow a request with an extra CRLF. If terminating the request 1586 message body with a line-ending is desired, then the user agent MUST 1587 count the terminating CRLF octets as part of the message body length. 1589 In the interest of robustness, a server that is expecting to receive 1590 and parse a request-line SHOULD ignore at least one empty line (CRLF) 1591 received prior to the request-line. 1593 Although the line terminator for the start-line and header fields is 1594 the sequence CRLF, a recipient MAY recognize a single LF as a line 1595 terminator and ignore any preceding CR. 1597 Although the request-line and status-line grammar rules require that 1598 each of the component elements be separated by a single SP octet, 1599 recipients MAY instead parse on whitespace-delimited word boundaries 1600 and, aside from the CRLF terminator, treat any form of whitespace as 1601 the SP separator while ignoring preceding or trailing whitespace; 1602 such whitespace includes one or more of the following octets: SP, 1603 HTAB, VT (%x0B), FF (%x0C), or bare CR. However, lenient parsing can 1604 result in security vulnerabilities if there are multiple recipients 1605 of the message and each has its own unique interpretation of 1606 robustness (see Section 9.5). 1608 When a server listening only for HTTP request messages, or processing 1609 what appears from the start-line to be an HTTP request message, 1610 receives a sequence of octets that does not match the HTTP-message 1611 grammar aside from the robustness exceptions listed above, the server 1612 SHOULD respond with a 400 (Bad Request) response. 1614 4. Transfer Codings 1616 Transfer coding names are used to indicate an encoding transformation 1617 that has been, can be, or might need to be applied to a payload body 1618 in order to ensure "safe transport" through the network. This 1619 differs from a content coding in that the transfer coding is a 1620 property of the message rather than a property of the representation 1621 that is being transferred. 1623 transfer-coding = "chunked" ; Section 4.1 1624 / "compress" ; Section 4.2.1 1625 / "deflate" ; Section 4.2.2 1626 / "gzip" ; Section 4.2.3 1627 / transfer-extension 1628 transfer-extension = token *( OWS ";" OWS transfer-parameter ) 1630 Parameters are in the form of a name or name=value pair. 1632 transfer-parameter = token BWS "=" BWS ( token / quoted-string ) 1634 All transfer-coding names are case-insensitive and ought to be 1635 registered within the HTTP Transfer Coding registry, as defined in 1636 Section 8.4. They are used in the TE (Section 4.3) and Transfer- 1637 Encoding (Section 3.3.1) header fields. 1639 4.1. Chunked Transfer Coding 1641 The chunked transfer coding wraps the payload body in order to 1642 transfer it as a series of chunks, each with its own size indicator, 1643 followed by an OPTIONAL trailer containing header fields. Chunked 1644 enables content streams of unknown size to be transferred as a 1645 sequence of length-delimited buffers, which enables the sender to 1646 retain connection persistence and the recipient to know when it has 1647 received the entire message. 1649 chunked-body = *chunk 1650 last-chunk 1651 trailer-part 1652 CRLF 1654 chunk = chunk-size [ chunk-ext ] CRLF 1655 chunk-data CRLF 1656 chunk-size = 1*HEXDIG 1657 last-chunk = 1*("0") [ chunk-ext ] CRLF 1659 chunk-data = 1*OCTET ; a sequence of chunk-size octets 1661 The chunk-size field is a string of hex digits indicating the size of 1662 the chunk-data in octets. The chunked transfer coding is complete 1663 when a chunk with a chunk-size of zero is received, possibly followed 1664 by a trailer, and finally terminated by an empty line. 1666 A recipient MUST be able to parse and decode the chunked transfer 1667 coding. 1669 4.1.1. Chunk Extensions 1671 The chunked encoding allows each chunk to include zero or more chunk 1672 extensions, immediately following the chunk-size, for the sake of 1673 supplying per-chunk metadata (such as a signature or hash), mid- 1674 message control information, or randomization of message body size. 1676 chunk-ext = *( ";" chunk-ext-name [ "=" chunk-ext-val ] ) 1678 chunk-ext-name = token 1679 chunk-ext-val = token / quoted-string 1681 The chunked encoding is specific to each connection and is likely to 1682 be removed or recoded by each recipient (including intermediaries) 1683 before any higher-level application would have a chance to inspect 1684 the extensions. Hence, use of chunk extensions is generally limited 1685 to specialized HTTP services such as "long polling" (where client and 1686 server can have shared expectations regarding the use of chunk 1687 extensions) or for padding within an end-to-end secured connection. 1689 A recipient MUST ignore unrecognized chunk extensions. A server 1690 ought to limit the total length of chunk extensions received in a 1691 request to an amount reasonable for the services provided, in the 1692 same way that it applies length limitations and timeouts for other 1693 parts of a message, and generate an appropriate 4xx (Client Error) 1694 response if that amount is exceeded. 1696 4.1.2. Chunked Trailer Part 1698 A trailer allows the sender to include additional fields at the end 1699 of a chunked message in order to supply metadata that might be 1700 dynamically generated while the message body is sent, such as a 1701 message integrity check, digital signature, or post-processing 1702 status. The trailer fields are identical to header fields, except 1703 they are sent in a chunked trailer instead of the message's header 1704 section. 1706 trailer-part = *( header-field CRLF ) 1708 A sender MUST NOT generate a trailer that contains a field necessary 1709 for message framing (e.g., Transfer-Encoding and Content-Length), 1710 routing (e.g., Host), request modifiers (e.g., controls and 1711 conditionals in Section 5 of [Part2]), authentication (e.g., see 1712 [Part7] and [RFC6265]), response control data (e.g., see Section 7.1 1713 of [Part2]), or determining how to process the payload (e.g., 1714 Content-Encoding, Content-Type, Content-Range, and Trailer). 1716 When a chunked message containing a non-empty trailer is received, 1717 the recipient MAY process the fields (aside from those forbidden 1718 above) as if they were appended to the message's header section. A 1719 recipient MUST ignore (or consider as an error) any fields that are 1720 forbidden to be sent in a trailer, since processing them as if they 1721 were present in the header section might bypass external security 1722 filters. 1724 Unless the request includes a TE header field indicating "trailers" 1725 is acceptable, as described in Section 4.3, a server SHOULD NOT 1726 generate trailer fields that it believes are necessary for the user 1727 agent to receive. Without a TE containing "trailers", the server 1728 ought to assume that the trailer fields might be silently discarded 1729 along the path to the user agent. This requirement allows 1730 intermediaries to forward a de-chunked message to an HTTP/1.0 1731 recipient without buffering the entire response. 1733 4.1.3. Decoding Chunked 1735 A process for decoding the chunked transfer coding can be represented 1736 in pseudo-code as: 1738 length := 0 1739 read chunk-size, chunk-ext (if any), and CRLF 1740 while (chunk-size > 0) { 1741 read chunk-data and CRLF 1742 append chunk-data to decoded-body 1743 length := length + chunk-size 1744 read chunk-size, chunk-ext (if any), and CRLF 1745 } 1746 read trailer field 1747 while (trailer field is not empty) { 1748 if (trailer field is allowed to be sent in a trailer) { 1749 append trailer field to existing header fields 1750 } 1751 read trailer-field 1752 } 1753 Content-Length := length 1754 Remove "chunked" from Transfer-Encoding 1755 Remove Trailer from existing header fields 1757 4.2. Compression Codings 1759 The codings defined below can be used to compress the payload of a 1760 message. 1762 4.2.1. Compress Coding 1764 The "compress" coding is an adaptive Lempel-Ziv-Welch (LZW) coding 1765 [Welch] that is commonly produced by the UNIX file compression 1766 program "compress". A recipient SHOULD consider "x-compress" to be 1767 equivalent to "compress". 1769 4.2.2. Deflate Coding 1771 The "deflate" coding is a "zlib" data format [RFC1950] containing a 1772 "deflate" compressed data stream [RFC1951] that uses a combination of 1773 the Lempel-Ziv (LZ77) compression algorithm and Huffman coding. 1775 Note: Some non-conformant implementations send the "deflate" 1776 compressed data without the zlib wrapper. 1778 4.2.3. Gzip Coding 1780 The "gzip" coding is an LZ77 coding with a 32 bit CRC that is 1781 commonly produced by the gzip file compression program [RFC1952]. A 1782 recipient SHOULD consider "x-gzip" to be equivalent to "gzip". 1784 4.3. TE 1786 The "TE" header field in a request indicates what transfer codings, 1787 besides chunked, the client is willing to accept in response, and 1788 whether or not the client is willing to accept trailer fields in a 1789 chunked transfer coding. 1791 The TE field-value consists of a comma-separated list of transfer 1792 coding names, each allowing for optional parameters (as described in 1793 Section 4), and/or the keyword "trailers". A client MUST NOT send 1794 the chunked transfer coding name in TE; chunked is always acceptable 1795 for HTTP/1.1 recipients. 1797 TE = #t-codings 1798 t-codings = "trailers" / ( transfer-coding [ t-ranking ] ) 1799 t-ranking = OWS ";" OWS "q=" rank 1800 rank = ( "0" [ "." 0*3DIGIT ] ) 1801 / ( "1" [ "." 0*3("0") ] ) 1803 Three examples of TE use are below. 1805 TE: deflate 1806 TE: 1807 TE: trailers, deflate;q=0.5 1809 The presence of the keyword "trailers" indicates that the client is 1810 willing to accept trailer fields in a chunked transfer coding, as 1811 defined in Section 4.1.2, on behalf of itself and any downstream 1812 clients. For requests from an intermediary, this implies that 1813 either: (a) all downstream clients are willing to accept trailer 1814 fields in the forwarded response; or, (b) the intermediary will 1815 attempt to buffer the response on behalf of downstream recipients. 1816 Note that HTTP/1.1 does not define any means to limit the size of a 1817 chunked response such that an intermediary can be assured of 1818 buffering the entire response. 1820 When multiple transfer codings are acceptable, the client MAY rank 1821 the codings by preference using a case-insensitive "q" parameter 1822 (similar to the qvalues used in content negotiation fields, Section 1823 5.3.1 of [Part2]). The rank value is a real number in the range 0 1824 through 1, where 0.001 is the least preferred and 1 is the most 1825 preferred; a value of 0 means "not acceptable". 1827 If the TE field-value is empty or if no TE field is present, the only 1828 acceptable transfer coding is chunked. A message with no transfer 1829 coding is always acceptable. 1831 Since the TE header field only applies to the immediate connection, a 1832 sender of TE MUST also send a "TE" connection option within the 1833 Connection header field (Section 6.1) in order to prevent the TE 1834 field from being forwarded by intermediaries that do not support its 1835 semantics. 1837 4.4. Trailer 1839 When a message includes a message body encoded with the chunked 1840 transfer coding and the sender desires to send metadata in the form 1841 of trailer fields at the end of the message, the sender SHOULD 1842 generate a Trailer header field before the message body to indicate 1843 which fields will be present in the trailers. This allows the 1844 recipient to prepare for receipt of that metadata before it starts 1845 processing the body, which is useful if the message is being streamed 1846 and the recipient wishes to confirm an integrity check on the fly. 1848 Trailer = 1#field-name 1850 5. Message Routing 1852 HTTP request message routing is determined by each client based on 1853 the target resource, the client's proxy configuration, and 1854 establishment or reuse of an inbound connection. The corresponding 1855 response routing follows the same connection chain back to the 1856 client. 1858 5.1. Identifying a Target Resource 1860 HTTP is used in a wide variety of applications, ranging from general- 1861 purpose computers to home appliances. In some cases, communication 1862 options are hard-coded in a client's configuration. However, most 1863 HTTP clients rely on the same resource identification mechanism and 1864 configuration techniques as general-purpose Web browsers. 1866 HTTP communication is initiated by a user agent for some purpose. 1867 The purpose is a combination of request semantics, which are defined 1868 in [Part2], and a target resource upon which to apply those 1869 semantics. A URI reference (Section 2.7) is typically used as an 1870 identifier for the "target resource", which a user agent would 1871 resolve to its absolute form in order to obtain the "target URI". 1872 The target URI excludes the reference's fragment component, if any, 1873 since fragment identifiers are reserved for client-side processing 1874 ([RFC3986], Section 3.5). 1876 5.2. Connecting Inbound 1878 Once the target URI is determined, a client needs to decide whether a 1879 network request is necessary to accomplish the desired semantics and, 1880 if so, where that request is to be directed. 1882 If the client has a cache [Part6] and the request can be satisfied by 1883 it, then the request is usually directed there first. 1885 If the request is not satisfied by a cache, then a typical client 1886 will check its configuration to determine whether a proxy is to be 1887 used to satisfy the request. Proxy configuration is implementation- 1888 dependent, but is often based on URI prefix matching, selective 1889 authority matching, or both, and the proxy itself is usually 1890 identified by an "http" or "https" URI. If a proxy is applicable, 1891 the client connects inbound by establishing (or reusing) a connection 1892 to that proxy. 1894 If no proxy is applicable, a typical client will invoke a handler 1895 routine, usually specific to the target URI's scheme, to connect 1896 directly to an authority for the target resource. How that is 1897 accomplished is dependent on the target URI scheme and defined by its 1898 associated specification, similar to how this specification defines 1899 origin server access for resolution of the "http" (Section 2.7.1) and 1900 "https" (Section 2.7.2) schemes. 1902 HTTP requirements regarding connection management are defined in 1903 Section 6. 1905 5.3. Request Target 1907 Once an inbound connection is obtained, the client sends an HTTP 1908 request message (Section 3) with a request-target derived from the 1909 target URI. There are four distinct formats for the request-target, 1910 depending on both the method being requested and whether the request 1911 is to a proxy. 1913 request-target = origin-form 1914 / absolute-form 1915 / authority-form 1916 / asterisk-form 1918 5.3.1. origin-form 1920 The most common form of request-target is the origin-form. 1922 origin-form = absolute-path [ "?" query ] 1924 When making a request directly to an origin server, other than a 1925 CONNECT or server-wide OPTIONS request (as detailed below), a client 1926 MUST send only the absolute path and query components of the target 1927 URI as the request-target. If the target URI's path component is 1928 empty, the client MUST send "/" as the path within the origin-form of 1929 request-target. A Host header field is also sent, as defined in 1930 Section 5.4. 1932 For example, a client wishing to retrieve a representation of the 1933 resource identified as 1935 http://www.example.org/where?q=now 1937 directly from the origin server would open (or reuse) a TCP 1938 connection to port 80 of the host "www.example.org" and send the 1939 lines: 1941 GET /where?q=now HTTP/1.1 1942 Host: www.example.org 1944 followed by the remainder of the request message. 1946 5.3.2. absolute-form 1948 When making a request to a proxy, other than a CONNECT or server-wide 1949 OPTIONS request (as detailed below), a client MUST send the target 1950 URI in absolute-form as the request-target. 1952 absolute-form = absolute-URI 1954 The proxy is requested to either service that request from a valid 1955 cache, if possible, or make the same request on the client's behalf 1956 to either the next inbound proxy server or directly to the origin 1957 server indicated by the request-target. Requirements on such 1958 "forwarding" of messages are defined in Section 5.7. 1960 An example absolute-form of request-line would be: 1962 GET http://www.example.org/pub/WWW/TheProject.html HTTP/1.1 1964 To allow for transition to the absolute-form for all requests in some 1965 future version of HTTP, a server MUST accept the absolute-form in 1966 requests, even though HTTP/1.1 clients will only send them in 1967 requests to proxies. 1969 5.3.3. authority-form 1971 The authority-form of request-target is only used for CONNECT 1972 requests (Section 4.3.6 of [Part2]). 1974 authority-form = authority 1976 When making a CONNECT request to establish a tunnel through one or 1977 more proxies, a client MUST send only the target URI's authority 1978 component (excluding any userinfo and its "@" delimiter) as the 1979 request-target. For example, 1981 CONNECT www.example.com:80 HTTP/1.1 1983 5.3.4. asterisk-form 1985 The asterisk-form of request-target is only used for a server-wide 1986 OPTIONS request (Section 4.3.7 of [Part2]). 1988 asterisk-form = "*" 1990 When a client wishes to request OPTIONS for the server as a whole, as 1991 opposed to a specific named resource of that server, the client MUST 1992 send only "*" (%x2A) as the request-target. For example, 1993 OPTIONS * HTTP/1.1 1995 If a proxy receives an OPTIONS request with an absolute-form of 1996 request-target in which the URI has an empty path and no query 1997 component, then the last proxy on the request chain MUST send a 1998 request-target of "*" when it forwards the request to the indicated 1999 origin server. 2001 For example, the request 2003 OPTIONS http://www.example.org:8001 HTTP/1.1 2005 would be forwarded by the final proxy as 2007 OPTIONS * HTTP/1.1 2008 Host: www.example.org:8001 2010 after connecting to port 8001 of host "www.example.org". 2012 5.4. Host 2014 The "Host" header field in a request provides the host and port 2015 information from the target URI, enabling the origin server to 2016 distinguish among resources while servicing requests for multiple 2017 host names on a single IP address. 2019 Host = uri-host [ ":" port ] ; Section 2.7.1 2021 A client MUST send a Host header field in all HTTP/1.1 request 2022 messages. If the target URI includes an authority component, then a 2023 client MUST send a field-value for Host that is identical to that 2024 authority component, excluding any userinfo subcomponent and its "@" 2025 delimiter (Section 2.7.1). If the authority component is missing or 2026 undefined for the target URI, then a client MUST send a Host header 2027 field with an empty field-value. 2029 Since the Host field-value is critical information for handling a 2030 request, a user agent SHOULD generate Host as the first header field 2031 following the request-line. 2033 For example, a GET request to the origin server for 2034 would begin with: 2036 GET /pub/WWW/ HTTP/1.1 2037 Host: www.example.org 2039 A client MUST send a Host header field in an HTTP/1.1 request even if 2040 the request-target is in the absolute-form, since this allows the 2041 Host information to be forwarded through ancient HTTP/1.0 proxies 2042 that might not have implemented Host. 2044 When a proxy receives a request with an absolute-form of request- 2045 target, the proxy MUST ignore the received Host header field (if any) 2046 and instead replace it with the host information of the request- 2047 target. A proxy that forwards such a request MUST generate a new 2048 Host field-value based on the received request-target rather than 2049 forward the received Host field-value. 2051 Since the Host header field acts as an application-level routing 2052 mechanism, it is a frequent target for malware seeking to poison a 2053 shared cache or redirect a request to an unintended server. An 2054 interception proxy is particularly vulnerable if it relies on the 2055 Host field-value for redirecting requests to internal servers, or for 2056 use as a cache key in a shared cache, without first verifying that 2057 the intercepted connection is targeting a valid IP address for that 2058 host. 2060 A server MUST respond with a 400 (Bad Request) status code to any 2061 HTTP/1.1 request message that lacks a Host header field and to any 2062 request message that contains more than one Host header field or a 2063 Host header field with an invalid field-value. 2065 5.5. Effective Request URI 2067 Since the request-target often contains only part of the user agent's 2068 target URI, a server reconstructs the intended target as an 2069 "effective request URI" to properly service the request. This 2070 reconstruction involves both the server's local configuration and 2071 information communicated in the request-target, Host header field, 2072 and connection context. 2074 For a user agent, the effective request URI is the target URI. 2076 If the request-target is in absolute-form, the effective request URI 2077 is the same as the request-target. Otherwise, the effective request 2078 URI is constructed as follows: 2080 If the server's configuration (or outbound gateway) provides a 2081 fixed URI scheme, that scheme is used for the effective request 2082 URI. Otherwise, if the request is received over a TLS-secured TCP 2083 connection, the effective request URI's scheme is "https"; if not, 2084 the scheme is "http". 2086 If the server's configuration (or outbound gateway) provides a 2087 fixed URI authority component, that authority is used for the 2088 effective request URI. If not, then if the request-target is in 2089 authority-form, the effective request URI's authority component is 2090 the same as the request-target. If not, then if a Host header 2091 field is supplied with a non-empty field-value, the authority 2092 component is the same as the Host field-value. Otherwise, the 2093 authority component is assigned the default name configured for 2094 the server and, if the connection's incoming TCP port number 2095 differs from the default port for the effective request URI's 2096 scheme, then a colon (":") and the incoming port number (in 2097 decimal form) are appended to the authority component. 2099 If the request-target is in authority-form or asterisk-form, the 2100 effective request URI's combined path and query component is 2101 empty. Otherwise, the combined path and query component is the 2102 same as the request-target. 2104 The components of the effective request URI, once determined as 2105 above, can be combined into absolute-URI form by concatenating the 2106 scheme, "://", authority, and combined path and query component. 2108 Example 1: the following message received over an insecure TCP 2109 connection 2111 GET /pub/WWW/TheProject.html HTTP/1.1 2112 Host: www.example.org:8080 2114 has an effective request URI of 2116 http://www.example.org:8080/pub/WWW/TheProject.html 2118 Example 2: the following message received over a TLS-secured TCP 2119 connection 2121 OPTIONS * HTTP/1.1 2122 Host: www.example.org 2124 has an effective request URI of 2126 https://www.example.org 2128 Recipients of an HTTP/1.0 request that lacks a Host header field 2129 might need to use heuristics (e.g., examination of the URI path for 2130 something unique to a particular host) in order to guess the 2131 effective request URI's authority component. 2133 Once the effective request URI has been constructed, an origin server 2134 needs to decide whether or not to provide service for that URI via 2135 the connection in which the request was received. For example, the 2136 request might have been misdirected, deliberately or accidentally, 2137 such that the information within a received request-target or Host 2138 header field differs from the host or port upon which the connection 2139 has been made. If the connection is from a trusted gateway, that 2140 inconsistency might be expected; otherwise, it might indicate an 2141 attempt to bypass security filters, trick the server into delivering 2142 non-public content, or poison a cache. See Section 9 for security 2143 considerations regarding message routing. 2145 5.6. Associating a Response to a Request 2147 HTTP does not include a request identifier for associating a given 2148 request message with its corresponding one or more response messages. 2149 Hence, it relies on the order of response arrival to correspond 2150 exactly to the order in which requests are made on the same 2151 connection. More than one response message per request only occurs 2152 when one or more informational responses (1xx, see Section 6.2 of 2153 [Part2]) precede a final response to the same request. 2155 A client that has more than one outstanding request on a connection 2156 MUST maintain a list of outstanding requests in the order sent and 2157 MUST associate each received response message on that connection to 2158 the highest ordered request that has not yet received a final (non- 2159 1xx) response. 2161 5.7. Message Forwarding 2163 As described in Section 2.3, intermediaries can serve a variety of 2164 roles in the processing of HTTP requests and responses. Some 2165 intermediaries are used to improve performance or availability. 2166 Others are used for access control or to filter content. Since an 2167 HTTP stream has characteristics similar to a pipe-and-filter 2168 architecture, there are no inherent limits to the extent an 2169 intermediary can enhance (or interfere) with either direction of the 2170 stream. 2172 An intermediary not acting as a tunnel MUST implement the Connection 2173 header field, as specified in Section 6.1, and exclude fields from 2174 being forwarded that are only intended for the incoming connection. 2176 An intermediary MUST NOT forward a message to itself unless it is 2177 protected from an infinite request loop. In general, an intermediary 2178 ought to recognize its own server names, including any aliases, local 2179 variations, or literal IP addresses, and respond to such requests 2180 directly. 2182 5.7.1. Via 2184 The "Via" header field indicates the presence of intermediate 2185 protocols and recipients between the user agent and the server (on 2186 requests) or between the origin server and the client (on responses), 2187 similar to the "Received" header field in email (Section 3.6.7 of 2188 [RFC5322]). Via can be used for tracking message forwards, avoiding 2189 request loops, and identifying the protocol capabilities of senders 2190 along the request/response chain. 2192 Via = 1#( received-protocol RWS received-by [ RWS comment ] ) 2194 received-protocol = [ protocol-name "/" ] protocol-version 2195 ; see Section 6.7 2196 received-by = ( uri-host [ ":" port ] ) / pseudonym 2197 pseudonym = token 2199 Multiple Via field values represent each proxy or gateway that has 2200 forwarded the message. Each intermediary appends its own information 2201 about how the message was received, such that the end result is 2202 ordered according to the sequence of forwarding recipients. 2204 A proxy MUST send an appropriate Via header field, as described 2205 below, in each message that it forwards. An HTTP-to-HTTP gateway 2206 MUST send an appropriate Via header field in each inbound request 2207 message and MAY send a Via header field in forwarded response 2208 messages. 2210 For each intermediary, the received-protocol indicates the protocol 2211 and protocol version used by the upstream sender of the message. 2212 Hence, the Via field value records the advertised protocol 2213 capabilities of the request/response chain such that they remain 2214 visible to downstream recipients; this can be useful for determining 2215 what backwards-incompatible features might be safe to use in 2216 response, or within a later request, as described in Section 2.6. 2217 For brevity, the protocol-name is omitted when the received protocol 2218 is HTTP. 2220 The received-by portion of the field value is normally the host and 2221 optional port number of a recipient server or client that 2222 subsequently forwarded the message. However, if the real host is 2223 considered to be sensitive information, a sender MAY replace it with 2224 a pseudonym. If a port is not provided, a recipient MAY interpret 2225 that as meaning it was received on the default TCP port, if any, for 2226 the received-protocol. 2228 A sender MAY generate comments in the Via header field to identify 2229 the software of each recipient, analogous to the User-Agent and 2230 Server header fields. However, all comments in the Via field are 2231 optional and a recipient MAY remove them prior to forwarding the 2232 message. 2234 For example, a request message could be sent from an HTTP/1.0 user 2235 agent to an internal proxy code-named "fred", which uses HTTP/1.1 to 2236 forward the request to a public proxy at p.example.net, which 2237 completes the request by forwarding it to the origin server at 2238 www.example.com. The request received by www.example.com would then 2239 have the following Via header field: 2241 Via: 1.0 fred, 1.1 p.example.net 2243 An intermediary used as a portal through a network firewall SHOULD 2244 NOT forward the names and ports of hosts within the firewall region 2245 unless it is explicitly enabled to do so. If not enabled, such an 2246 intermediary SHOULD replace each received-by host of any host behind 2247 the firewall by an appropriate pseudonym for that host. 2249 An intermediary MAY combine an ordered subsequence of Via header 2250 field entries into a single such entry if the entries have identical 2251 received-protocol values. For example, 2253 Via: 1.0 ricky, 1.1 ethel, 1.1 fred, 1.0 lucy 2255 could be collapsed to 2257 Via: 1.0 ricky, 1.1 mertz, 1.0 lucy 2259 A sender SHOULD NOT combine multiple entries unless they are all 2260 under the same organizational control and the hosts have already been 2261 replaced by pseudonyms. A sender MUST NOT combine entries that have 2262 different received-protocol values. 2264 5.7.2. Transformations 2266 Some intermediaries include features for transforming messages and 2267 their payloads. A proxy might, for example, convert between image 2268 formats in order to save cache space or to reduce the amount of 2269 traffic on a slow link. However, operational problems might occur 2270 when these transformations are applied to payloads intended for 2271 critical applications, such as medical imaging or scientific data 2272 analysis, particularly when integrity checks or digital signatures 2273 are used to ensure that the payload received is identical to the 2274 original. 2276 An HTTP-to-HTTP proxy is called a "transforming proxy" if it is 2277 designed or configured to modify messages in a semantically 2278 meaningful way (i.e., modifications, beyond those required by normal 2279 HTTP processing, that change the message in a way that would be 2280 significant to the original sender or potentially significant to 2281 downstream recipients). For example, a transforming proxy might be 2282 acting as a shared annotation server (modifying responses to include 2283 references to a local annotation database), a malware filter, a 2284 format transcoder, or a privacy filter. Such transformations are 2285 presumed to be desired by whichever client (or client organization) 2286 selected the proxy. 2288 If a proxy receives a request-target with a host name that is not a 2289 fully qualified domain name, it MAY add its own domain to the host 2290 name it received when forwarding the request. A proxy MUST NOT 2291 change the host name if the request-target contains a fully qualified 2292 domain name. 2294 A proxy MUST NOT modify the "absolute-path" and "query" parts of the 2295 received request-target when forwarding it to the next inbound 2296 server, except as noted above to replace an empty path with "/" or 2297 "*". 2299 A proxy MAY modify the message body through application or removal of 2300 a transfer coding (Section 4). 2302 A proxy MUST NOT transform the payload (Section 3.3 of [Part2]) of a 2303 message that contains a no-transform cache-control directive (Section 2304 5.2 of [Part6]). 2306 A proxy MAY transform the payload of a message that does not contain 2307 a no-transform cache-control directive. A proxy that transforms a 2308 payload MUST add a Warning header field with the warn-code of 214 2309 ("Transformation Applied") if one is not already in the message (see 2310 Section 5.5 of [Part6]). A proxy that transforms the payload of a 2311 200 (OK) response can further inform downstream recipients that a 2312 transformation has been applied by changing the response status code 2313 to 203 (Non-Authoritative Information) (Section 6.3.4 of [Part2]). 2315 A proxy SHOULD NOT modify header fields that provide information 2316 about the end points of the communication chain, the resource state, 2317 or the selected representation (other than the payload) unless the 2318 field's definition specifically allows such modification or the 2319 modification is deemed necessary for privacy or security. 2321 6. Connection Management 2323 HTTP messaging is independent of the underlying transport or session- 2324 layer connection protocol(s). HTTP only presumes a reliable 2325 transport with in-order delivery of requests and the corresponding 2326 in-order delivery of responses. The mapping of HTTP request and 2327 response structures onto the data units of an underlying transport 2328 protocol is outside the scope of this specification. 2330 As described in Section 5.2, the specific connection protocols to be 2331 used for an HTTP interaction are determined by client configuration 2332 and the target URI. For example, the "http" URI scheme 2333 (Section 2.7.1) indicates a default connection of TCP over IP, with a 2334 default TCP port of 80, but the client might be configured to use a 2335 proxy via some other connection, port, or protocol. 2337 HTTP implementations are expected to engage in connection management, 2338 which includes maintaining the state of current connections, 2339 establishing a new connection or reusing an existing connection, 2340 processing messages received on a connection, detecting connection 2341 failures, and closing each connection. Most clients maintain 2342 multiple connections in parallel, including more than one connection 2343 per server endpoint. Most servers are designed to maintain thousands 2344 of concurrent connections, while controlling request queues to enable 2345 fair use and detect denial of service attacks. 2347 6.1. Connection 2349 The "Connection" header field allows the sender to indicate desired 2350 control options for the current connection. In order to avoid 2351 confusing downstream recipients, a proxy or gateway MUST remove or 2352 replace any received connection options before forwarding the 2353 message. 2355 When a header field aside from Connection is used to supply control 2356 information for or about the current connection, the sender MUST list 2357 the corresponding field-name within the "Connection" header field. A 2358 proxy or gateway MUST parse a received Connection header field before 2359 a message is forwarded and, for each connection-option in this field, 2360 remove any header field(s) from the message with the same name as the 2361 connection-option, and then remove the Connection header field itself 2362 (or replace it with the intermediary's own connection options for the 2363 forwarded message). 2365 Hence, the Connection header field provides a declarative way of 2366 distinguishing header fields that are only intended for the immediate 2367 recipient ("hop-by-hop") from those fields that are intended for all 2368 recipients on the chain ("end-to-end"), enabling the message to be 2369 self-descriptive and allowing future connection-specific extensions 2370 to be deployed without fear that they will be blindly forwarded by 2371 older intermediaries. 2373 The Connection header field's value has the following grammar: 2375 Connection = 1#connection-option 2376 connection-option = token 2378 Connection options are case-insensitive. 2380 A sender MUST NOT send a connection option corresponding to a header 2381 field that is intended for all recipients of the payload. For 2382 example, Cache-Control is never appropriate as a connection option 2383 (Section 5.2 of [Part6]). 2385 The connection options do not always correspond to a header field 2386 present in the message, since a connection-specific header field 2387 might not be needed if there are no parameters associated with a 2388 connection option. In contrast, a connection-specific header field 2389 that is received without a corresponding connection option usually 2390 indicates that the field has been improperly forwarded by an 2391 intermediary and ought to be ignored by the recipient. 2393 When defining new connection options, specification authors ought to 2394 survey existing header field names and ensure that the new connection 2395 option does not share the same name as an already deployed header 2396 field. Defining a new connection option essentially reserves that 2397 potential field-name for carrying additional information related to 2398 the connection option, since it would be unwise for senders to use 2399 that field-name for anything else. 2401 The "close" connection option is defined for a sender to signal that 2402 this connection will be closed after completion of the response. For 2403 example, 2405 Connection: close 2407 in either the request or the response header fields indicates that 2408 the sender is going to close the connection after the current 2409 request/response is complete (Section 6.6). 2411 A client that does not support persistent connections MUST send the 2412 "close" connection option in every request message. 2414 A server that does not support persistent connections MUST send the 2415 "close" connection option in every response message that does not 2416 have a 1xx (Informational) status code. 2418 6.2. Establishment 2420 It is beyond the scope of this specification to describe how 2421 connections are established via various transport or session-layer 2422 protocols. Each connection applies to only one transport link. 2424 6.3. Persistence 2426 HTTP/1.1 defaults to the use of "persistent connections", allowing 2427 multiple requests and responses to be carried over a single 2428 connection. The "close" connection-option is used to signal that a 2429 connection will not persist after the current request/response. HTTP 2430 implementations SHOULD support persistent connections. 2432 A recipient determines whether a connection is persistent or not 2433 based on the most recently received message's protocol version and 2434 Connection header field (if any): 2436 o If the close connection option is present, the connection will not 2437 persist after the current response; else, 2439 o If the received protocol is HTTP/1.1 (or later), the connection 2440 will persist after the current response; else, 2442 o If the received protocol is HTTP/1.0, the "keep-alive" connection 2443 option is present, the recipient is not a proxy, and the recipient 2444 wishes to honor the HTTP/1.0 "keep-alive" mechanism, the 2445 connection will persist after the current response; otherwise, 2447 o The connection will close after the current response. 2449 A client MAY send additional requests on a persistent connection 2450 until it sends or receives a close connection option or receives an 2451 HTTP/1.0 response without a "keep-alive" connection option. 2453 In order to remain persistent, all messages on a connection need to 2454 have a self-defined message length (i.e., one not defined by closure 2455 of the connection), as described in Section 3.3. A server MUST read 2456 the entire request message body or close the connection after sending 2457 its response, since otherwise the remaining data on a persistent 2458 connection would be misinterpreted as the next request. Likewise, a 2459 client MUST read the entire response message body if it intends to 2460 reuse the same connection for a subsequent request. 2462 A proxy server MUST NOT maintain a persistent connection with an 2463 HTTP/1.0 client (see Section 19.7.1 of [RFC2068] for information and 2464 discussion of the problems with the Keep-Alive header field 2465 implemented by many HTTP/1.0 clients). 2467 See Appendix A.1.2 for more information on backward compatibility 2468 with HTTP/1.0 clients. 2470 6.3.1. Retrying Requests 2472 Connections can be closed at any time, with or without intention. 2473 Implementations ought to anticipate the need to recover from 2474 asynchronous close events. 2476 When an inbound connection is closed prematurely, a client MAY open a 2477 new connection and automatically retransmit an aborted sequence of 2478 requests if all of those requests have idempotent methods (Section 2479 4.2.2 of [Part2]). A proxy MUST NOT automatically retry non- 2480 idempotent requests. 2482 A user agent MUST NOT automatically retry a request with a non- 2483 idempotent method unless it has some means to know that the request 2484 semantics are actually idempotent, regardless of the method, or some 2485 means to detect that the original request was never applied. For 2486 example, a user agent that knows (through design or configuration) 2487 that a POST request to a given resource is safe can repeat that 2488 request automatically. Likewise, a user agent designed specifically 2489 to operate on a version control repository might be able to recover 2490 from partial failure conditions by checking the target resource 2491 revision(s) after a failed connection, reverting or fixing any 2492 changes that were partially applied, and then automatically retrying 2493 the requests that failed. 2495 A client SHOULD NOT automatically retry a failed automatic retry. 2497 6.3.2. Pipelining 2499 A client that supports persistent connections MAY "pipeline" its 2500 requests (i.e., send multiple requests without waiting for each 2501 response). A server MAY process a sequence of pipelined requests in 2502 parallel if they all have safe methods (Section 4.2.1 of [Part2]), 2503 but MUST send the corresponding responses in the same order that the 2504 requests were received. 2506 A client that pipelines requests SHOULD retry unanswered requests if 2507 the connection closes before it receives all of the corresponding 2508 responses. When retrying pipelined requests after a failed 2509 connection (a connection not explicitly closed by the server in its 2510 last complete response), a client MUST NOT pipeline immediately after 2511 connection establishment, since the first remaining request in the 2512 prior pipeline might have caused an error response that can be lost 2513 again if multiple requests are sent on a prematurely closed 2514 connection (see the TCP reset problem described in Section 6.6). 2516 Idempotent methods (Section 4.2.2 of [Part2]) are significant to 2517 pipelining because they can be automatically retried after a 2518 connection failure. A user agent SHOULD NOT pipeline requests after 2519 a non-idempotent method, until the final response status code for 2520 that method has been received, unless the user agent has a means to 2521 detect and recover from partial failure conditions involving the 2522 pipelined sequence. 2524 An intermediary that receives pipelined requests MAY pipeline those 2525 requests when forwarding them inbound, since it can rely on the 2526 outbound user agent(s) to determine what requests can be safely 2527 pipelined. If the inbound connection fails before receiving a 2528 response, the pipelining intermediary MAY attempt to retry a sequence 2529 of requests that have yet to receive a response if the requests all 2530 have idempotent methods; otherwise, the pipelining intermediary 2531 SHOULD forward any received responses and then close the 2532 corresponding outbound connection(s) so that the outbound user 2533 agent(s) can recover accordingly. 2535 6.4. Concurrency 2537 A client ought to limit the number of simultaneous open connections 2538 that it maintains to a given server. 2540 Previous revisions of HTTP gave a specific number of connections as a 2541 ceiling, but this was found to be impractical for many applications. 2542 As a result, this specification does not mandate a particular maximum 2543 number of connections, but instead encourages clients to be 2544 conservative when opening multiple connections. 2546 Multiple connections are typically used to avoid the "head-of-line 2547 blocking" problem, wherein a request that takes significant server- 2548 side processing and/or has a large payload blocks subsequent requests 2549 on the same connection. However, each connection consumes server 2550 resources. Furthermore, using multiple connections can cause 2551 undesirable side effects in congested networks. 2553 Note that a server might reject traffic that it deems abusive or 2554 characteristic of a denial of service attack, such as an excessive 2555 number of open connections from a single client. 2557 6.5. Failures and Time-outs 2559 Servers will usually have some time-out value beyond which they will 2560 no longer maintain an inactive connection. Proxy servers might make 2561 this a higher value since it is likely that the client will be making 2562 more connections through the same proxy server. The use of 2563 persistent connections places no requirements on the length (or 2564 existence) of this time-out for either the client or the server. 2566 A client or server that wishes to time-out SHOULD issue a graceful 2567 close on the connection. Implementations SHOULD constantly monitor 2568 open connections for a received closure signal and respond to it as 2569 appropriate, since prompt closure of both sides of a connection 2570 enables allocated system resources to be reclaimed. 2572 A client, server, or proxy MAY close the transport connection at any 2573 time. For example, a client might have started to send a new request 2574 at the same time that the server has decided to close the "idle" 2575 connection. From the server's point of view, the connection is being 2576 closed while it was idle, but from the client's point of view, a 2577 request is in progress. 2579 A server SHOULD sustain persistent connections, when possible, and 2580 allow the underlying transport's flow control mechanisms to resolve 2581 temporary overloads, rather than terminate connections with the 2582 expectation that clients will retry. The latter technique can 2583 exacerbate network congestion. 2585 A client sending a message body SHOULD monitor the network connection 2586 for an error response while it is transmitting the request. If the 2587 client sees a response that indicates the server does not wish to 2588 receive the message body and is closing the connection, the client 2589 SHOULD immediately cease transmitting the body and close its side of 2590 the connection. 2592 6.6. Tear-down 2594 The Connection header field (Section 6.1) provides a "close" 2595 connection option that a sender SHOULD send when it wishes to close 2596 the connection after the current request/response pair. 2598 A client that sends a close connection option MUST NOT send further 2599 requests on that connection (after the one containing close) and MUST 2600 close the connection after reading the final response message 2601 corresponding to this request. 2603 A server that receives a close connection option MUST initiate a 2604 close of the connection (see below) after it sends the final response 2605 to the request that contained close. The server SHOULD send a close 2606 connection option in its final response on that connection. The 2607 server MUST NOT process any further requests received on that 2608 connection. 2610 A server that sends a close connection option MUST initiate a close 2611 of the connection (see below) after it sends the response containing 2612 close. The server MUST NOT process any further requests received on 2613 that connection. 2615 A client that receives a close connection option MUST cease sending 2616 requests on that connection and close the connection after reading 2617 the response message containing the close; if additional pipelined 2618 requests had been sent on the connection, the client SHOULD NOT 2619 assume that they will be processed by the server. 2621 If a server performs an immediate close of a TCP connection, there is 2622 a significant risk that the client will not be able to read the last 2623 HTTP response. If the server receives additional data from the 2624 client on a fully-closed connection, such as another request that was 2625 sent by the client before receiving the server's response, the 2626 server's TCP stack will send a reset packet to the client; 2627 unfortunately, the reset packet might erase the client's 2628 unacknowledged input buffers before they can be read and interpreted 2629 by the client's HTTP parser. 2631 To avoid the TCP reset problem, servers typically close a connection 2632 in stages. First, the server performs a half-close by closing only 2633 the write side of the read/write connection. The server then 2634 continues to read from the connection until it receives a 2635 corresponding close by the client, or until the server is reasonably 2636 certain that its own TCP stack has received the client's 2637 acknowledgement of the packet(s) containing the server's last 2638 response. Finally, the server fully closes the connection. 2640 It is unknown whether the reset problem is exclusive to TCP or might 2641 also be found in other transport connection protocols. 2643 6.7. Upgrade 2645 The "Upgrade" header field is intended to provide a simple mechanism 2646 for transitioning from HTTP/1.1 to some other protocol on the same 2647 connection. A client MAY send a list of protocols in the Upgrade 2648 header field of a request to invite the server to switch to one or 2649 more of those protocols, in order of descending preference, before 2650 sending the final response. A server MAY ignore a received Upgrade 2651 header field if it wishes to continue using the current protocol on 2652 that connection. Upgrade cannot be used to insist on a protocol 2653 change. 2655 Upgrade = 1#protocol 2657 protocol = protocol-name ["/" protocol-version] 2658 protocol-name = token 2659 protocol-version = token 2661 A server that sends a 101 (Switching Protocols) response MUST send an 2662 Upgrade header field to indicate the new protocol(s) to which the 2663 connection is being switched; if multiple protocol layers are being 2664 switched, the sender MUST list the protocols in layer-ascending 2665 order. A server MUST NOT switch to a protocol that was not indicated 2666 by the client in the corresponding request's Upgrade header field. A 2667 server MAY choose to ignore the order of preference indicated by the 2668 client and select the new protocol(s) based on other factors, such as 2669 the nature of the request or the current load on the server. 2671 A server that sends a 426 (Upgrade Required) response MUST send an 2672 Upgrade header field to indicate the acceptable protocols, in order 2673 of descending preference. 2675 A server MAY send an Upgrade header field in any other response to 2676 advertise that it implements support for upgrading to the listed 2677 protocols, in order of descending preference, when appropriate for a 2678 future request. 2680 The following is a hypothetical example sent by a client: 2682 GET /hello.txt HTTP/1.1 2683 Host: www.example.com 2684 Connection: upgrade 2685 Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11 2687 The capabilities and nature of the application-level communication 2688 after the protocol change is entirely dependent upon the new 2689 protocol(s) chosen. However, immediately after sending the 101 2690 response, the server is expected to continue responding to the 2691 original request as if it had received its equivalent within the new 2692 protocol (i.e., the server still has an outstanding request to 2693 satisfy after the protocol has been changed, and is expected to do so 2694 without requiring the request to be repeated). 2696 For example, if the Upgrade header field is received in a GET request 2697 and the server decides to switch protocols, it first responds with a 2698 101 (Switching Protocols) message in HTTP/1.1 and then immediately 2699 follows that with the new protocol's equivalent of a response to a 2700 GET on the target resource. This allows a connection to be upgraded 2701 to protocols with the same semantics as HTTP without the latency cost 2702 of an additional round-trip. A server MUST NOT switch protocols 2703 unless the received message semantics can be honored by the new 2704 protocol; an OPTIONS request can be honored by any protocol. 2706 The following is an example response to the above hypothetical 2707 request: 2709 HTTP/1.1 101 Switching Protocols 2710 Connection: upgrade 2711 Upgrade: HTTP/2.0 2713 [... data stream switches to HTTP/2.0 with an appropriate response 2714 (as defined by new protocol) to the "GET /hello.txt" request ...] 2716 When Upgrade is sent, the sender MUST also send a Connection header 2717 field (Section 6.1) that contains an "upgrade" connection option, in 2718 order to prevent Upgrade from being accidentally forwarded by 2719 intermediaries that might not implement the listed protocols. A 2720 server MUST ignore an Upgrade header field that is received in an 2721 HTTP/1.0 request. 2723 A client cannot begin using an upgraded protocol on the connection 2724 until it has completely sent the request message (i.e., the client 2725 can't change the protocol it is sending in the middle of a message). 2726 If a server receives both Upgrade and an Expect header field with the 2727 "100-continue" expectation (Section 5.1.1 of [Part2]), the server 2728 MUST send a 100 (Continue) response before sending a 101 (Switching 2729 Protocols) response. 2731 The Upgrade header field only applies to switching protocols on top 2732 of the existing connection; it cannot be used to switch the 2733 underlying connection (transport) protocol, nor to switch the 2734 existing communication to a different connection. For those 2735 purposes, it is more appropriate to use a 3xx (Redirection) response 2736 (Section 6.4 of [Part2]). 2738 This specification only defines the protocol name "HTTP" for use by 2739 the family of Hypertext Transfer Protocols, as defined by the HTTP 2740 version rules of Section 2.6 and future updates to this 2741 specification. Additional tokens ought to be registered with IANA 2742 using the registration procedure defined in Section 8.6. 2744 7. ABNF list extension: #rule 2746 A #rule extension to the ABNF rules of [RFC5234] is used to improve 2747 readability in the definitions of some header field values. 2749 A construct "#" is defined, similar to "*", for defining comma- 2750 delimited lists of elements. The full form is "#element" 2751 indicating at least and at most elements, each separated by a 2752 single comma (",") and optional whitespace (OWS). 2754 In any production that uses the list construct, a sender MUST NOT 2755 generate empty list elements. In other words, a sender MUST generate 2756 lists that satisfy the following syntax: 2758 1#element => element *( OWS "," OWS element ) 2760 and: 2762 #element => [ 1#element ] 2764 and for n >= 1 and m > 1: 2766 #element => element *( OWS "," OWS element ) 2768 For compatibility with legacy list rules, a recipient MUST parse and 2769 ignore a reasonable number of empty list elements: enough to handle 2770 common mistakes by senders that merge values, but not so much that 2771 they could be used as a denial of service mechanism. In other words, 2772 a recipient MUST accept lists that satisfy the following syntax: 2774 #element => [ ( "," / element ) *( OWS "," [ OWS element ] ) ] 2776 1#element => *( "," OWS ) element *( OWS "," [ OWS element ] ) 2778 Empty elements do not contribute to the count of elements present. 2779 For example, given these ABNF productions: 2781 example-list = 1#example-list-elmt 2782 example-list-elmt = token ; see Section 3.2.6 2784 Then the following are valid values for example-list (not including 2785 the double quotes, which are present for delimitation only): 2787 "foo,bar" 2788 "foo ,bar," 2789 "foo , ,bar,charlie " 2791 In contrast, the following values would be invalid, since at least 2792 one non-empty element is required by the example-list production: 2794 "" 2795 "," 2796 ", ," 2798 Appendix B shows the collected ABNF for recipients after the list 2799 constructs have been expanded. 2801 8. IANA Considerations 2803 8.1. Header Field Registration 2805 HTTP header fields are registered within the Message Header Field 2806 Registry maintained at 2807 . 2809 This document defines the following HTTP header fields, so their 2810 associated registry entries shall be updated according to the 2811 permanent registrations below (see [BCP90]): 2813 +-------------------+----------+----------+---------------+ 2814 | Header Field Name | Protocol | Status | Reference | 2815 +-------------------+----------+----------+---------------+ 2816 | Connection | http | standard | Section 6.1 | 2817 | Content-Length | http | standard | Section 3.3.2 | 2818 | Host | http | standard | Section 5.4 | 2819 | TE | http | standard | Section 4.3 | 2820 | Trailer | http | standard | Section 4.4 | 2821 | Transfer-Encoding | http | standard | Section 3.3.1 | 2822 | Upgrade | http | standard | Section 6.7 | 2823 | Via | http | standard | Section 5.7.1 | 2824 +-------------------+----------+----------+---------------+ 2826 Furthermore, the header field-name "Close" shall be registered as 2827 "reserved", since using that name as an HTTP header field might 2828 conflict with the "close" connection option of the "Connection" 2829 header field (Section 6.1). 2831 +-------------------+----------+----------+-------------+ 2832 | Header Field Name | Protocol | Status | Reference | 2833 +-------------------+----------+----------+-------------+ 2834 | Close | http | reserved | Section 8.1 | 2835 +-------------------+----------+----------+-------------+ 2837 The change controller is: "IETF (iesg@ietf.org) - Internet 2838 Engineering Task Force". 2840 8.2. URI Scheme Registration 2842 IANA maintains the registry of URI Schemes [BCP115] at 2843 . 2845 This document defines the following URI schemes, so their associated 2846 registry entries shall be updated according to the permanent 2847 registrations below: 2849 +------------+------------------------------------+---------------+ 2850 | URI Scheme | Description | Reference | 2851 +------------+------------------------------------+---------------+ 2852 | http | Hypertext Transfer Protocol | Section 2.7.1 | 2853 | https | Hypertext Transfer Protocol Secure | Section 2.7.2 | 2854 +------------+------------------------------------+---------------+ 2856 8.3. Internet Media Type Registration 2858 IANA maintains the registry of Internet media types [BCP13] at 2859 . 2861 This document serves as the specification for the Internet media 2862 types "message/http" and "application/http". The following is to be 2863 registered with IANA. 2865 8.3.1. Internet Media Type message/http 2867 The message/http type can be used to enclose a single HTTP request or 2868 response message, provided that it obeys the MIME restrictions for 2869 all "message" types regarding line length and encodings. 2871 Type name: message 2873 Subtype name: http 2875 Required parameters: N/A 2877 Optional parameters: version, msgtype 2879 version: The HTTP-version number of the enclosed message (e.g., 2880 "1.1"). If not present, the version can be determined from the 2881 first line of the body. 2883 msgtype: The message type -- "request" or "response". If not 2884 present, the type can be determined from the first line of the 2885 body. 2887 Encoding considerations: only "7bit", "8bit", or "binary" are 2888 permitted 2890 Security considerations: see Section 9 2892 Interoperability considerations: N/A 2893 Published specification: This specification (see Section 8.3.1). 2895 Applications that use this media type: N/A 2897 Fragment identifier considerations: N/A 2899 Additional information: 2901 Magic number(s): N/A 2903 Deprecated alias names for this type: N/A 2905 File extension(s): N/A 2907 Macintosh file type code(s): N/A 2909 Person and email address to contact for further information: See 2910 Authors Section. 2912 Intended usage: COMMON 2914 Restrictions on usage: N/A 2916 Author: See Authors Section. 2918 Change controller: IESG 2920 8.3.2. Internet Media Type application/http 2922 The application/http type can be used to enclose a pipeline of one or 2923 more HTTP request or response messages (not intermixed). 2925 Type name: application 2927 Subtype name: http 2929 Required parameters: N/A 2931 Optional parameters: version, msgtype 2933 version: The HTTP-version number of the enclosed messages (e.g., 2934 "1.1"). If not present, the version can be determined from the 2935 first line of the body. 2937 msgtype: The message type -- "request" or "response". If not 2938 present, the type can be determined from the first line of the 2939 body. 2941 Encoding considerations: HTTP messages enclosed by this type are in 2942 "binary" format; use of an appropriate Content-Transfer-Encoding 2943 is required when transmitted via E-mail. 2945 Security considerations: see Section 9 2947 Interoperability considerations: N/A 2949 Published specification: This specification (see Section 8.3.2). 2951 Applications that use this media type: N/A 2953 Fragment identifier considerations: N/A 2955 Additional information: 2957 Deprecated alias names for this type: N/A 2959 Magic number(s): N/A 2961 File extension(s): N/A 2963 Macintosh file type code(s): N/A 2965 Person and email address to contact for further information: See 2966 Authors Section. 2968 Intended usage: COMMON 2970 Restrictions on usage: N/A 2972 Author: See Authors Section. 2974 Change controller: IESG 2976 8.4. Transfer Coding Registry 2978 The HTTP Transfer Coding Registry defines the name space for transfer 2979 coding names. It is maintained at 2980 . 2982 8.4.1. Procedure 2984 Registrations MUST include the following fields: 2986 o Name 2987 o Description 2989 o Pointer to specification text 2991 Names of transfer codings MUST NOT overlap with names of content 2992 codings (Section 3.1.2.1 of [Part2]) unless the encoding 2993 transformation is identical, as is the case for the compression 2994 codings defined in Section 4.2. 2996 Values to be added to this name space require IETF Review (see 2997 Section 4.1 of [RFC5226]), and MUST conform to the purpose of 2998 transfer coding defined in this specification. 3000 Use of program names for the identification of encoding formats is 3001 not desirable and is discouraged for future encodings. 3003 8.4.2. Registration 3005 The HTTP Transfer Coding Registry shall be updated with the 3006 registrations below: 3008 +------------+--------------------------------------+---------------+ 3009 | Name | Description | Reference | 3010 +------------+--------------------------------------+---------------+ 3011 | chunked | Transfer in a series of chunks | Section 4.1 | 3012 | compress | UNIX "compress" data format [Welch] | Section 4.2.1 | 3013 | deflate | "deflate" compressed data | Section 4.2.2 | 3014 | | ([RFC1951]) inside the "zlib" data | | 3015 | | format ([RFC1950]) | | 3016 | gzip | GZIP file format [RFC1952] | Section 4.2.3 | 3017 | x-compress | Deprecated (alias for compress) | Section 4.2.1 | 3018 | x-gzip | Deprecated (alias for gzip) | Section 4.2.3 | 3019 +------------+--------------------------------------+---------------+ 3021 8.5. Content Coding Registration 3023 IANA maintains the registry of HTTP Content Codings at 3024 . 3026 The HTTP Content Codings Registry shall be updated with the 3027 registrations below: 3029 +------------+--------------------------------------+---------------+ 3030 | Name | Description | Reference | 3031 +------------+--------------------------------------+---------------+ 3032 | compress | UNIX "compress" data format [Welch] | Section 4.2.1 | 3033 | deflate | "deflate" compressed data | Section 4.2.2 | 3034 | | ([RFC1951]) inside the "zlib" data | | 3035 | | format ([RFC1950]) | | 3036 | gzip | GZIP file format [RFC1952] | Section 4.2.3 | 3037 | x-compress | Deprecated (alias for compress) | Section 4.2.1 | 3038 | x-gzip | Deprecated (alias for gzip) | Section 4.2.3 | 3039 +------------+--------------------------------------+---------------+ 3041 8.6. Upgrade Token Registry 3043 The HTTP Upgrade Token Registry defines the name space for protocol- 3044 name tokens used to identify protocols in the Upgrade header field. 3045 The registry is maintained at 3046 . 3048 8.6.1. Procedure 3050 Each registered protocol name is associated with contact information 3051 and an optional set of specifications that details how the connection 3052 will be processed after it has been upgraded. 3054 Registrations happen on a "First Come First Served" basis (see 3055 Section 4.1 of [RFC5226]) and are subject to the following rules: 3057 1. A protocol-name token, once registered, stays registered forever. 3059 2. The registration MUST name a responsible party for the 3060 registration. 3062 3. The registration MUST name a point of contact. 3064 4. The registration MAY name a set of specifications associated with 3065 that token. Such specifications need not be publicly available. 3067 5. The registration SHOULD name a set of expected "protocol-version" 3068 tokens associated with that token at the time of registration. 3070 6. The responsible party MAY change the registration at any time. 3071 The IANA will keep a record of all such changes, and make them 3072 available upon request. 3074 7. The IESG MAY reassign responsibility for a protocol token. This 3075 will normally only be used in the case when a responsible party 3076 cannot be contacted. 3078 This registration procedure for HTTP Upgrade Tokens replaces that 3079 previously defined in Section 7.2 of [RFC2817]. 3081 8.6.2. Upgrade Token Registration 3083 The "HTTP" entry in the HTTP Upgrade Token Registry shall be updated 3084 with the registration below: 3086 +-------+----------------------+----------------------+-------------+ 3087 | Value | Description | Expected Version | Reference | 3088 | | | Tokens | | 3089 +-------+----------------------+----------------------+-------------+ 3090 | HTTP | Hypertext Transfer | any DIGIT.DIGIT | Section 2.6 | 3091 | | Protocol | (e.g, "2.0") | | 3092 +-------+----------------------+----------------------+-------------+ 3094 The responsible party is: "IETF (iesg@ietf.org) - Internet 3095 Engineering Task Force". 3097 9. Security Considerations 3099 This section is meant to inform developers, information providers, 3100 and users of known security considerations relevant to HTTP message 3101 syntax, parsing, and routing. Security considerations about HTTP 3102 semantics and payloads are addressed in [Part2]. 3104 9.1. Establishing Authority 3106 HTTP relies on the notion of an authoritative response: a response 3107 that has been determined by (or at the direction of) the authority 3108 identified within the target URI to be the most appropriate response 3109 for that request given the state of the target resource at the time 3110 of response message origination. Providing a response from a non- 3111 authoritative source, such as a shared cache, is often useful to 3112 improve performance and availability, but only to the extent that the 3113 source can be trusted or the distrusted response can be safely used. 3115 Unfortunately, establishing authority can be difficult. For example, 3116 phishing is an attack on the user's perception of authority, where 3117 that perception can be misled by presenting similar branding in 3118 hypertext, possibly aided by userinfo obfuscating the authority 3119 component (see Section 2.7.1). User agents can reduce the impact of 3120 phishing attacks by enabling users to easily inspect a target URI 3121 prior to making an action, by prominently distinguishing (or 3122 rejecting) userinfo when present, and by not sending stored 3123 credentials and cookies when the referring document is from an 3124 unknown or untrusted source. 3126 When a registered name is used in the authority component, the "http" 3127 URI scheme (Section 2.7.1) relies on the user's local name resolution 3128 service to determine where it can find authoritative responses. This 3129 means that any attack on a user's network host table, cached names, 3130 or name resolution libraries becomes an avenue for attack on 3131 establishing authority. Likewise, the user's choice of server for 3132 Domain Name Service (DNS), and the hierarchy of servers from which it 3133 obtains resolution results, could impact the authenticity of address 3134 mappings; DNSSEC ([RFC4033]) is one way to improve authenticity. 3136 Furthermore, after an IP address is obtained, establishing authority 3137 for an "http" URI is vulnerable to attacks on Internet Protocol 3138 routing. 3140 The "https" scheme (Section 2.7.2) is intended to prevent (or at 3141 least reveal) many of these potential attacks on establishing 3142 authority, provided that the negotiated TLS connection is secured and 3143 the client properly verifies that the communicating server's identity 3144 matches the target URI's authority component (see [RFC2818]). 3145 Correctly implementing such verification can be difficult (see 3146 [Georgiev]). 3148 9.2. Risks of Intermediaries 3150 By their very nature, HTTP intermediaries are men-in-the-middle, and 3151 thus represent an opportunity for man-in-the-middle attacks. 3152 Compromise of the systems on which the intermediaries run can result 3153 in serious security and privacy problems. Intermediaries might have 3154 access to security-related information, personal information about 3155 individual users and organizations, and proprietary information 3156 belonging to users and content providers. A compromised 3157 intermediary, or an intermediary implemented or configured without 3158 regard to security and privacy considerations, might be used in the 3159 commission of a wide range of potential attacks. 3161 Intermediaries that contain a shared cache are especially vulnerable 3162 to cache poisoning attacks, as described in Section 8 of [Part6]. 3164 Implementers need to consider the privacy and security implications 3165 of their design and coding decisions, and of the configuration 3166 options they provide to operators (especially the default 3167 configuration). 3169 Users need to be aware that intermediaries are no more trustworthy 3170 than the people who run them; HTTP itself cannot solve this problem. 3172 9.3. Attacks via Protocol Element Length 3174 Because HTTP uses mostly textual, character-delimited fields, parsers 3175 are often vulnerable to attacks based on sending very long (or very 3176 slow) streams of data, particularly where an implementation is 3177 expecting a protocol element with no predefined length. 3179 To promote interoperability, specific recommendations are made for 3180 minimum size limits on request-line (Section 3.1.1) and header fields 3181 (Section 3.2). These are minimum recommendations, chosen to be 3182 supportable even by implementations with limited resources; it is 3183 expected that most implementations will choose substantially higher 3184 limits. 3186 A server can reject a message that has a request-target that is too 3187 long (Section 6.5.12 of [Part2]) or a request payload that is too 3188 large (Section 6.5.11 of [Part2]). Additional status codes related 3189 to capacity limits have been defined by extensions to HTTP [RFC6585]. 3191 Recipients ought to carefully limit the extent to which they process 3192 other protocol elements, including (but not limited to) request 3193 methods, response status phrases, header field-names, numeric values, 3194 and body chunks. Failure to limit such processing can result in 3195 buffer overflows, arithmetic overflows, or increased vulnerability to 3196 denial of service attacks. 3198 9.4. Response Splitting 3200 Response splitting (a.k.a, CRLF injection) is a common technique, 3201 used in various attacks on Web usage, that exploits the line-based 3202 nature of HTTP message framing and the ordered association of 3203 requests to responses on persistent connections [Klein]. This 3204 technique can be particularly damaging when the requests pass through 3205 a shared cache. 3207 Response splitting exploits a vulnerability in servers (usually 3208 within an application server) where an attacker can send encoded data 3209 within some parameter of the request that is later decoded and echoed 3210 within any of the response header fields of the response. If the 3211 decoded data is crafted to look like the response has ended and a 3212 subsequent response has begun, the response has been split and the 3213 content within the apparent second response is controlled by the 3214 attacker. The attacker can then make any other request on the same 3215 persistent connection and trick the recipients (including 3216 intermediaries) into believing that the second half of the split is 3217 an authoritative answer to the second request. 3219 For example, a parameter within the request-target might be read by 3220 an application server and reused within a redirect, resulting in the 3221 same parameter being echoed in the Location header field of the 3222 response. If the parameter is decoded by the application and not 3223 properly encoded when placed in the response field, the attacker can 3224 send encoded CRLF octets and other content that will make the 3225 application's single response look like two or more responses. 3227 A common defense against response splitting is to filter requests for 3228 data that looks like encoded CR and LF (e.g., "%0D" and "%0A"). 3229 However, that assumes the application server is only performing URI 3230 decoding, rather than more obscure data transformations like charset 3231 transcoding, XML entity translation, base64 decoding, sprintf 3232 reformatting, etc. A more effective mitigation is to prevent 3233 anything other than the server's core protocol libraries from sending 3234 a CR or LF within the header section, which means restricting the 3235 output of header fields to APIs that filter for bad octets and not 3236 allowing application servers to write directly to the protocol 3237 stream. 3239 9.5. Request Smuggling 3241 Request smuggling ([Linhart]) is a technique that exploits 3242 differences in protocol parsing among various recipients to hide 3243 additional requests (which might otherwise be blocked or disabled by 3244 policy) within an apparently harmless request. Like response 3245 splitting, request smuggling can lead to a variety of attacks on HTTP 3246 usage. 3248 This specification has introduced new requirements on request 3249 parsing, particularly with regard to message framing in 3250 Section 3.3.3, to reduce the effectiveness of request smuggling. 3252 9.6. Message Integrity 3254 HTTP does not define a specific mechanism for ensuring message 3255 integrity, instead relying on the error-detection ability of 3256 underlying transport protocols and the use of length or chunk- 3257 delimited framing to detect completeness. Additional integrity 3258 mechanisms, such as hash functions or digital signatures applied to 3259 the content, can be selectively added to messages via extensible 3260 metadata header fields. Historically, the lack of a single integrity 3261 mechanism has been justified by the informal nature of most HTTP 3262 communication. However, the prevalence of HTTP as an information 3263 access mechanism has resulted in its increasing use within 3264 environments where verification of message integrity is crucial. 3266 User agents are encouraged to implement configurable means for 3267 detecting and reporting failures of message integrity such that those 3268 means can be enabled within environments for which integrity is 3269 necessary. For example, a browser being used to view medical history 3270 or drug interaction information needs to indicate to the user when 3271 such information is detected by the protocol to be incomplete, 3272 expired, or corrupted during transfer. Such mechanisms might be 3273 selectively enabled via user agent extensions or the presence of 3274 message integrity metadata in a response. At a minimum, user agents 3275 ought to provide some indication that allows a user to distinguish 3276 between a complete and incomplete response message (Section 3.4) when 3277 such verification is desired. 3279 9.7. Message Confidentiality 3281 HTTP relies on underlying transport protocols to provide message 3282 confidentiality when that is desired. HTTP has been specifically 3283 designed to be independent of the transport protocol, such that it 3284 can be used over many different forms of encrypted connection, with 3285 the selection of such transports being identified by the choice of 3286 URI scheme or within user agent configuration. 3288 The "https" scheme can be used to identify resources that require a 3289 confidential connection, as described in Section 2.7.2. 3291 9.8. Privacy of Server Log Information 3293 A server is in the position to save personal data about a user's 3294 requests over time, which might identify their reading patterns or 3295 subjects of interest. In particular, log information gathered at an 3296 intermediary often contains a history of user agent interaction, 3297 across a multitude of sites, that can be traced to individual users. 3299 HTTP log information is confidential in nature; its handling is often 3300 constrained by laws and regulations. Log information needs to be 3301 securely stored and appropriate guidelines followed for its analysis. 3302 Anonymization of personal information within individual entries 3303 helps, but is generally not sufficient to prevent real log traces 3304 from being re-identified based on correlation with other access 3305 characteristics. As such, access traces that are keyed to a specific 3306 client are unsafe to publish even if the key is pseudonymous. 3308 To minimize the risk of theft or accidental publication, log 3309 information ought to be purged of personally identifiable 3310 information, including user identifiers, IP addresses, and user- 3311 provided query parameters, as soon as that information is no longer 3312 necessary to support operational needs for security, auditing, or 3313 fraud control. 3315 10. Acknowledgments 3317 This edition of HTTP/1.1 builds on the many contributions that went 3318 into RFC 1945, RFC 2068, RFC 2145, and RFC 2616, including 3319 substantial contributions made by the previous authors, editors, and 3320 working group chairs: Tim Berners-Lee, Ari Luotonen, Roy T. Fielding, 3321 Henrik Frystyk Nielsen, Jim Gettys, Jeffrey C. Mogul, Larry Masinter, 3322 and Paul J. Leach. Mark Nottingham oversaw this effort as working 3323 group chair. 3325 Since 1999, the following contributors have helped improve the HTTP 3326 specification by reporting bugs, asking smart questions, drafting or 3327 reviewing text, and evaluating open issues: 3329 Adam Barth, Adam Roach, Addison Phillips, Adrian Chadd, Adrian Cole, 3330 Adrien W. de Croy, Alan Ford, Alan Ruttenberg, Albert Lunde, Alek 3331 Storm, Alex Rousskov, Alexandre Morgaut, Alexey Melnikov, Alisha 3332 Smith, Amichai Rothman, Amit Klein, Amos Jeffries, Andreas Maier, 3333 Andreas Petersson, Andrei Popov, Anil Sharma, Anne van Kesteren, 3334 Anthony Bryan, Asbjorn Ulsberg, Ashok Kumar, Balachander 3335 Krishnamurthy, Barry Leiba, Ben Laurie, Benjamin Carlyle, Benjamin 3336 Niven-Jenkins, Benoit Claise, Bil Corry, Bill Burke, Bjoern 3337 Hoehrmann, Bob Scheifler, Boris Zbarsky, Brett Slatkin, Brian Kell, 3338 Brian McBarron, Brian Pane, Brian Raymor, Brian Smith, Bruce Perens, 3339 Bryce Nesbitt, Cameron Heavon-Jones, Carl Kugler, Carsten Bormann, 3340 Charles Fry, Chris Burdess, Chris Newman, Christian Huitema, Cyrus 3341 Daboo, Dale Robert Anderson, Dan Wing, Dan Winship, Daniel Stenberg, 3342 Darrel Miller, Dave Cridland, Dave Crocker, Dave Kristol, Dave 3343 Thaler, David Booth, David Singer, David W. Morris, Diwakar Shetty, 3344 Dmitry Kurochkin, Drummond Reed, Duane Wessels, Edward Lee, Eitan 3345 Adler, Eliot Lear, Emile Stephan, Eran Hammer-Lahav, Eric D. 3346 Williams, Eric J. Bowman, Eric Lawrence, Eric Rescorla, Erik 3347 Aronesty, EungJun Yi, Evan Prodromou, Felix Geisendoerfer, Florian 3348 Weimer, Frank Ellermann, Fred Akalin, Fred Bohle, Frederic Kayser, 3349 Gabor Molnar, Gabriel Montenegro, Geoffrey Sneddon, Gervase Markham, 3350 Gili Tzabari, Grahame Grieve, Greg Slepak, Greg Wilkins, Grzegorz 3351 Calkowski, Harald Tveit Alvestrand, Harry Halpin, Helge Hess, Henrik 3352 Nordstrom, Henry S. Thompson, Henry Story, Herbert van de Sompel, 3353 Herve Ruellan, Howard Melman, Hugo Haas, Ian Fette, Ian Hickson, Ido 3354 Safruti, Ilari Liusvaara, Ilya Grigorik, Ingo Struck, J. Ross Nicoll, 3355 James Cloos, James H. Manger, James Lacey, James M. Snell, Jamie 3356 Lokier, Jan Algermissen, Jari Arkko, Jeff Hodges (who came up with 3357 the term 'effective Request-URI'), Jeff Pinner, Jeff Walden, Jim 3358 Luther, Jitu Padhye, Joe D. Williams, Joe Gregorio, Joe Orton, Joel 3359 Jaeggli, John C. Klensin, John C. Mallery, John Cowan, John Kemp, 3360 John Panzer, John Schneider, John Stracke, John Sullivan, Jonas 3361 Sicking, Jonathan A. Rees, Jonathan Billington, Jonathan Moore, 3362 Jonathan Silvera, Jordi Ros, Joris Dobbelsteen, Josh Cohen, Julien 3363 Pierre, Jungshik Shin, Justin Chapweske, Justin Erenkrantz, Justin 3364 James, Kalvinder Singh, Karl Dubost, Kathleen Moriarty, Keith 3365 Hoffman, Keith Moore, Ken Murchison, Koen Holtman, Konstantin 3366 Voronkov, Kris Zyp, Leif Hedstrom, Lionel Morand, Lisa Dusseault, 3367 Maciej Stachowiak, Manu Sporny, Marc Schneider, Marc Slemko, Mark 3368 Baker, Mark Pauley, Mark Watson, Markus Isomaki, Markus Lanthaler, 3369 Martin J. Duerst, Martin Musatov, Martin Nilsson, Martin Thomson, 3370 Matt Lynch, Matthew Cox, Matthew Kerwin, Max Clark, Menachem Dodge, 3371 Meral Shirazipour, Michael Burrows, Michael Hausenblas, Michael 3372 Scharf, Michael Sweet, Michael Tuexen, Michael Welzl, Mike Amundsen, 3373 Mike Belshe, Mike Bishop, Mike Kelly, Mike Schinkel, Miles Sabin, 3374 Murray S. Kucherawy, Mykyta Yevstifeyev, Nathan Rixham, Nicholas 3375 Shanks, Nico Williams, Nicolas Alvarez, Nicolas Mailhot, Noah Slater, 3376 Osama Mazahir, Pablo Castro, Pat Hayes, Patrick R. McManus, Paul E. 3377 Jones, Paul Hoffman, Paul Marquess, Pete Resnick, Peter Lepeska, 3378 Peter Occil, Peter Saint-Andre, Peter Watkins, Phil Archer, Phil 3379 Hunt, Philippe Mougin, Phillip Hallam-Baker, Piotr Dobrogost, Poul- 3380 Henning Kamp, Preethi Natarajan, Rajeev Bector, Ray Polk, Reto 3381 Bachmann-Gmuer, Richard Barnes, Richard Cyganiak, Rob Trace, Robby 3382 Simpson, Robert Brewer, Robert Collins, Robert Mattson, Robert 3383 O'Callahan, Robert Olofsson, Robert Sayre, Robert Siemer, Robert de 3384 Wilde, Roberto Javier Godoy, Roberto Peon, Roland Zink, Ronny 3385 Widjaja, Ryan Hamilton, S. Mike Dierken, Salvatore Loreto, Sam 3386 Johnston, Sam Pullara, Sam Ruby, Saurabh Kulkarni, Scott Lawrence 3387 (who maintained the original issues list), Sean B. Palmer, Sean 3388 Turner, Sebastien Barnoud, Shane McCarron, Shigeki Ohtsu, Simon 3389 Yarde, Stefan Eissing, Stefan Tilkov, Stefanos Harhalakis, Stephane 3390 Bortzmeyer, Stephen Farrell, Stephen Kent, Stephen Ludin, Stuart 3391 Williams, Subbu Allamaraju, Subramanian Moonesamy, Susan Hares, 3392 Sylvain Hellegouarch, Tapan Divekar, Tatsuhiro Tsujikawa, Tatsuya 3393 Hayashi, Ted Hardie, Ted Lemon, Thomas Broyer, Thomas Fossati, Thomas 3394 Maslen, Thomas Nadeau, Thomas Nordin, Thomas Roessler, Tim Bray, Tim 3395 Morgan, Tim Olsen, Tom Zhou, Travis Snoozy, Tyler Close, Vincent 3396 Murphy, Wenbo Zhu, Werner Baumann, Wilbur Streett, Wilfredo Sanchez 3397 Vega, William A. Rowe Jr., William Chan, Willy Tarreau, Xiaoshu Wang, 3398 Yaron Goland, Yngve Nysaeter Pettersen, Yoav Nir, Yogesh Bang, 3399 Yuchung Cheng, Yutaka Oiwa, Yves Lafon (long-time member of the 3400 editor team), Zed A. Shaw, and Zhong Yu. 3402 See Section 16 of [RFC2616] for additional acknowledgements from 3403 prior revisions. 3405 11. References 3407 11.1. Normative References 3409 [Part2] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext 3410 Transfer Protocol (HTTP/1.1): Semantics and Content", 3411 draft-ietf-httpbis-p2-semantics-26 (work in progress), 3412 February 2014. 3414 [Part4] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext 3415 Transfer Protocol (HTTP/1.1): Conditional Requests", 3416 draft-ietf-httpbis-p4-conditional-26 (work in 3417 progress), February 2014. 3419 [Part5] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., 3420 "Hypertext Transfer Protocol (HTTP/1.1): Range 3421 Requests", draft-ietf-httpbis-p5-range-26 (work in 3422 progress), February 2014. 3424 [Part6] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, 3425 Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", 3426 draft-ietf-httpbis-p6-cache-26 (work in progress), 3427 February 2014. 3429 [Part7] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext 3430 Transfer Protocol (HTTP/1.1): Authentication", 3431 draft-ietf-httpbis-p7-auth-26 (work in progress), 3432 February 2014. 3434 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 3435 RFC 793, September 1981. 3437 [RFC1950] Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data 3438 Format Specification version 3.3", RFC 1950, May 1996. 3440 [RFC1951] Deutsch, P., "DEFLATE Compressed Data Format 3441 Specification version 1.3", RFC 1951, May 1996. 3443 [RFC1952] Deutsch, P., Gailly, J-L., Adler, M., Deutsch, L., and 3444 G. Randers-Pehrson, "GZIP file format specification 3445 version 4.3", RFC 1952, May 1996. 3447 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3448 Requirement Levels", BCP 14, RFC 2119, March 1997. 3450 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, 3451 "Uniform Resource Identifier (URI): Generic Syntax", 3452 STD 66, RFC 3986, January 2005. 3454 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for 3455 Syntax Specifications: ABNF", STD 68, RFC 5234, 3456 January 2008. 3458 [USASCII] American National Standards Institute, "Coded Character 3459 Set -- 7-bit American Standard Code for Information 3460 Interchange", ANSI X3.4, 1986. 3462 [Welch] Welch, T., "A Technique for High Performance Data 3463 Compression", IEEE Computer 17(6), June 1984. 3465 11.2. Informative References 3467 [BCP115] Hansen, T., Hardie, T., and L. Masinter, "Guidelines 3468 and Registration Procedures for New URI Schemes", 3469 BCP 115, RFC 4395, February 2006. 3471 [BCP13] Freed, N., Klensin, J., and T. Hansen, "Media Type 3472 Specifications and Registration Procedures", BCP 13, 3473 RFC 6838, January 2013. 3475 [BCP90] Klyne, G., Nottingham, M., and J. Mogul, "Registration 3476 Procedures for Message Header Fields", BCP 90, 3477 RFC 3864, September 2004. 3479 [Georgiev] Georgiev, M., Iyengar, S., Jana, S., Anubhai, R., 3480 Boneh, D., and V. Shmatikov, "The Most Dangerous Code 3481 in the World: Validating SSL Certificates in Non- 3482 browser Software", In Proceedings of the 2012 ACM 3483 Conference on Computer and Communications Security (CCS 3484 '12), pp. 38-49, October 2012, 3485 . 3487 [ISO-8859-1] International Organization for Standardization, 3488 "Information technology -- 8-bit single-byte coded 3489 graphic character sets -- Part 1: Latin alphabet No. 3490 1", ISO/IEC 8859-1:1998, 1998. 3492 [Klein] Klein, A., "Divide and Conquer - HTTP Response 3493 Splitting, Web Cache Poisoning Attacks, and Related 3494 Topics", March 2004, . 3497 [Kri2001] Kristol, D., "HTTP Cookies: Standards, Privacy, and 3498 Politics", ACM Transactions on Internet 3499 Technology 1(2), November 2001, 3500 . 3502 [Linhart] Linhart, C., Klein, A., Heled, R., and S. Orrin, "HTTP 3503 Request Smuggling", June 2005, 3504 . 3506 [RFC1919] Chatel, M., "Classical versus Transparent IP Proxies", 3507 RFC 1919, March 1996. 3509 [RFC1945] Berners-Lee, T., Fielding, R., and H. Nielsen, 3510 "Hypertext Transfer Protocol -- HTTP/1.0", RFC 1945, 3511 May 1996. 3513 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet 3514 Mail Extensions (MIME) Part One: Format of Internet 3515 Message Bodies", RFC 2045, November 1996. 3517 [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail 3518 Extensions) Part Three: Message Header Extensions for 3519 Non-ASCII Text", RFC 2047, November 1996. 3521 [RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and 3522 T. Berners-Lee, "Hypertext Transfer Protocol -- 3523 HTTP/1.1", RFC 2068, January 1997. 3525 [RFC2145] Mogul, J., Fielding, R., Gettys, J., and H. Nielsen, 3526 "Use and Interpretation of HTTP Version Numbers", 3527 RFC 2145, May 1997. 3529 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 3530 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 3531 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 3533 [RFC2817] Khare, R. and S. Lawrence, "Upgrading to TLS Within 3534 HTTP/1.1", RFC 2817, May 2000. 3536 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 3538 [RFC3040] Cooper, I., Melve, I., and G. Tomlinson, "Internet Web 3539 Replication and Caching Taxonomy", RFC 3040, 3540 January 2001. 3542 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 3543 Rose, "DNS Security Introduction and Requirements", 3544 RFC 4033, March 2005. 3546 [RFC4559] Jaganathan, K., Zhu, L., and J. Brezak, "SPNEGO-based 3547 Kerberos and NTLM HTTP Authentication in Microsoft 3548 Windows", RFC 4559, June 2006. 3550 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing 3551 an IANA Considerations Section in RFCs", BCP 26, 3552 RFC 5226, May 2008. 3554 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer 3555 Security (TLS) Protocol Version 1.2", RFC 5246, 3556 August 2008. 3558 [RFC5322] Resnick, P., "Internet Message Format", RFC 5322, 3559 October 2008. 3561 [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, 3562 April 2011. 3564 [RFC6585] Nottingham, M. and R. Fielding, "Additional HTTP Status 3565 Codes", RFC 6585, April 2012. 3567 Appendix A. HTTP Version History 3569 HTTP has been in use since 1990. The first version, later referred 3570 to as HTTP/0.9, was a simple protocol for hypertext data transfer 3571 across the Internet, using only a single request method (GET) and no 3572 metadata. HTTP/1.0, as defined by [RFC1945], added a range of 3573 request methods and MIME-like messaging, allowing for metadata to be 3574 transferred and modifiers placed on the request/response semantics. 3575 However, HTTP/1.0 did not sufficiently take into consideration the 3576 effects of hierarchical proxies, caching, the need for persistent 3577 connections, or name-based virtual hosts. The proliferation of 3578 incompletely-implemented applications calling themselves "HTTP/1.0" 3579 further necessitated a protocol version change in order for two 3580 communicating applications to determine each other's true 3581 capabilities. 3583 HTTP/1.1 remains compatible with HTTP/1.0 by including more stringent 3584 requirements that enable reliable implementations, adding only those 3585 features that can either be safely ignored by an HTTP/1.0 recipient 3586 or only sent when communicating with a party advertising conformance 3587 with HTTP/1.1. 3589 HTTP/1.1 has been designed to make supporting previous versions easy. 3590 A general-purpose HTTP/1.1 server ought to be able to understand any 3591 valid request in the format of HTTP/1.0, responding appropriately 3592 with an HTTP/1.1 message that only uses features understood (or 3593 safely ignored) by HTTP/1.0 clients. Likewise, an HTTP/1.1 client 3594 can be expected to understand any valid HTTP/1.0 response. 3596 Since HTTP/0.9 did not support header fields in a request, there is 3597 no mechanism for it to support name-based virtual hosts (selection of 3598 resource by inspection of the Host header field). Any server that 3599 implements name-based virtual hosts ought to disable support for 3600 HTTP/0.9. Most requests that appear to be HTTP/0.9 are, in fact, 3601 badly constructed HTTP/1.x requests caused by a client failing to 3602 properly encode the request-target. 3604 A.1. Changes from HTTP/1.0 3606 This section summarizes major differences between versions HTTP/1.0 3607 and HTTP/1.1. 3609 A.1.1. Multi-homed Web Servers 3611 The requirements that clients and servers support the Host header 3612 field (Section 5.4), report an error if it is missing from an 3613 HTTP/1.1 request, and accept absolute URIs (Section 5.3) are among 3614 the most important changes defined by HTTP/1.1. 3616 Older HTTP/1.0 clients assumed a one-to-one relationship of IP 3617 addresses and servers; there was no other established mechanism for 3618 distinguishing the intended server of a request than the IP address 3619 to which that request was directed. The Host header field was 3620 introduced during the development of HTTP/1.1 and, though it was 3621 quickly implemented by most HTTP/1.0 browsers, additional 3622 requirements were placed on all HTTP/1.1 requests in order to ensure 3623 complete adoption. At the time of this writing, most HTTP-based 3624 services are dependent upon the Host header field for targeting 3625 requests. 3627 A.1.2. Keep-Alive Connections 3629 In HTTP/1.0, each connection is established by the client prior to 3630 the request and closed by the server after sending the response. 3631 However, some implementations implement the explicitly negotiated 3632 ("Keep-Alive") version of persistent connections described in Section 3633 19.7.1 of [RFC2068]. 3635 Some clients and servers might wish to be compatible with these 3636 previous approaches to persistent connections, by explicitly 3637 negotiating for them with a "Connection: keep-alive" request header 3638 field. However, some experimental implementations of HTTP/1.0 3639 persistent connections are faulty; for example, if an HTTP/1.0 proxy 3640 server doesn't understand Connection, it will erroneously forward 3641 that header field to the next inbound server, which would result in a 3642 hung connection. 3644 One attempted solution was the introduction of a Proxy-Connection 3645 header field, targeted specifically at proxies. In practice, this 3646 was also unworkable, because proxies are often deployed in multiple 3647 layers, bringing about the same problem discussed above. 3649 As a result, clients are encouraged not to send the Proxy-Connection 3650 header field in any requests. 3652 Clients are also encouraged to consider the use of Connection: keep- 3653 alive in requests carefully; while they can enable persistent 3654 connections with HTTP/1.0 servers, clients using them will need to 3655 monitor the connection for "hung" requests (which indicate that the 3656 client ought stop sending the header field), and this mechanism ought 3657 not be used by clients at all when a proxy is being used. 3659 A.1.3. Introduction of Transfer-Encoding 3661 HTTP/1.1 introduces the Transfer-Encoding header field 3662 (Section 3.3.1). Transfer codings need to be decoded prior to 3663 forwarding an HTTP message over a MIME-compliant protocol. 3665 A.2. Changes from RFC 2616 3667 HTTP's approach to error handling has been explained. (Section 2.5) 3669 The HTTP-version ABNF production has been clarified to be case- 3670 sensitive. Additionally, version numbers has been restricted to 3671 single digits, due to the fact that implementations are known to 3672 handle multi-digit version numbers incorrectly. (Section 2.6) 3674 Userinfo (i.e., username and password) are now disallowed in HTTP and 3675 HTTPS URIs, because of security issues related to their transmission 3676 on the wire. (Section 2.7.1) 3678 The HTTPS URI scheme is now defined by this specification; 3679 previously, it was done in Section 2.4 of [RFC2818]. Furthermore, it 3680 implies end-to-end security. (Section 2.7.2) 3682 HTTP messages can be (and often are) buffered by implementations; 3683 despite it sometimes being available as a stream, HTTP is 3684 fundamentally a message-oriented protocol. Minimum supported sizes 3685 for various protocol elements have been suggested, to improve 3686 interoperability. (Section 3) 3688 Invalid whitespace around field-names is now required to be rejected, 3689 because accepting it represents a security vulnerability. The ABNF 3690 productions defining header fields now only list the field value. 3691 (Section 3.2) 3693 Rules about implicit linear whitespace between certain grammar 3694 productions have been removed; now whitespace is only allowed where 3695 specifically defined in the ABNF. (Section 3.2.3) 3697 Header fields that span multiple lines ("line folding") are 3698 deprecated. (Section 3.2.4) 3699 The NUL octet is no longer allowed in comment and quoted-string text, 3700 and handling of backslash-escaping in them has been clarified. The 3701 quoted-pair rule no longer allows escaping control characters other 3702 than HTAB. Non-ASCII content in header fields and the reason phrase 3703 has been obsoleted and made opaque (the TEXT rule was removed). 3704 (Section 3.2.6) 3706 Bogus "Content-Length" header fields are now required to be handled 3707 as errors by recipients. (Section 3.3.2) 3709 The algorithm for determining the message body length has been 3710 clarified to indicate all of the special cases (e.g., driven by 3711 methods or status codes) that affect it, and that new protocol 3712 elements cannot define such special cases. CONNECT is a new, special 3713 case in determining message body length. "multipart/byteranges" is no 3714 longer a way of determining message body length detection. 3715 (Section 3.3.3) 3717 The "identity" transfer coding token has been removed. (Sections 3.3 3718 and 4) 3720 Chunk length does not include the count of the octets in the chunk 3721 header and trailer. Line folding in chunk extensions is disallowed. 3722 (Section 4.1) 3724 The meaning of the "deflate" content coding has been clarified. 3725 (Section 4.2.2) 3727 The segment + query components of RFC 3986 have been used to define 3728 the request-target, instead of abs_path from RFC 1808. The asterisk- 3729 form of the request-target is only allowed with the OPTIONS method. 3730 (Section 5.3) 3732 The term "Effective Request URI" has been introduced. (Section 5.5) 3734 Gateways do not need to generate Via header fields anymore. 3735 (Section 5.7.1) 3737 Exactly when "close" connection options have to be sent has been 3738 clarified. Also, "hop-by-hop" header fields are required to appear 3739 in the Connection header field; just because they're defined as hop- 3740 by-hop in this specification doesn't exempt them. (Section 6.1) 3742 The limit of two connections per server has been removed. An 3743 idempotent sequence of requests is no longer required to be retried. 3744 The requirement to retry requests under certain circumstances when 3745 the server prematurely closes the connection has been removed. Also, 3746 some extraneous requirements about when servers are allowed to close 3747 connections prematurely have been removed. (Section 6.3) 3749 The semantics of the Upgrade header field is now defined in responses 3750 other than 101 (this was incorporated from [RFC2817]). Furthermore, 3751 the ordering in the field value is now significant. (Section 6.7) 3753 Empty list elements in list productions (e.g., a list header field 3754 containing ", ,") have been deprecated. (Section 7) 3756 Registration of Transfer Codings now requires IETF Review 3757 (Section 8.4) 3759 This specification now defines the Upgrade Token Registry, previously 3760 defined in Section 7.2 of [RFC2817]. (Section 8.6) 3762 The expectation to support HTTP/0.9 requests has been removed. 3763 (Appendix A) 3765 Issues with the Keep-Alive and Proxy-Connection header fields in 3766 requests are pointed out, with use of the latter being discouraged 3767 altogether. (Appendix A.1.2) 3769 Appendix B. Collected ABNF 3771 BWS = OWS 3773 Connection = *( "," OWS ) connection-option *( OWS "," [ OWS 3774 connection-option ] ) 3775 Content-Length = 1*DIGIT 3777 HTTP-message = start-line *( header-field CRLF ) CRLF [ message-body 3778 ] 3779 HTTP-name = %x48.54.54.50 ; HTTP 3780 HTTP-version = HTTP-name "/" DIGIT "." DIGIT 3781 Host = uri-host [ ":" port ] 3783 OWS = *( SP / HTAB ) 3785 RWS = 1*( SP / HTAB ) 3787 TE = [ ( "," / t-codings ) *( OWS "," [ OWS t-codings ] ) ] 3788 Trailer = *( "," OWS ) field-name *( OWS "," [ OWS field-name ] ) 3789 Transfer-Encoding = *( "," OWS ) transfer-coding *( OWS "," [ OWS 3790 transfer-coding ] ) 3792 URI-reference = 3793 Upgrade = *( "," OWS ) protocol *( OWS "," [ OWS protocol ] ) 3794 Via = *( "," OWS ) ( received-protocol RWS received-by [ RWS comment 3795 ] ) *( OWS "," [ OWS ( received-protocol RWS received-by [ RWS 3796 comment ] ) ] ) 3798 absolute-URI = 3799 absolute-form = absolute-URI 3800 absolute-path = 1*( "/" segment ) 3801 asterisk-form = "*" 3802 authority = 3803 authority-form = authority 3805 chunk = chunk-size [ chunk-ext ] CRLF chunk-data CRLF 3806 chunk-data = 1*OCTET 3807 chunk-ext = *( ";" chunk-ext-name [ "=" chunk-ext-val ] ) 3808 chunk-ext-name = token 3809 chunk-ext-val = token / quoted-string 3810 chunk-size = 1*HEXDIG 3811 chunked-body = *chunk last-chunk trailer-part CRLF 3812 comment = "(" *( ctext / quoted-pair / comment ) ")" 3813 connection-option = token 3814 ctext = HTAB / SP / %x21-27 ; '!'-''' 3815 / %x2A-5B ; '*'-'[' 3816 / %x5D-7E ; ']'-'~' 3817 / obs-text 3819 field-content = field-vchar [ 1*( SP / HTAB ) field-vchar ] 3820 field-name = token 3821 field-value = *( field-content / obs-fold ) 3822 field-vchar = VCHAR / obs-text 3823 fragment = 3825 header-field = field-name ":" OWS field-value OWS 3826 http-URI = "http://" authority path-abempty [ "?" query ] [ "#" 3827 fragment ] 3828 https-URI = "https://" authority path-abempty [ "?" query ] [ "#" 3829 fragment ] 3831 last-chunk = 1*"0" [ chunk-ext ] CRLF 3833 message-body = *OCTET 3834 method = token 3836 obs-fold = CRLF 1*( SP / HTAB ) 3837 obs-text = %x80-FF 3838 origin-form = absolute-path [ "?" query ] 3840 partial-URI = relative-part [ "?" query ] 3841 path-abempty = 3842 port = 3843 protocol = protocol-name [ "/" protocol-version ] 3844 protocol-name = token 3845 protocol-version = token 3846 pseudonym = token 3848 qdtext = HTAB / SP / "!" / %x23-5B ; '#'-'[' 3849 / %x5D-7E ; ']'-'~' 3850 / obs-text 3851 query = 3852 quoted-pair = "\" ( HTAB / SP / VCHAR / obs-text ) 3853 quoted-string = DQUOTE *( qdtext / quoted-pair ) DQUOTE 3855 rank = ( "0" [ "." *3DIGIT ] ) / ( "1" [ "." *3"0" ] ) 3856 reason-phrase = *( HTAB / SP / VCHAR / obs-text ) 3857 received-by = ( uri-host [ ":" port ] ) / pseudonym 3858 received-protocol = [ protocol-name "/" ] protocol-version 3859 relative-part = 3860 request-line = method SP request-target SP HTTP-version CRLF 3861 request-target = origin-form / absolute-form / authority-form / 3862 asterisk-form 3864 scheme = 3865 segment = 3866 start-line = request-line / status-line 3867 status-code = 3DIGIT 3868 status-line = HTTP-version SP status-code SP reason-phrase CRLF 3870 t-codings = "trailers" / ( transfer-coding [ t-ranking ] ) 3871 t-ranking = OWS ";" OWS "q=" rank 3872 tchar = "!" / "#" / "$" / "%" / "&" / "'" / "*" / "+" / "-" / "." / 3873 "^" / "_" / "`" / "|" / "~" / DIGIT / ALPHA 3874 token = 1*tchar 3875 trailer-part = *( header-field CRLF ) 3876 transfer-coding = "chunked" / "compress" / "deflate" / "gzip" / 3877 transfer-extension 3878 transfer-extension = token *( OWS ";" OWS transfer-parameter ) 3879 transfer-parameter = token BWS "=" BWS ( token / quoted-string ) 3881 uri-host = 3883 Appendix C. Change Log (to be removed by RFC Editor before publication) 3885 C.1. Since RFC 2616 3887 Changes up to the IETF Last Call draft are summarized in . 3891 C.2. Since draft-ietf-httpbis-p1-messaging-24 3893 Closed issues: 3895 o : "APPSDIR 3896 review of draft-ietf-httpbis-p1-messaging-24" 3898 o : "integer value 3899 parsing" 3901 o : "move IANA 3902 registrations to correct draft" 3904 C.3. Since draft-ietf-httpbis-p1-messaging-25 3906 Closed issues: 3908 o : "check media 3909 type registration templates" 3911 o : "Redundant 3912 rule quoted-str-nf" 3914 o : "IESG ballot 3915 on draft-ietf-httpbis-p1-messaging-25" 3917 o : "add 3918 'stateless' to Abstract" 3920 o : "clarify ABNF 3921 layering" 3923 o : "use of 'word' 3924 ABNF production" 3926 o : "improve 3927 introduction of list rule" 3929 o : "moving 2616/ 3930 2068/2145 to historic" 3932 o : "augment 3933 security considerations with pointers to current research" 3935 o : 3936 "intermediaries handling trailers" 3938 o : "allow privacy 3939 proxies to be conformant" 3941 Index 3943 A 3944 absolute-form (of request-target) 42 3945 accelerator 10 3946 application/http Media Type 62 3947 asterisk-form (of request-target) 42 3948 authoritative response 66 3949 authority-form (of request-target) 42 3951 B 3952 browser 7 3954 C 3955 cache 11 3956 cacheable 11 3957 captive portal 11 3958 chunked (Coding Format) 28, 31, 35 3959 client 7 3960 close 50, 55 3961 compress (Coding Format) 38 3962 connection 7 3963 Connection header field 50, 55 3964 Content-Length header field 30 3966 D 3967 deflate (Coding Format) 38 3968 Delimiters 26 3969 downstream 9 3971 E 3972 effective request URI 44 3974 G 3975 gateway 10 3976 Grammar 3977 absolute-form 41-42 3978 absolute-path 16 3979 absolute-URI 16 3980 ALPHA 6 3981 asterisk-form 41-42 3982 authority 16 3983 authority-form 41-42 3984 BWS 24 3985 chunk 35 3986 chunk-data 35 3987 chunk-ext 35-36 3988 chunk-ext-name 36 3989 chunk-ext-val 36 3990 chunk-size 35 3991 chunked-body 35-36 3992 comment 27 3993 Connection 51 3994 connection-option 51 3995 Content-Length 30 3996 CR 6 3997 CRLF 6 3998 ctext 27 3999 CTL 6 4000 DIGIT 6 4001 DQUOTE 6 4002 field-content 22 4003 field-name 22, 39 4004 field-value 22 4005 field-vchar 22 4006 fragment 16 4007 header-field 22, 36 4008 HEXDIG 6 4009 Host 43 4010 HTAB 6 4011 HTTP-message 19 4012 HTTP-name 13 4013 http-URI 16 4014 HTTP-version 13 4015 https-URI 18 4016 last-chunk 35 4017 LF 6 4018 message-body 27 4019 method 21 4020 obs-fold 22 4021 obs-text 27 4022 OCTET 6 4023 origin-form 41 4024 OWS 24 4025 partial-URI 16 4026 port 16 4027 protocol-name 47 4028 protocol-version 47 4029 pseudonym 47 4030 qdtext 27 4031 query 16 4032 quoted-pair 27 4033 quoted-string 27 4034 rank 38 4035 reason-phrase 22 4036 received-by 47 4037 received-protocol 47 4038 request-line 21 4039 request-target 41 4040 RWS 24 4041 scheme 16 4042 segment 16 4043 SP 6 4044 start-line 20 4045 status-code 22 4046 status-line 22 4047 t-codings 38 4048 t-ranking 38 4049 tchar 27 4050 TE 38 4051 token 27 4052 Trailer 39 4053 trailer-part 35-36 4054 transfer-coding 35 4055 Transfer-Encoding 28 4056 transfer-extension 35 4057 transfer-parameter 35 4058 Upgrade 56 4059 uri-host 16 4060 URI-reference 16 4061 VCHAR 6 4062 Via 47 4063 gzip (Coding Format) 38 4065 H 4066 header field 19 4067 header section 19 4068 headers 19 4069 Host header field 43 4070 http URI scheme 16 4071 https URI scheme 18 4073 I 4074 inbound 9 4075 interception proxy 11 4076 intermediary 9 4078 M 4079 Media Type 4080 application/http 62 4081 message/http 61 4083 message 7 4084 message/http Media Type 61 4085 method 21 4087 N 4088 non-transforming proxy 48 4090 O 4091 origin server 7 4092 origin-form (of request-target) 41 4093 outbound 9 4095 P 4096 phishing 66 4097 proxy 10 4099 R 4100 recipient 7 4101 request 7 4102 request-target 21 4103 resource 16 4104 response 7 4105 reverse proxy 10 4107 S 4108 sender 7 4109 server 7 4110 spider 7 4112 T 4113 target resource 40 4114 target URI 40 4115 TE header field 38 4116 Trailer header field 39 4117 Transfer-Encoding header field 28 4118 transforming proxy 48 4119 transparent proxy 11 4120 tunnel 10 4122 U 4123 Upgrade header field 56 4124 upstream 9 4125 URI scheme 4126 http 16 4127 https 18 4128 user agent 7 4130 V 4131 Via header field 47 4133 Authors' Addresses 4135 Roy T. Fielding (editor) 4136 Adobe Systems Incorporated 4137 345 Park Ave 4138 San Jose, CA 95110 4139 USA 4141 EMail: fielding@gbiv.com 4142 URI: http://roy.gbiv.com/ 4144 Julian F. Reschke (editor) 4145 greenbytes GmbH 4146 Hafenweg 16 4147 Muenster, NW 48155 4148 Germany 4150 EMail: julian.reschke@greenbytes.de 4151 URI: http://greenbytes.de/tech/webdav/