idnits 2.17.1 draft-ietf-httpbis-p1-messaging-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 30. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 3365. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 3376. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 3383. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 3389. 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 29, 2008) is 5718 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO-8859-1' == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p2-semantics-04 == Outdated reference: A later version (-20) exists of draft-ietf-httpbis-p3-payload-04 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p5-range-04 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p6-cache-04 ** Obsolete normative reference: RFC 2396 (Obsoleted by RFC 3986) ** Obsolete normative reference: RFC 822 (Obsoleted by RFC 2822) -- Possible downref: Non-RFC (?) normative reference: ref. 'USASCII' -- Obsolete informational reference (is this intentional?): RFC 1305 (Obsoleted by RFC 5905) -- Obsolete informational reference (is this intentional?): RFC 1738 (Obsoleted by RFC 4248, RFC 4266) -- Obsolete informational reference (is this intentional?): RFC 1808 (Obsoleted by RFC 3986) -- Obsolete informational reference (is this intentional?): RFC 2068 (Obsoleted by RFC 2616) -- Obsolete informational reference (is this intentional?): RFC 2109 (Obsoleted by RFC 2965) -- 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 2821 (Obsoleted by RFC 5321) -- Obsolete informational reference (is this intentional?): RFC 2822 (Obsoleted by RFC 5322) -- Obsolete informational reference (is this intentional?): RFC 2965 (Obsoleted by RFC 6265) -- Obsolete informational reference (is this intentional?): RFC 4288 (Obsoleted by RFC 6838) -- Obsolete informational reference (is this intentional?): RFC 4395 (Obsoleted by RFC 7595) -- Duplicate reference: RFC822, mentioned in 'RFC822', was also mentioned in 'RFC822ABNF'. -- Obsolete informational reference (is this intentional?): RFC 822 (Obsoleted by RFC 2822) Summary: 3 errors (**), 0 flaws (~~), 5 warnings (==), 25 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Fielding, Ed. 3 Internet-Draft Day Software 4 Obsoletes: 2616 (if approved) J. Gettys 5 Intended status: Standards Track One Laptop per Child 6 Expires: March 2, 2009 J. Mogul 7 HP 8 H. Frystyk 9 Microsoft 10 L. Masinter 11 Adobe Systems 12 P. Leach 13 Microsoft 14 T. Berners-Lee 15 W3C/MIT 16 Y. Lafon, Ed. 17 W3C 18 J. Reschke, Ed. 19 greenbytes 20 August 29, 2008 22 HTTP/1.1, part 1: URIs, Connections, and Message Parsing 23 draft-ietf-httpbis-p1-messaging-04 25 Status of this Memo 27 By submitting this Internet-Draft, each author represents that any 28 applicable patent or other IPR claims of which he or she is aware 29 have been or will be disclosed, and any of which he or she becomes 30 aware will be disclosed, in accordance with Section 6 of BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF), its areas, and its working groups. Note that 34 other groups may also distribute working documents as Internet- 35 Drafts. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 The list of current Internet-Drafts can be accessed at 43 http://www.ietf.org/ietf/1id-abstracts.txt. 45 The list of Internet-Draft Shadow Directories can be accessed at 46 http://www.ietf.org/shadow.html. 48 This Internet-Draft will expire on March 2, 2009. 50 Abstract 52 The Hypertext Transfer Protocol (HTTP) is an application-level 53 protocol for distributed, collaborative, hypermedia information 54 systems. HTTP has been in use by the World Wide Web global 55 information initiative since 1990. This document is Part 1 of the 56 seven-part specification that defines the protocol referred to as 57 "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 1 provides 58 an overview of HTTP and its associated terminology, defines the 59 "http" and "https" Uniform Resource Identifier (URI) schemes, defines 60 the generic message syntax and parsing requirements for HTTP message 61 frames, and describes general security concerns for implementations. 63 Editorial Note (To be removed by RFC Editor) 65 Discussion of this draft should take place on the HTTPBIS working 66 group mailing list (ietf-http-wg@w3.org). The current issues list is 67 at and related 68 documents (including fancy diffs) can be found at 69 . 71 The changes in this draft are summarized in Appendix D.4. 73 Table of Contents 75 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 76 1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 5 77 1.2. Requirements . . . . . . . . . . . . . . . . . . . . . . . 6 78 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 79 1.4. Overall Operation . . . . . . . . . . . . . . . . . . . . 9 80 2. Notational Conventions and Generic Grammar . . . . . . . . . . 11 81 2.1. Augmented BNF . . . . . . . . . . . . . . . . . . . . . . 11 82 2.2. Basic Rules . . . . . . . . . . . . . . . . . . . . . . . 13 83 2.3. ABNF Rules defined in other Parts of the Specification . . 16 84 3. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 16 85 3.1. HTTP Version . . . . . . . . . . . . . . . . . . . . . . . 16 86 3.2. Uniform Resource Identifiers . . . . . . . . . . . . . . . 17 87 3.2.1. General Syntax . . . . . . . . . . . . . . . . . . . . 17 88 3.2.2. http URL . . . . . . . . . . . . . . . . . . . . . . . 18 89 3.2.3. URI Comparison . . . . . . . . . . . . . . . . . . . . 19 90 3.3. Date/Time Formats . . . . . . . . . . . . . . . . . . . . 19 91 3.3.1. Full Date . . . . . . . . . . . . . . . . . . . . . . 19 92 3.4. Transfer Codings . . . . . . . . . . . . . . . . . . . . . 21 93 3.4.1. Chunked Transfer Coding . . . . . . . . . . . . . . . 22 94 3.5. Product Tokens . . . . . . . . . . . . . . . . . . . . . . 24 95 4. HTTP Message . . . . . . . . . . . . . . . . . . . . . . . . . 24 96 4.1. Message Types . . . . . . . . . . . . . . . . . . . . . . 24 97 4.2. Message Headers . . . . . . . . . . . . . . . . . . . . . 25 98 4.3. Message Body . . . . . . . . . . . . . . . . . . . . . . . 26 99 4.4. Message Length . . . . . . . . . . . . . . . . . . . . . . 27 100 4.5. General Header Fields . . . . . . . . . . . . . . . . . . 28 101 5. Request . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 102 5.1. Request-Line . . . . . . . . . . . . . . . . . . . . . . . 29 103 5.1.1. Method . . . . . . . . . . . . . . . . . . . . . . . . 29 104 5.1.2. Request-URI . . . . . . . . . . . . . . . . . . . . . 30 105 5.2. The Resource Identified by a Request . . . . . . . . . . . 31 106 6. Response . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 107 6.1. Status-Line . . . . . . . . . . . . . . . . . . . . . . . 32 108 6.1.1. Status Code and Reason Phrase . . . . . . . . . . . . 32 109 7. Connections . . . . . . . . . . . . . . . . . . . . . . . . . 33 110 7.1. Persistent Connections . . . . . . . . . . . . . . . . . . 33 111 7.1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . 33 112 7.1.2. Overall Operation . . . . . . . . . . . . . . . . . . 34 113 7.1.3. Proxy Servers . . . . . . . . . . . . . . . . . . . . 35 114 7.1.4. Practical Considerations . . . . . . . . . . . . . . . 35 115 7.2. Message Transmission Requirements . . . . . . . . . . . . 36 116 7.2.1. Persistent Connections and Flow Control . . . . . . . 37 117 7.2.2. Monitoring Connections for Error Status Messages . . . 37 118 7.2.3. Use of the 100 (Continue) Status . . . . . . . . . . . 37 119 7.2.4. Client Behavior if Server Prematurely Closes 120 Connection . . . . . . . . . . . . . . . . . . . . . . 39 122 8. Header Field Definitions . . . . . . . . . . . . . . . . . . . 40 123 8.1. Connection . . . . . . . . . . . . . . . . . . . . . . . . 40 124 8.2. Content-Length . . . . . . . . . . . . . . . . . . . . . . 41 125 8.3. Date . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 126 8.3.1. Clockless Origin Server Operation . . . . . . . . . . 43 127 8.4. Host . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 128 8.5. TE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 129 8.6. Trailer . . . . . . . . . . . . . . . . . . . . . . . . . 45 130 8.7. Transfer-Encoding . . . . . . . . . . . . . . . . . . . . 45 131 8.8. Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . 46 132 8.9. Via . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 133 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 48 134 9.1. Message Header Registration . . . . . . . . . . . . . . . 48 135 9.2. URI Scheme Registration . . . . . . . . . . . . . . . . . 49 136 9.3. Internet Media Type Registrations . . . . . . . . . . . . 49 137 9.3.1. Internet Media Type message/http . . . . . . . . . . . 49 138 9.3.2. Internet Media Type application/http . . . . . . . . . 50 139 10. Security Considerations . . . . . . . . . . . . . . . . . . . 51 140 10.1. Personal Information . . . . . . . . . . . . . . . . . . . 52 141 10.2. Abuse of Server Log Information . . . . . . . . . . . . . 52 142 10.3. Attacks Based On File and Path Names . . . . . . . . . . . 52 143 10.4. DNS Spoofing . . . . . . . . . . . . . . . . . . . . . . . 52 144 10.5. Proxies and Caching . . . . . . . . . . . . . . . . . . . 53 145 10.6. Denial of Service Attacks on Proxies . . . . . . . . . . . 54 146 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 54 147 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 55 148 12.1. Normative References . . . . . . . . . . . . . . . . . . . 55 149 12.2. Informative References . . . . . . . . . . . . . . . . . . 56 150 Appendix A. Tolerant Applications . . . . . . . . . . . . . . . . 59 151 Appendix B. Conversion of Date Formats . . . . . . . . . . . . . 59 152 Appendix C. Compatibility with Previous Versions . . . . . . . . 60 153 C.1. Changes from HTTP/1.0 . . . . . . . . . . . . . . . . . . 60 154 C.1.1. Changes to Simplify Multi-homed Web Servers and 155 Conserve IP Addresses . . . . . . . . . . . . . . . . 60 156 C.2. Compatibility with HTTP/1.0 Persistent Connections . . . . 61 157 C.3. Changes from RFC 2068 . . . . . . . . . . . . . . . . . . 62 158 C.4. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 62 159 Appendix D. Change Log (to be removed by RFC Editor before 160 publication) . . . . . . . . . . . . . . . . . . . . 63 161 D.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 63 162 D.2. Since draft-ietf-httpbis-p1-messaging-00 . . . . . . . . . 63 163 D.3. Since draft-ietf-httpbis-p1-messaging-01 . . . . . . . . . 64 164 D.4. Since draft-ietf-httpbis-p1-messaging-02 . . . . . . . . . 65 165 D.5. Since draft-ietf-httpbis-p1-messaging-03 . . . . . . . . . 66 166 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 167 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 70 168 Intellectual Property and Copyright Statements . . . . . . . . . . 73 170 1. Introduction 172 The Hypertext Transfer Protocol (HTTP) is an application-level 173 protocol for distributed, collaborative, hypermedia information 174 systems. HTTP has been in use by the World-Wide Web global 175 information initiative since 1990. The first version of HTTP, 176 commonly referred to as HTTP/0.9, was a simple protocol for raw data 177 transfer across the Internet with only a single method and no 178 metadata. HTTP/1.0, as defined by [RFC1945], improved the protocol 179 by allowing messages to be in the format of MIME-like messages, 180 containing metadata about the data transferred and modifiers on the 181 request/response semantics. However, HTTP/1.0 did not sufficiently 182 take into consideration the effects of hierarchical proxies, caching, 183 the need for persistent connections, or name-based virtual hosts. In 184 addition, the proliferation of incompletely-implemented applications 185 calling themselves "HTTP/1.0" necessitated a protocol version change 186 in order for two communicating applications to determine each other's 187 true capabilities. 189 This document is Part 1 of the seven-part specification that defines 190 the protocol referred to as "HTTP/1.1", obsoleting [RFC2616]. 191 HTTP/1.1 remains compatible with HTTP/1.0 by including more stringent 192 requirements that enable reliable implementations and adding only 193 those new features that will either be safely ignored by an HTTP/1.0 194 recipient or only sent when communicating with a party advertising 195 compliance with HTTP/1.1. Part 1 defines those aspects of HTTP/1.1 196 related to overall network operation, message framing, interaction 197 with transport protocols, and URI schemes. 199 This document is currently disorganized in order to minimize the 200 changes between drafts and enable reviewers to see the smaller errata 201 changes. The next draft will reorganize the sections to better 202 reflect the content. In particular, the sections will be organized 203 according to the typical process of deciding when to use HTTP (URI 204 schemes), overall network operation, connection management, message 205 framing, and generic message parsing. The current mess reflects how 206 widely dispersed these topics and associated requirements had become 207 in [RFC2616]. 209 1.1. Purpose 211 Practical information systems require more functionality than simple 212 retrieval, including search, front-end update, and annotation. HTTP 213 allows an open-ended set of methods and headers that indicate the 214 purpose of a request [RFC2324]. It builds on the discipline of 215 reference provided by the Uniform Resource Identifier (URI) 216 [RFC1630], as a location (URL) [RFC1738] or name (URN) [RFC1737], for 217 indicating the resource to which a method is to be applied. Messages 218 are passed in a format similar to that used by Internet mail 219 [RFC2822] as defined by the Multipurpose Internet Mail Extensions 220 (MIME) [RFC2045]. 222 HTTP is also used as a generic protocol for communication between 223 user agents and proxies/gateways to other Internet systems, including 224 those supported by the SMTP [RFC2821], NNTP [RFC3977], FTP [RFC959], 225 Gopher [RFC1436], and WAIS [WAIS] protocols. In this way, HTTP 226 allows basic hypermedia access to resources available from diverse 227 applications. 229 1.2. Requirements 231 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 232 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 233 document are to be interpreted as described in [RFC2119]. 235 An implementation is not compliant if it fails to satisfy one or more 236 of the MUST or REQUIRED level requirements for the protocols it 237 implements. An implementation that satisfies all the MUST or 238 REQUIRED level and all the SHOULD level requirements for its 239 protocols is said to be "unconditionally compliant"; one that 240 satisfies all the MUST level requirements but not all the SHOULD 241 level requirements for its protocols is said to be "conditionally 242 compliant." 244 1.3. Terminology 246 This specification uses a number of terms to refer to the roles 247 played by participants in, and objects of, the HTTP communication. 249 connection 251 A transport layer virtual circuit established between two programs 252 for the purpose of communication. 254 message 256 The basic unit of HTTP communication, consisting of a structured 257 sequence of octets matching the syntax defined in Section 4 and 258 transmitted via the connection. 260 request 262 An HTTP request message, as defined in Section 5. 264 response 265 An HTTP response message, as defined in Section 6. 267 resource 269 A network data object or service that can be identified by a URI, 270 as defined in Section 3.2. Resources may be available in multiple 271 representations (e.g. multiple languages, data formats, size, and 272 resolutions) or vary in other ways. 274 entity 276 The information transferred as the payload of a request or 277 response. An entity consists of metainformation in the form of 278 entity-header fields and content in the form of an entity-body, as 279 described in Section 4 of [Part3]. 281 representation 283 An entity included with a response that is subject to content 284 negotiation, as described in Section 5 of [Part3]. There may 285 exist multiple representations associated with a particular 286 response status. 288 content negotiation 290 The mechanism for selecting the appropriate representation when 291 servicing a request, as described in Section 5 of [Part3]. The 292 representation of entities in any response can be negotiated 293 (including error responses). 295 variant 297 A resource may have one, or more than one, representation(s) 298 associated with it at any given instant. Each of these 299 representations is termed a `variant'. Use of the term `variant' 300 does not necessarily imply that the resource is subject to content 301 negotiation. 303 client 305 A program that establishes connections for the purpose of sending 306 requests. 308 user agent 310 The client which initiates a request. These are often browsers, 311 editors, spiders (web-traversing robots), or other end user tools. 313 server 315 An application program that accepts connections in order to 316 service requests by sending back responses. Any given program may 317 be capable of being both a client and a server; our use of these 318 terms refers only to the role being performed by the program for a 319 particular connection, rather than to the program's capabilities 320 in general. Likewise, any server may act as an origin server, 321 proxy, gateway, or tunnel, switching behavior based on the nature 322 of each request. 324 origin server 326 The server on which a given resource resides or is to be created. 328 proxy 330 An intermediary program which acts as both a server and a client 331 for the purpose of making requests on behalf of other clients. 332 Requests are serviced internally or by passing them on, with 333 possible translation, to other servers. A proxy MUST implement 334 both the client and server requirements of this specification. A 335 "transparent proxy" is a proxy that does not modify the request or 336 response beyond what is required for proxy authentication and 337 identification. A "non-transparent proxy" is a proxy that 338 modifies the request or response in order to provide some added 339 service to the user agent, such as group annotation services, 340 media type transformation, protocol reduction, or anonymity 341 filtering. Except where either transparent or non-transparent 342 behavior is explicitly stated, the HTTP proxy requirements apply 343 to both types of proxies. 345 gateway 347 A server which acts as an intermediary for some other server. 348 Unlike a proxy, a gateway receives requests as if it were the 349 origin server for the requested resource; the requesting client 350 may not be aware that it is communicating with a gateway. 352 tunnel 354 An intermediary program which is acting as a blind relay between 355 two connections. Once active, a tunnel is not considered a party 356 to the HTTP communication, though the tunnel may have been 357 initiated by an HTTP request. The tunnel ceases to exist when 358 both ends of the relayed connections are closed. 360 cache 361 A program's local store of response messages and the subsystem 362 that controls its message storage, retrieval, and deletion. A 363 cache stores cacheable responses in order to reduce the response 364 time and network bandwidth consumption on future, equivalent 365 requests. Any client or server may include a cache, though a 366 cache cannot be used by a server that is acting as a tunnel. 368 cacheable 370 A response is cacheable if a cache is allowed to store a copy of 371 the response message for use in answering subsequent requests. 372 The rules for determining the cacheability of HTTP responses are 373 defined in Section 1 of [Part6]. Even if a resource is cacheable, 374 there may be additional constraints on whether a cache can use the 375 cached copy for a particular request. 377 upstream/downstream 379 Upstream and downstream describe the flow of a message: all 380 messages flow from upstream to downstream. 382 inbound/outbound 384 Inbound and outbound refer to the request and response paths for 385 messages: "inbound" means "traveling toward the origin server", 386 and "outbound" means "traveling toward the user agent" 388 1.4. Overall Operation 390 HTTP is a request/response protocol. A client sends a request to the 391 server in the form of a request method, URI, and protocol version, 392 followed by a MIME-like message containing request modifiers, client 393 information, and possible body content over a connection with a 394 server. The server responds with a status line, including the 395 message's protocol version and a success or error code, followed by a 396 MIME-like message containing server information, entity 397 metainformation, and possible entity-body content. The relationship 398 between HTTP and MIME is described in Appendix A of [Part3]. 400 Most HTTP communication is initiated by a user agent and consists of 401 a request to be applied to a resource on some origin server. In the 402 simplest case, this may be accomplished via a single connection (v) 403 between the user agent (UA) and the origin server (O). 405 request chain ------------------------> 406 UA -------------------v------------------- O 407 <----------------------- response chain 409 A more complicated situation occurs when one or more intermediaries 410 are present in the request/response chain. There are three common 411 forms of intermediary: proxy, gateway, and tunnel. A proxy is a 412 forwarding agent, receiving requests for a URI in its absolute form, 413 rewriting all or part of the message, and forwarding the reformatted 414 request toward the server identified by the URI. A gateway is a 415 receiving agent, acting as a layer above some other server(s) and, if 416 necessary, translating the requests to the underlying server's 417 protocol. A tunnel acts as a relay point between two connections 418 without changing the messages; tunnels are used when the 419 communication needs to pass through an intermediary (such as a 420 firewall) even when the intermediary cannot understand the contents 421 of the messages. 423 request chain --------------------------------------> 424 UA -----v----- A -----v----- B -----v----- C -----v----- O 425 <------------------------------------- response chain 427 The figure above shows three intermediaries (A, B, and C) between the 428 user agent and origin server. A request or response message that 429 travels the whole chain will pass through four separate connections. 430 This distinction is important because some HTTP communication options 431 may apply only to the connection with the nearest, non-tunnel 432 neighbor, only to the end-points of the chain, or to all connections 433 along the chain. Although the diagram is linear, each participant 434 may be engaged in multiple, simultaneous communications. For 435 example, B may be receiving requests from many clients other than A, 436 and/or forwarding requests to servers other than C, at the same time 437 that it is handling A's request. 439 Any party to the communication which is not acting as a tunnel may 440 employ an internal cache for handling requests. The effect of a 441 cache is that the request/response chain is shortened if one of the 442 participants along the chain has a cached response applicable to that 443 request. The following illustrates the resulting chain if B has a 444 cached copy of an earlier response from O (via C) for a request which 445 has not been cached by UA or A. 447 request chain ----------> 448 UA -----v----- A -----v----- B - - - - - - C - - - - - - O 449 <--------- response chain 451 Not all responses are usefully cacheable, and some requests may 452 contain modifiers which place special requirements on cache behavior. 453 HTTP requirements for cache behavior and cacheable responses are 454 defined in Section 1 of [Part6]. 456 In fact, there are a wide variety of architectures and configurations 457 of caches and proxies currently being experimented with or deployed 458 across the World Wide Web. These systems include national hierarchies 459 of proxy caches to save transoceanic bandwidth, systems that 460 broadcast or multicast cache entries, organizations that distribute 461 subsets of cached data via CD-ROM, and so on. HTTP systems are used 462 in corporate intranets over high-bandwidth links, and for access via 463 PDAs with low-power radio links and intermittent connectivity. The 464 goal of HTTP/1.1 is to support the wide diversity of configurations 465 already deployed while introducing protocol constructs that meet the 466 needs of those who build web applications that require high 467 reliability and, failing that, at least reliable indications of 468 failure. 470 HTTP communication usually takes place over TCP/IP connections. The 471 default port is TCP 80 472 (), but other ports can 473 be used. This does not preclude HTTP from being implemented on top 474 of any other protocol on the Internet, or on other networks. HTTP 475 only presumes a reliable transport; any protocol that provides such 476 guarantees can be used; the mapping of the HTTP/1.1 request and 477 response structures onto the transport data units of the protocol in 478 question is outside the scope of this specification. 480 In HTTP/1.0, most implementations used a new connection for each 481 request/response exchange. In HTTP/1.1, a connection may be used for 482 one or more request/response exchanges, although connections may be 483 closed for a variety of reasons (see Section 7.1). 485 2. Notational Conventions and Generic Grammar 487 2.1. Augmented BNF 489 All of the mechanisms specified in this document are described in 490 both prose and an augmented Backus-Naur Form (BNF) similar to that 491 used by [RFC822ABNF]. Implementors will need to be familiar with the 492 notation in order to understand this specification. The augmented 493 BNF includes the following constructs: 495 name = definition 497 The name of a rule is simply the name itself (without any 498 enclosing "<" and ">") and is separated from its definition by the 499 equal "=" character. White space is only significant in that 500 indentation of continuation lines is used to indicate a rule 501 definition that spans more than one line. Certain basic rules are 502 in uppercase, such as SP, LWS, HTAB, CRLF, DIGIT, ALPHA, etc. 503 Angle brackets are used within definitions whenever their presence 504 will facilitate discerning the use of rule names. 506 "literal" 508 Quotation marks surround literal text. Unless stated otherwise, 509 the text is case-insensitive. 511 rule1 | rule2 513 Elements separated by a bar ("|") are alternatives, e.g., "yes | 514 no" will accept yes or no. 516 (rule1 rule2) 518 Elements enclosed in parentheses are treated as a single element. 519 Thus, "(elem (foo | bar) elem)" allows the token sequences "elem 520 foo elem" and "elem bar elem". 522 *rule 524 The character "*" preceding an element indicates repetition. The 525 full form is "*element" indicating at least and at most 526 occurrences of element. Default values are 0 and infinity so 527 that "*(element)" allows any number, including zero; "1*element" 528 requires at least one; and "1*2element" allows one or two. 530 [rule] 532 Square brackets enclose optional elements; "[foo bar]" is 533 equivalent to "*1(foo bar)". 535 N rule 537 Specific repetition: "(element)" is equivalent to 538 "*(element)"; that is, exactly occurrences of (element). 539 Thus 2DIGIT is a 2-digit number, and 3ALPHA is a string of three 540 alphabetic characters. 542 #rule 544 A construct "#" is defined, similar to "*", for defining lists of 545 elements. The full form is "#element" indicating at least 546 and at most elements, each separated by one or more commas 547 (",") and OPTIONAL linear white space (LWS). This makes the usual 548 form of lists very easy; a rule such as 550 ( *LWS element *( *LWS "," *LWS element )) 551 can be shown as 553 1#element 555 Wherever this construct is used, null elements are allowed, but do 556 not contribute to the count of elements present. That is, 557 "(element), , (element) " is permitted, but counts as only two 558 elements. Therefore, where at least one element is required, at 559 least one non-null element MUST be present. Default values are 0 560 and infinity so that "#element" allows any number, including zero; 561 "1#element" requires at least one; and "1#2element" allows one or 562 two. 564 ; comment 566 A semi-colon, set off some distance to the right of rule text, 567 starts a comment that continues to the end of line. This is a 568 simple way of including useful notes in parallel with the 569 specifications. 571 implied *LWS 573 The grammar described by this specification is word-based. Except 574 where noted otherwise, linear white space (LWS) can be included 575 between any two adjacent words (token or quoted-string), and 576 between adjacent words and separators, without changing the 577 interpretation of a field. At least one delimiter (LWS and/or 578 separators) MUST exist between any two tokens (for the definition 579 of "token" below), since they would otherwise be interpreted as a 580 single token. 582 2.2. Basic Rules 584 The following rules are used throughout this specification to 585 describe basic parsing constructs. The US-ASCII coded character set 586 is defined by ANSI X3.4-1986 [USASCII]. 588 OCTET = %x00-FF 589 ; any 8-bit sequence of data 590 CHAR = %x01-7F 591 ; any US-ASCII character, excluding NUL 592 ALPHA = %x41-5A | %x61-7A 593 ; A-Z | a-z 594 DIGIT = %x30-39 595 ; any US-ASCII digit "0".."9" 596 CTL = %x00-1F | %x7F 597 ; (octets 0 - 31) and DEL (127) 598 CR = %x0D 599 ; US-ASCII CR, carriage return (13) 600 LF = %x0A 601 ; US-ASCII LF, linefeed (10) 602 SP = %x20 603 ; US-ASCII SP, space (32) 604 HTAB = %x09 605 ; US-ASCII HT, horizontal-tab (9) 606 DQUOTE = %x22 607 ; US-ASCII double-quote mark (34) 609 HTTP/1.1 defines the sequence CR LF as the end-of-line marker for all 610 protocol elements except the entity-body (see Appendix A for tolerant 611 applications). The end-of-line marker within an entity-body is 612 defined by its associated media type, as described in Section 3.3 of 613 [Part3]. 615 CRLF = CR LF 617 HTTP/1.1 header field values can be folded onto multiple lines if the 618 continuation line begins with a space or horizontal tab. All linear 619 white space, including folding, has the same semantics as SP. A 620 recipient MAY replace any linear white space with a single SP before 621 interpreting the field value or forwarding the message downstream. 623 LWS = [CRLF] 1*( SP | HTAB ) 625 The TEXT rule is only used for descriptive field contents and values 626 that are not intended to be interpreted by the message parser. Words 627 of *TEXT MAY contain characters from character sets other than ISO- 628 8859-1 [ISO-8859-1] only when encoded according to the rules of 629 [RFC2047]. 631 TEXT = %x20-7E | %x80-FF | LWS 632 ; any OCTET except CTLs, but including LWS 634 A CRLF is allowed in the definition of TEXT only as part of a header 635 field continuation. It is expected that the folding LWS will be 636 replaced with a single SP before interpretation of the TEXT value. 638 Hexadecimal numeric characters are used in several protocol elements. 640 HEXDIG = "A" | "B" | "C" | "D" | "E" | "F" 641 | "a" | "b" | "c" | "d" | "e" | "f" | DIGIT 643 Many HTTP/1.1 header field values consist of words separated by LWS 644 or special characters. These special characters MUST be in a quoted 645 string to be used within a parameter value (as defined in 646 Section 3.4). 648 separators = "(" | ")" | "<" | ">" | "@" 649 | "," | ";" | ":" | "\" | DQUOTE 650 | "/" | "[" | "]" | "?" | "=" 651 | "{" | "}" | SP | HTAB 653 tchar = "!" | "#" | "$" | "%" | "&" | "'" | "*" 654 | "+" | "-" | "." | "^" | "_" | "`" | "|" | "~" 655 | DIGIT | ALPHA 656 ; any CHAR except CTLs or separators 658 token = 1*tchar 660 Comments can be included in some HTTP header fields by surrounding 661 the comment text with parentheses. Comments are only allowed in 662 fields containing "comment" as part of their field value definition. 663 In all other fields, parentheses are considered part of the field 664 value. 666 comment = "(" *( ctext | quoted-pair | comment ) ")" 667 ctext = 669 A string of text is parsed as a single word if it is quoted using 670 double-quote marks. 672 quoted-string = ( DQUOTE *(qdtext | quoted-pair ) DQUOTE ) 673 qdtext = 675 The backslash character ("\") MAY be used as a single-character 676 quoting mechanism only within quoted-string and comment constructs. 678 quoted-text = %x01-09 | 679 %x0B-0C | 680 %x0E-FF ; Characters excluding NUL, CR and LF 681 quoted-pair = "\" quoted-text 683 2.3. ABNF Rules defined in other Parts of the Specification 685 The ABNF rules below are defined in other parts: 687 request-header = 688 response-header = 690 accept-params = 691 entity-body = 692 entity-header = 694 Cache-Control = 695 Pragma = 696 Warning = 698 3. Protocol Parameters 700 3.1. HTTP Version 702 HTTP uses a "." numbering scheme to indicate versions 703 of the protocol. The protocol versioning policy is intended to allow 704 the sender to indicate the format of a message and its capacity for 705 understanding further HTTP communication, rather than the features 706 obtained via that communication. No change is made to the version 707 number for the addition of message components which do not affect 708 communication behavior or which only add to extensible field values. 709 The number is incremented when the changes made to the 710 protocol add features which do not change the general message parsing 711 algorithm, but which may add to the message semantics and imply 712 additional capabilities of the sender. The number is 713 incremented when the format of a message within the protocol is 714 changed. See [RFC2145] for a fuller explanation. 716 The version of an HTTP message is indicated by an HTTP-Version field 717 in the first line of the message. HTTP-Version is case-sensitive. 719 HTTP-Version = HTTP-Prot-Name "/" 1*DIGIT "." 1*DIGIT 720 HTTP-Prot-Name = %x48.54.54.50 ; "HTTP", case-sensitive 722 Note that the major and minor numbers MUST be treated as separate 723 integers and that each MAY be incremented higher than a single digit. 724 Thus, HTTP/2.4 is a lower version than HTTP/2.13, which in turn is 725 lower than HTTP/12.3. Leading zeros MUST be ignored by recipients 726 and MUST NOT be sent. 728 An application that sends a request or response message that includes 729 HTTP-Version of "HTTP/1.1" MUST be at least conditionally compliant 730 with this specification. Applications that are at least 731 conditionally compliant with this specification SHOULD use an HTTP- 732 Version of "HTTP/1.1" in their messages, and MUST do so for any 733 message that is not compatible with HTTP/1.0. For more details on 734 when to send specific HTTP-Version values, see [RFC2145]. 736 The HTTP version of an application is the highest HTTP version for 737 which the application is at least conditionally compliant. 739 Proxy and gateway applications need to be careful when forwarding 740 messages in protocol versions different from that of the application. 741 Since the protocol version indicates the protocol capability of the 742 sender, a proxy/gateway MUST NOT send a message with a version 743 indicator which is greater than its actual version. If a higher 744 version request is received, the proxy/gateway MUST either downgrade 745 the request version, or respond with an error, or switch to tunnel 746 behavior. 748 Due to interoperability problems with HTTP/1.0 proxies discovered 749 since the publication of [RFC2068], caching proxies MUST, gateways 750 MAY, and tunnels MUST NOT upgrade the request to the highest version 751 they support. The proxy/gateway's response to that request MUST be 752 in the same major version as the request. 754 Note: Converting between versions of HTTP may involve modification 755 of header fields required or forbidden by the versions involved. 757 3.2. Uniform Resource Identifiers 759 URIs have been known by many names: WWW addresses, Universal Document 760 Identifiers, Universal Resource Identifiers [RFC1630], and finally 761 the combination of Uniform Resource Locators (URL) [RFC1738] and 762 Names (URN) [RFC1737]. As far as HTTP is concerned, Uniform Resource 763 Identifiers are simply formatted strings which identify--via name, 764 location, or any other characteristic--a resource. 766 3.2.1. General Syntax 768 URIs in HTTP can be represented in absolute form or relative to some 769 known base URI [RFC1808], depending upon the context of their use. 770 The two forms are differentiated by the fact that absolute URIs 771 always begin with a scheme name followed by a colon. For definitive 772 information on URL syntax and semantics, see "Uniform Resource 773 Identifiers (URI): Generic Syntax and Semantics," [RFC2396] (which 774 replaces [RFC1738] and [RFC1808]). This specification adopts the 775 definitions of "URI-reference", "absoluteURI", "fragment", 776 "relativeURI", "port", "host", "abs_path", "query", and "authority" 777 from that specification: 779 absoluteURI = 780 authority = 781 fragment = 782 path-absolute = 783 port = 784 query = 785 relativeURI = 786 uri-host = 788 HTTP does not place any a priori limit on the length of a URI. 789 Servers MUST be able to handle the URI of any resource they serve, 790 and SHOULD be able to handle URIs of unbounded length if they provide 791 GET-based forms that could generate such URIs. A server SHOULD 792 return 414 (Request-URI Too Long) status if a URI is longer than the 793 server can handle (see Section 9.4.15 of [Part2]). 795 Note: Servers ought to be cautious about depending on URI lengths 796 above 255 bytes, because some older client or proxy 797 implementations might not properly support these lengths. 799 3.2.2. http URL 801 The "http" scheme is used to locate network resources via the HTTP 802 protocol. This section defines the scheme-specific syntax and 803 semantics for http URLs. 805 http-URL = "http:" "//" uri-host [ ":" port ] 806 [ path-absolute [ "?" query ]] 808 If the port is empty or not given, port 80 is assumed. The semantics 809 are that the identified resource is located at the server listening 810 for TCP connections on that port of that host, and the Request-URI 811 for the resource is path-absolute (Section 5.1.2). The use of IP 812 addresses in URLs SHOULD be avoided whenever possible (see 813 [RFC1900]). If the path-absolute is not present in the URL, it MUST 814 be given as "/" when used as a Request-URI for a resource 815 (Section 5.1.2). If a proxy receives a host name which is not a 816 fully qualified domain name, it MAY add its domain to the host name 817 it received. If a proxy receives a fully qualified domain name, the 818 proxy MUST NOT change the host name. 820 Note: the "https" scheme is defined in [RFC2818]. 822 3.2.3. URI Comparison 824 When comparing two URIs to decide if they match or not, a client 825 SHOULD use a case-sensitive octet-by-octet comparison of the entire 826 URIs, with these exceptions: 828 o A port that is empty or not given is equivalent to the default 829 port for that URI-reference; 831 o Comparisons of host names MUST be case-insensitive; 833 o Comparisons of scheme names MUST be case-insensitive; 835 o An empty path-absolute is equivalent to an path-absolute of "/". 837 Characters other than those in the "reserved" set (see [RFC2396], 838 Section 2.2) are equivalent to their ""%" HEXDIG HEXDIG" encoding. 840 For example, the following three URIs are equivalent: 842 http://example.com:80/~smith/home.html 843 http://EXAMPLE.com/%7Esmith/home.html 844 http://EXAMPLE.com:/%7esmith/home.html 846 3.3. Date/Time Formats 848 3.3.1. Full Date 850 HTTP applications have historically allowed three different formats 851 for the representation of date/time stamps: 853 Sun, 06 Nov 1994 08:49:37 GMT ; RFC 822, updated by RFC 1123 854 Sunday, 06-Nov-94 08:49:37 GMT ; obsolete RFC 850 format 855 Sun Nov 6 08:49:37 1994 ; ANSI C's asctime() format 857 The first format is preferred as an Internet standard and represents 858 a fixed-length subset of that defined by [RFC1123] (an update to 859 [RFC822]). The other formats are described here only for 860 compatibility with obsolete implementations. HTTP/1.1 clients and 861 servers that parse the date value MUST accept all three formats (for 862 compatibility with HTTP/1.0), though they MUST only generate the RFC 863 1123 format for representing HTTP-date values in header fields. See 864 Appendix A for further information. 866 Note: Recipients of date values are encouraged to be robust in 867 accepting date values that may have been sent by non-HTTP 868 applications, as is sometimes the case when retrieving or posting 869 messages via proxies/gateways to SMTP or NNTP. 871 All HTTP date/time stamps MUST be represented in Greenwich Mean Time 872 (GMT), without exception. For the purposes of HTTP, GMT is exactly 873 equal to UTC (Coordinated Universal Time). This is indicated in the 874 first two formats by the inclusion of "GMT" as the three-letter 875 abbreviation for time zone, and MUST be assumed when reading the 876 asctime format. HTTP-date is case sensitive and MUST NOT include 877 additional LWS beyond that specifically included as SP in the 878 grammar. 880 HTTP-date = rfc1123-date | obsolete-date 881 obsolete-date = rfc850-date | asctime-date 882 rfc1123-date = wkday "," SP date1 SP time SP GMT 883 rfc850-date = weekday "," SP date2 SP time SP GMT 884 asctime-date = wkday SP date3 SP time SP 4DIGIT 885 date1 = 2DIGIT SP month SP 4DIGIT 886 ; day month year (e.g., 02 Jun 1982) 887 date2 = 2DIGIT "-" month "-" 2DIGIT 888 ; day-month-year (e.g., 02-Jun-82) 889 date3 = month SP ( 2DIGIT | ( SP 1DIGIT )) 890 ; month day (e.g., Jun 2) 891 time = 2DIGIT ":" 2DIGIT ":" 2DIGIT 892 ; 00:00:00 - 23:59:59 893 wkday = s-Mon | s-Tue | s-Wed 894 | s-Thu | s-Fri | s-Sat | s-Sun 895 weekday = l-Mon | l-Tue | l-Wed 896 | l-Thu | l-Fri | l-Sat | l-Sun 897 month = s-Jan | s-Feb | s-Mar | s-Apr 898 | s-May | s-Jun | s-Jul | s-Aug 899 | s-Sep | s-Oct | s-Nov | s-Dec 901 GMT = %x47.4D.54 ; "GMT", case-sensitive 903 s-Mon = %x4D.6F.6E ; "Mon", case-sensitive 904 s-Tue = %x54.75.65 ; "Tue", case-sensitive 905 s-Wed = %x57.65.64 ; "Wed", case-sensitive 906 s-Thu = %x54.68.75 ; "Thu", case-sensitive 907 s-Fri = %x46.72.69 ; "Fri", case-sensitive 908 s-Sat = %x53.61.74 ; "Sat", case-sensitive 909 s-Sun = %x53.75.6E ; "Sun", case-sensitive 911 l-Mon = %x4D.6F.6E.64.61.79 ; "Monday", case-sensitive 912 l-Tue = %x54.75.65.73.64.61.79 ; "Tuesday", case-sensitive 913 l-Wed = %x57.65.64.6E.65.73.64.61.79 ; "Wednesday", case-sensitive 914 l-Thu = %x54.68.75.72.73.64.61.79 ; "Thursday", case-sensitive 915 l-Fri = %x46.72.69.64.61.79 ; "Friday", case-sensitive 916 l-Sat = %x53.61.74.75.72.64.61.79 ; "Saturday", case-sensitive 917 l-Sun = %x53.75.6E.64.61.79 ; "Sunday", case-sensitive 918 s-Jan = %x4A.61.6E ; "Jan", case-sensitive 919 s-Feb = %x46.65.62 ; "Feb", case-sensitive 920 s-Mar = %x4D.61.72 ; "Mar", case-sensitive 921 s-Apr = %x41.70.72 ; "Apr", case-sensitive 922 s-May = %x4D.61.79 ; "May", case-sensitive 923 s-Jun = %x4A.75.6E ; "Jun", case-sensitive 924 s-Jul = %x4A.75.6C ; "Jul", case-sensitive 925 s-Aug = %x41.75.67 ; "Aug", case-sensitive 926 s-Sep = %x53.65.70 ; "Sep", case-sensitive 927 s-Oct = %x4F.63.74 ; "Oct", case-sensitive 928 s-Nov = %x4E.6F.76 ; "Nov", case-sensitive 929 s-Dec = %x44.65.63 ; "Dec", case-sensitive 931 Note: HTTP requirements for the date/time stamp format apply only to 932 their usage within the protocol stream. Clients and servers are not 933 required to use these formats for user presentation, request logging, 934 etc. 936 3.4. Transfer Codings 938 Transfer-coding values are used to indicate an encoding 939 transformation that has been, can be, or may need to be applied to an 940 entity-body in order to ensure "safe transport" through the network. 941 This differs from a content coding in that the transfer-coding is a 942 property of the message, not of the original entity. 944 transfer-coding = "chunked" | transfer-extension 945 transfer-extension = token *( ";" parameter ) 947 Parameters are in the form of attribute/value pairs. 949 parameter = attribute "=" value 950 attribute = token 951 value = token | quoted-string 953 All transfer-coding values are case-insensitive. HTTP/1.1 uses 954 transfer-coding values in the TE header field (Section 8.5) and in 955 the Transfer-Encoding header field (Section 8.7). 957 Whenever a transfer-coding is applied to a message-body, the set of 958 transfer-codings MUST include "chunked", unless the message indicates 959 it is terminated by closing the connection. When the "chunked" 960 transfer-coding is used, it MUST be the last transfer-coding applied 961 to the message-body. The "chunked" transfer-coding MUST NOT be 962 applied more than once to a message-body. These rules allow the 963 recipient to determine the transfer-length of the message 964 (Section 4.4). 966 Transfer-codings are analogous to the Content-Transfer-Encoding 967 values of MIME [RFC2045], which were designed to enable safe 968 transport of binary data over a 7-bit transport service. However, 969 safe transport has a different focus for an 8bit-clean transfer 970 protocol. In HTTP, the only unsafe characteristic of message-bodies 971 is the difficulty in determining the exact body length (Section 4.4), 972 or the desire to encrypt data over a shared transport. 974 The Internet Assigned Numbers Authority (IANA) acts as a registry for 975 transfer-coding value tokens. Initially, the registry contains the 976 following tokens: "chunked" (Section 3.4.1), "gzip", "compress", and 977 "deflate" (Section 3.2 of [Part3]). 979 New transfer-coding value tokens SHOULD be registered in the same way 980 as new content-coding value tokens (Section 3.2 of [Part3]). 982 A server which receives an entity-body with a transfer-coding it does 983 not understand SHOULD return 501 (Not Implemented), and close the 984 connection. A server MUST NOT send transfer-codings to an HTTP/1.0 985 client. 987 3.4.1. Chunked Transfer Coding 989 The chunked encoding modifies the body of a message in order to 990 transfer it as a series of chunks, each with its own size indicator, 991 followed by an OPTIONAL trailer containing entity-header fields. 992 This allows dynamically produced content to be transferred along with 993 the information necessary for the recipient to verify that it has 994 received the full message. 996 Chunked-Body = *chunk 997 last-chunk 998 trailer-part 999 CRLF 1001 chunk = chunk-size [ chunk-extension ] CRLF 1002 chunk-data CRLF 1003 chunk-size = 1*HEXDIG 1004 last-chunk = 1*("0") [ chunk-extension ] CRLF 1006 chunk-extension= *( ";" chunk-ext-name [ "=" chunk-ext-val ] ) 1007 chunk-ext-name = token 1008 chunk-ext-val = token | quoted-string 1009 chunk-data = 1*OCTET ; a sequence of chunk-size octets 1010 trailer-part = *(entity-header CRLF) 1012 The chunk-size field is a string of hex digits indicating the size of 1013 the chunk-data in octets. The chunked encoding is ended by any chunk 1014 whose size is zero, followed by the trailer, which is terminated by 1015 an empty line. 1017 The trailer allows the sender to include additional HTTP header 1018 fields at the end of the message. The Trailer header field can be 1019 used to indicate which header fields are included in a trailer (see 1020 Section 8.6). 1022 A server using chunked transfer-coding in a response MUST NOT use the 1023 trailer for any header fields unless at least one of the following is 1024 true: 1026 1. the request included a TE header field that indicates "trailers" 1027 is acceptable in the transfer-coding of the response, as 1028 described in Section 8.5; or, 1030 2. the server is the origin server for the response, the trailer 1031 fields consist entirely of optional metadata, and the recipient 1032 could use the message (in a manner acceptable to the origin 1033 server) without receiving this metadata. In other words, the 1034 origin server is willing to accept the possibility that the 1035 trailer fields might be silently discarded along the path to the 1036 client. 1038 This requirement prevents an interoperability failure when the 1039 message is being received by an HTTP/1.1 (or later) proxy and 1040 forwarded to an HTTP/1.0 recipient. It avoids a situation where 1041 compliance with the protocol would have necessitated a possibly 1042 infinite buffer on the proxy. 1044 A process for decoding the "chunked" transfer-coding can be 1045 represented in pseudo-code as: 1047 length := 0 1048 read chunk-size, chunk-extension (if any) and CRLF 1049 while (chunk-size > 0) { 1050 read chunk-data and CRLF 1051 append chunk-data to entity-body 1052 length := length + chunk-size 1053 read chunk-size and CRLF 1054 } 1055 read entity-header 1056 while (entity-header not empty) { 1057 append entity-header to existing header fields 1058 read entity-header 1059 } 1060 Content-Length := length 1061 Remove "chunked" from Transfer-Encoding 1063 All HTTP/1.1 applications MUST be able to receive and decode the 1064 "chunked" transfer-coding, and MUST ignore chunk-extension extensions 1065 they do not understand. 1067 3.5. Product Tokens 1069 Product tokens are used to allow communicating applications to 1070 identify themselves by software name and version. Most fields using 1071 product tokens also allow sub-products which form a significant part 1072 of the application to be listed, separated by white space. By 1073 convention, the products are listed in order of their significance 1074 for identifying the application. 1076 product = token ["/" product-version] 1077 product-version = token 1079 Examples: 1081 User-Agent: CERN-LineMode/2.15 libwww/2.17b3 1082 Server: Apache/0.8.4 1084 Product tokens SHOULD be short and to the point. They MUST NOT be 1085 used for advertising or other non-essential information. Although 1086 any token character MAY appear in a product-version, this token 1087 SHOULD only be used for a version identifier (i.e., successive 1088 versions of the same product SHOULD only differ in the product- 1089 version portion of the product value). 1091 4. HTTP Message 1093 4.1. Message Types 1095 HTTP messages consist of requests from client to server and responses 1096 from server to client. 1098 HTTP-message = Request | Response ; HTTP/1.1 messages 1100 Request (Section 5) and Response (Section 6) messages use the generic 1101 message format of [RFC2822] for transferring entities (the payload of 1102 the message). Both types of message consist of a start-line, zero or 1103 more header fields (also known as "headers"), an empty line (i.e., a 1104 line with nothing preceding the CRLF) indicating the end of the 1105 header fields, and possibly a message-body. 1107 generic-message = start-line 1108 *(message-header CRLF) 1109 CRLF 1110 [ message-body ] 1111 start-line = Request-Line | Status-Line 1113 In the interest of robustness, servers SHOULD ignore any empty 1114 line(s) received where a Request-Line is expected. In other words, 1115 if the server is reading the protocol stream at the beginning of a 1116 message and receives a CRLF first, it should ignore the CRLF. 1118 Certain buggy HTTP/1.0 client implementations generate extra CRLF's 1119 after a POST request. To restate what is explicitly forbidden by the 1120 BNF, an HTTP/1.1 client MUST NOT preface or follow a request with an 1121 extra CRLF. 1123 4.2. Message Headers 1125 HTTP header fields, which include general-header (Section 4.5), 1126 request-header (Section 4 of [Part2]), response-header (Section 6 of 1127 [Part2]), and entity-header (Section 4.1 of [Part3]) fields, follow 1128 the same generic format as that given in Section 2.1 of [RFC2822]. 1129 Each header field consists of a name followed by a colon (":") and 1130 the field value. Field names are case-insensitive. The field value 1131 MAY be preceded by any amount of LWS, though a single SP is 1132 preferred. Header fields can be extended over multiple lines by 1133 preceding each extra line with at least one SP or HTAB. Applications 1134 ought to follow "common form", where one is known or indicated, when 1135 generating HTTP constructs, since there might exist some 1136 implementations that fail to accept anything beyond the common forms. 1138 message-header = field-name ":" [ field-value ] 1139 field-name = token 1140 field-value = *( field-content | LWS ) 1141 field-content = 1142 ; the OCTETs making up the field-value 1143 ; and consisting of either *TEXT or combinations 1144 ; of token, separators, and quoted-string 1146 The field-content does not include any leading or trailing LWS: 1147 linear white space occurring before the first non-whitespace 1148 character of the field-value or after the last non-whitespace 1149 character of the field-value. Such leading or trailing LWS MAY be 1150 removed without changing the semantics of the field value. Any LWS 1151 that occurs between field-content MAY be replaced with a single SP 1152 before interpreting the field value or forwarding the message 1153 downstream. 1155 The order in which header fields with differing field names are 1156 received is not significant. However, it is "good practice" to send 1157 general-header fields first, followed by request-header or response- 1158 header fields, and ending with the entity-header fields. 1160 Multiple message-header fields with the same field-name MAY be 1161 present in a message if and only if the entire field-value for that 1162 header field is defined as a comma-separated list [i.e., #(values)]. 1163 It MUST be possible to combine the multiple header fields into one 1164 "field-name: field-value" pair, without changing the semantics of the 1165 message, by appending each subsequent field-value to the first, each 1166 separated by a comma. The order in which header fields with the same 1167 field-name are received is therefore significant to the 1168 interpretation of the combined field value, and thus a proxy MUST NOT 1169 change the order of these field values when a message is forwarded. 1171 Note: the "Set-Cookie" header as implemented in practice (as 1172 opposed to how it is specified in [RFC2109]) can occur multiple 1173 times, but does not use the list syntax, and thus cannot be 1174 combined into a single line. (See Appendix A.2.3 of [Kri2001] for 1175 details.) Also note that the Set-Cookie2 header specified in 1176 [RFC2965] does not share this problem. 1178 4.3. Message Body 1180 The message-body (if any) of an HTTP message is used to carry the 1181 entity-body associated with the request or response. The message- 1182 body differs from the entity-body only when a transfer-coding has 1183 been applied, as indicated by the Transfer-Encoding header field 1184 (Section 8.7). 1186 message-body = entity-body 1187 | 1189 Transfer-Encoding MUST be used to indicate any transfer-codings 1190 applied by an application to ensure safe and proper transfer of the 1191 message. Transfer-Encoding is a property of the message, not of the 1192 entity, and thus MAY be added or removed by any application along the 1193 request/response chain. (However, Section 3.4 places restrictions on 1194 when certain transfer-codings may be used.) 1196 The rules for when a message-body is allowed in a message differ for 1197 requests and responses. 1199 The presence of a message-body in a request is signaled by the 1200 inclusion of a Content-Length or Transfer-Encoding header field in 1201 the request's message-headers. A message-body MUST NOT be included 1202 in a request if the specification of the request method (Section 3 of 1204 [Part2]) explicitly disallows an entity-body in requests. When a 1205 request message contains both a message-body of non-zero length and a 1206 method that does not define any semantics for that request message- 1207 body, then an origin server SHOULD either ignore the message-body or 1208 respond with an appropriate error message (e.g., 413). A proxy or 1209 gateway, when presented the same request, SHOULD either forward the 1210 request inbound with the message-body or ignore the message-body when 1211 determining a response. 1213 For response messages, whether or not a message-body is included with 1214 a message is dependent on both the request method and the response 1215 status code (Section 6.1.1). All responses to the HEAD request 1216 method MUST NOT include a message-body, even though the presence of 1217 entity-header fields might lead one to believe they do. All 1xx 1218 (informational), 204 (No Content), and 304 (Not Modified) responses 1219 MUST NOT include a message-body. All other responses do include a 1220 message-body, although it MAY be of zero length. 1222 4.4. Message Length 1224 The transfer-length of a message is the length of the message-body as 1225 it appears in the message; that is, after any transfer-codings have 1226 been applied. When a message-body is included with a message, the 1227 transfer-length of that body is determined by one of the following 1228 (in order of precedence): 1230 1. Any response message which "MUST NOT" include a message-body 1231 (such as the 1xx, 204, and 304 responses and any response to a 1232 HEAD request) is always terminated by the first empty line after 1233 the header fields, regardless of the entity-header fields present 1234 in the message. 1236 2. If a Transfer-Encoding header field (Section 8.7) is present and 1237 the "chunked" transfer-coding (Section 3.4) is used, the 1238 transfer-length is defined by the use of this transfer-coding. 1239 If a Transfer-Encoding header field is present and the "chunked" 1240 transfer-coding is not present, the transfer-length is defined by 1241 the sender closing the connection. 1243 3. If a Content-Length header field (Section 8.2) is present, its 1244 decimal value in OCTETs represents both the entity-length and the 1245 transfer-length. The Content-Length header field MUST NOT be 1246 sent if these two lengths are different (i.e., if a Transfer- 1247 Encoding header field is present). If a message is received with 1248 both a Transfer-Encoding header field and a Content-Length header 1249 field, the latter MUST be ignored. 1251 4. If the message uses the media type "multipart/byteranges", and 1252 the transfer-length is not otherwise specified, then this self- 1253 delimiting media type defines the transfer-length. This media 1254 type MUST NOT be used unless the sender knows that the recipient 1255 can parse it; the presence in a request of a Range header with 1256 multiple byte-range specifiers from a 1.1 client implies that the 1257 client can parse multipart/byteranges responses. 1259 A range header might be forwarded by a 1.0 proxy that does not 1260 understand multipart/byteranges; in this case the server MUST 1261 delimit the message using methods defined in items 1, 3 or 5 1262 of this section. 1264 5. By the server closing the connection. (Closing the connection 1265 cannot be used to indicate the end of a request body, since that 1266 would leave no possibility for the server to send back a 1267 response.) 1269 For compatibility with HTTP/1.0 applications, HTTP/1.1 requests 1270 containing a message-body MUST include a valid Content-Length header 1271 field unless the server is known to be HTTP/1.1 compliant. If a 1272 request contains a message-body and a Content-Length is not given, 1273 the server SHOULD respond with 400 (Bad Request) if it cannot 1274 determine the length of the message, or with 411 (Length Required) if 1275 it wishes to insist on receiving a valid Content-Length. 1277 All HTTP/1.1 applications that receive entities MUST accept the 1278 "chunked" transfer-coding (Section 3.4), thus allowing this mechanism 1279 to be used for messages when the message length cannot be determined 1280 in advance. 1282 Messages MUST NOT include both a Content-Length header field and a 1283 transfer-coding. If the message does include a transfer-coding, the 1284 Content-Length MUST be ignored. 1286 When a Content-Length is given in a message where a message-body is 1287 allowed, its field value MUST exactly match the number of OCTETs in 1288 the message-body. HTTP/1.1 user agents MUST notify the user when an 1289 invalid length is received and detected. 1291 4.5. General Header Fields 1293 There are a few header fields which have general applicability for 1294 both request and response messages, but which do not apply to the 1295 entity being transferred. These header fields apply only to the 1296 message being transmitted. 1298 general-header = Cache-Control ; [Part6], Section 16.2 1299 | Connection ; Section 8.1 1300 | Date ; Section 8.3 1301 | Pragma ; [Part6], Section 16.4 1302 | Trailer ; Section 8.6 1303 | Transfer-Encoding ; Section 8.7 1304 | Upgrade ; Section 8.8 1305 | Via ; Section 8.9 1306 | Warning ; [Part6], Section 16.6 1308 General-header field names can be extended reliably only in 1309 combination with a change in the protocol version. However, new or 1310 experimental header fields may be given the semantics of general 1311 header fields if all parties in the communication recognize them to 1312 be general-header fields. Unrecognized header fields are treated as 1313 entity-header fields. 1315 5. Request 1317 A request message from a client to a server includes, within the 1318 first line of that message, the method to be applied to the resource, 1319 the identifier of the resource, and the protocol version in use. 1321 Request = Request-Line ; Section 5.1 1322 *(( general-header ; Section 4.5 1323 | request-header ; [Part2], Section 4 1324 | entity-header ) CRLF) ; [Part3], Section 4.1 1325 CRLF 1326 [ message-body ] ; Section 4.3 1328 5.1. Request-Line 1330 The Request-Line begins with a method token, followed by the Request- 1331 URI and the protocol version, and ending with CRLF. The elements are 1332 separated by SP characters. No CR or LF is allowed except in the 1333 final CRLF sequence. 1335 Request-Line = Method SP Request-URI SP HTTP-Version CRLF 1337 5.1.1. Method 1339 The Method token indicates the method to be performed on the resource 1340 identified by the Request-URI. The method is case-sensitive. 1342 Method = token 1344 5.1.2. Request-URI 1346 The Request-URI is a Uniform Resource Identifier (Section 3.2) and 1347 identifies the resource upon which to apply the request. 1349 Request-URI = "*" 1350 | absoluteURI 1351 | ( path-absolute [ "?" query ] ) 1352 | authority 1354 The four options for Request-URI are dependent on the nature of the 1355 request. The asterisk "*" means that the request does not apply to a 1356 particular resource, but to the server itself, and is only allowed 1357 when the method used does not necessarily apply to a resource. One 1358 example would be 1360 OPTIONS * HTTP/1.1 1362 The absoluteURI form is REQUIRED when the request is being made to a 1363 proxy. The proxy is requested to forward the request or service it 1364 from a valid cache, and return the response. Note that the proxy MAY 1365 forward the request on to another proxy or directly to the server 1366 specified by the absoluteURI. In order to avoid request loops, a 1367 proxy MUST be able to recognize all of its server names, including 1368 any aliases, local variations, and the numeric IP address. An 1369 example Request-Line would be: 1371 GET http://www.example.org/pub/WWW/TheProject.html HTTP/1.1 1373 To allow for transition to absoluteURIs in all requests in future 1374 versions of HTTP, all HTTP/1.1 servers MUST accept the absoluteURI 1375 form in requests, even though HTTP/1.1 clients will only generate 1376 them in requests to proxies. 1378 The authority form is only used by the CONNECT method (Section 8.9 of 1379 [Part2]). 1381 The most common form of Request-URI is that used to identify a 1382 resource on an origin server or gateway. In this case the absolute 1383 path of the URI MUST be transmitted (see Section 3.2.1, path- 1384 absolute) as the Request-URI, and the network location of the URI 1385 (authority) MUST be transmitted in a Host header field. For example, 1386 a client wishing to retrieve the resource above directly from the 1387 origin server would create a TCP connection to port 80 of the host 1388 "www.example.org" and send the lines: 1390 GET /pub/WWW/TheProject.html HTTP/1.1 1391 Host: www.example.org 1393 followed by the remainder of the Request. Note that the absolute 1394 path cannot be empty; if none is present in the original URI, it MUST 1395 be given as "/" (the server root). 1397 The Request-URI is transmitted in the format specified in 1398 Section 3.2.1. If the Request-URI is encoded using the "% HEXDIG 1399 HEXDIG" encoding ([RFC2396], Section 2.4.1), the origin server MUST 1400 decode the Request-URI in order to properly interpret the request. 1401 Servers SHOULD respond to invalid Request-URIs with an appropriate 1402 status code. 1404 A transparent proxy MUST NOT rewrite the "path-absolute" part of the 1405 received Request-URI when forwarding it to the next inbound server, 1406 except as noted above to replace a null path-absolute with "/". 1408 Note: The "no rewrite" rule prevents the proxy from changing the 1409 meaning of the request when the origin server is improperly using 1410 a non-reserved URI character for a reserved purpose. Implementors 1411 should be aware that some pre-HTTP/1.1 proxies have been known to 1412 rewrite the Request-URI. 1414 5.2. The Resource Identified by a Request 1416 The exact resource identified by an Internet request is determined by 1417 examining both the Request-URI and the Host header field. 1419 An origin server that does not allow resources to differ by the 1420 requested host MAY ignore the Host header field value when 1421 determining the resource identified by an HTTP/1.1 request. (But see 1422 Appendix C.1.1 for other requirements on Host support in HTTP/1.1.) 1424 An origin server that does differentiate resources based on the host 1425 requested (sometimes referred to as virtual hosts or vanity host 1426 names) MUST use the following rules for determining the requested 1427 resource on an HTTP/1.1 request: 1429 1. If Request-URI is an absoluteURI, the host is part of the 1430 Request-URI. Any Host header field value in the request MUST be 1431 ignored. 1433 2. If the Request-URI is not an absoluteURI, and the request 1434 includes a Host header field, the host is determined by the Host 1435 header field value. 1437 3. If the host as determined by rule 1 or 2 is not a valid host on 1438 the server, the response MUST be a 400 (Bad Request) error 1439 message. 1441 Recipients of an HTTP/1.0 request that lacks a Host header field MAY 1442 attempt to use heuristics (e.g., examination of the URI path for 1443 something unique to a particular host) in order to determine what 1444 exact resource is being requested. 1446 6. Response 1448 After receiving and interpreting a request message, a server responds 1449 with an HTTP response message. 1451 Response = Status-Line ; Section 6.1 1452 *(( general-header ; Section 4.5 1453 | response-header ; [Part2], Section 6 1454 | entity-header ) CRLF) ; [Part3], Section 4.1 1455 CRLF 1456 [ message-body ] ; Section 4.3 1458 6.1. Status-Line 1460 The first line of a Response message is the Status-Line, consisting 1461 of the protocol version followed by a numeric status code and its 1462 associated textual phrase, with each element separated by SP 1463 characters. No CR or LF is allowed except in the final CRLF 1464 sequence. 1466 Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF 1468 6.1.1. Status Code and Reason Phrase 1470 The Status-Code element is a 3-digit integer result code of the 1471 attempt to understand and satisfy the request. These codes are fully 1472 defined in Section 9 of [Part2]. The Reason Phrase exists for the 1473 sole purpose of providing a textual description associated with the 1474 numeric status code, out of deference to earlier Internet application 1475 protocols that were more frequently used with interactive text 1476 clients. A client SHOULD ignore the content of the Reason Phrase. 1478 The first digit of the Status-Code defines the class of response. 1479 The last two digits do not have any categorization role. There are 5 1480 values for the first digit: 1482 o 1xx: Informational - Request received, continuing process 1484 o 2xx: Success - The action was successfully received, understood, 1485 and accepted 1487 o 3xx: Redirection - Further action must be taken in order to 1488 complete the request 1490 o 4xx: Client Error - The request contains bad syntax or cannot be 1491 fulfilled 1493 o 5xx: Server Error - The server failed to fulfill an apparently 1494 valid request 1496 Status-Code = 3DIGIT 1497 Reason-Phrase = * 1499 7. Connections 1501 7.1. Persistent Connections 1503 7.1.1. Purpose 1505 Prior to persistent connections, a separate TCP connection was 1506 established to fetch each URL, increasing the load on HTTP servers 1507 and causing congestion on the Internet. The use of inline images and 1508 other associated data often require a client to make multiple 1509 requests of the same server in a short amount of time. Analysis of 1510 these performance problems and results from a prototype 1511 implementation are available [Pad1995] [Spe]. Implementation 1512 experience and measurements of actual HTTP/1.1 (RFC 2068) 1513 implementations show good results [Nie1997]. Alternatives have also 1514 been explored, for example, T/TCP [Tou1998]. 1516 Persistent HTTP connections have a number of advantages: 1518 o By opening and closing fewer TCP connections, CPU time is saved in 1519 routers and hosts (clients, servers, proxies, gateways, tunnels, 1520 or caches), and memory used for TCP protocol control blocks can be 1521 saved in hosts. 1523 o HTTP requests and responses can be pipelined on a connection. 1524 Pipelining allows a client to make multiple requests without 1525 waiting for each response, allowing a single TCP connection to be 1526 used much more efficiently, with much lower elapsed time. 1528 o Network congestion is reduced by reducing the number of packets 1529 caused by TCP opens, and by allowing TCP sufficient time to 1530 determine the congestion state of the network. 1532 o Latency on subsequent requests is reduced since there is no time 1533 spent in TCP's connection opening handshake. 1535 o HTTP can evolve more gracefully, since errors can be reported 1536 without the penalty of closing the TCP connection. Clients using 1537 future versions of HTTP might optimistically try a new feature, 1538 but if communicating with an older server, retry with old 1539 semantics after an error is reported. 1541 HTTP implementations SHOULD implement persistent connections. 1543 7.1.2. Overall Operation 1545 A significant difference between HTTP/1.1 and earlier versions of 1546 HTTP is that persistent connections are the default behavior of any 1547 HTTP connection. That is, unless otherwise indicated, the client 1548 SHOULD assume that the server will maintain a persistent connection, 1549 even after error responses from the server. 1551 Persistent connections provide a mechanism by which a client and a 1552 server can signal the close of a TCP connection. This signaling 1553 takes place using the Connection header field (Section 8.1). Once a 1554 close has been signaled, the client MUST NOT send any more requests 1555 on that connection. 1557 7.1.2.1. Negotiation 1559 An HTTP/1.1 server MAY assume that a HTTP/1.1 client intends to 1560 maintain a persistent connection unless a Connection header including 1561 the connection-token "close" was sent in the request. If the server 1562 chooses to close the connection immediately after sending the 1563 response, it SHOULD send a Connection header including the 1564 connection-token close. 1566 An HTTP/1.1 client MAY expect a connection to remain open, but would 1567 decide to keep it open based on whether the response from a server 1568 contains a Connection header with the connection-token close. In 1569 case the client does not want to maintain a connection for more than 1570 that request, it SHOULD send a Connection header including the 1571 connection-token close. 1573 If either the client or the server sends the close token in the 1574 Connection header, that request becomes the last one for the 1575 connection. 1577 Clients and servers SHOULD NOT assume that a persistent connection is 1578 maintained for HTTP versions less than 1.1 unless it is explicitly 1579 signaled. See Appendix C.2 for more information on backward 1580 compatibility with HTTP/1.0 clients. 1582 In order to remain persistent, all messages on the connection MUST 1583 have a self-defined message length (i.e., one not defined by closure 1584 of the connection), as described in Section 4.4. 1586 7.1.2.2. Pipelining 1588 A client that supports persistent connections MAY "pipeline" its 1589 requests (i.e., send multiple requests without waiting for each 1590 response). A server MUST send its responses to those requests in the 1591 same order that the requests were received. 1593 Clients which assume persistent connections and pipeline immediately 1594 after connection establishment SHOULD be prepared to retry their 1595 connection if the first pipelined attempt fails. If a client does 1596 such a retry, it MUST NOT pipeline before it knows the connection is 1597 persistent. Clients MUST also be prepared to resend their requests 1598 if the server closes the connection before sending all of the 1599 corresponding responses. 1601 Clients SHOULD NOT pipeline requests using non-idempotent methods or 1602 non-idempotent sequences of methods (see Section 8.1.2 of [Part2]). 1603 Otherwise, a premature termination of the transport connection could 1604 lead to indeterminate results. A client wishing to send a non- 1605 idempotent request SHOULD wait to send that request until it has 1606 received the response status for the previous request. 1608 7.1.3. Proxy Servers 1610 It is especially important that proxies correctly implement the 1611 properties of the Connection header field as specified in 1612 Section 8.1. 1614 The proxy server MUST signal persistent connections separately with 1615 its clients and the origin servers (or other proxy servers) that it 1616 connects to. Each persistent connection applies to only one 1617 transport link. 1619 A proxy server MUST NOT establish a HTTP/1.1 persistent connection 1620 with an HTTP/1.0 client (but see [RFC2068] for information and 1621 discussion of the problems with the Keep-Alive header implemented by 1622 many HTTP/1.0 clients). 1624 7.1.4. Practical Considerations 1626 Servers will usually have some time-out value beyond which they will 1627 no longer maintain an inactive connection. Proxy servers might make 1628 this a higher value since it is likely that the client will be making 1629 more connections through the same server. The use of persistent 1630 connections places no requirements on the length (or existence) of 1631 this time-out for either the client or the server. 1633 When a client or server wishes to time-out it SHOULD issue a graceful 1634 close on the transport connection. Clients and servers SHOULD both 1635 constantly watch for the other side of the transport close, and 1636 respond to it as appropriate. If a client or server does not detect 1637 the other side's close promptly it could cause unnecessary resource 1638 drain on the network. 1640 A client, server, or proxy MAY close the transport connection at any 1641 time. For example, a client might have started to send a new request 1642 at the same time that the server has decided to close the "idle" 1643 connection. From the server's point of view, the connection is being 1644 closed while it was idle, but from the client's point of view, a 1645 request is in progress. 1647 This means that clients, servers, and proxies MUST be able to recover 1648 from asynchronous close events. Client software SHOULD reopen the 1649 transport connection and retransmit the aborted sequence of requests 1650 without user interaction so long as the request sequence is 1651 idempotent (see Section 8.1.2 of [Part2]). Non-idempotent methods or 1652 sequences MUST NOT be automatically retried, although user agents MAY 1653 offer a human operator the choice of retrying the request(s). 1654 Confirmation by user-agent software with semantic understanding of 1655 the application MAY substitute for user confirmation. The automatic 1656 retry SHOULD NOT be repeated if the second sequence of requests 1657 fails. 1659 Servers SHOULD always respond to at least one request per connection, 1660 if at all possible. Servers SHOULD NOT close a connection in the 1661 middle of transmitting a response, unless a network or client failure 1662 is suspected. 1664 Clients that use persistent connections SHOULD limit the number of 1665 simultaneous connections that they maintain to a given server. A 1666 single-user client SHOULD NOT maintain more than 2 connections with 1667 any server or proxy. A proxy SHOULD use up to 2*N connections to 1668 another server or proxy, where N is the number of simultaneously 1669 active users. These guidelines are intended to improve HTTP response 1670 times and avoid congestion. 1672 7.2. Message Transmission Requirements 1673 7.2.1. Persistent Connections and Flow Control 1675 HTTP/1.1 servers SHOULD maintain persistent connections and use TCP's 1676 flow control mechanisms to resolve temporary overloads, rather than 1677 terminating connections with the expectation that clients will retry. 1678 The latter technique can exacerbate network congestion. 1680 7.2.2. Monitoring Connections for Error Status Messages 1682 An HTTP/1.1 (or later) client sending a message-body SHOULD monitor 1683 the network connection for an error status while it is transmitting 1684 the request. If the client sees an error status, it SHOULD 1685 immediately cease transmitting the body. If the body is being sent 1686 using a "chunked" encoding (Section 3.4), a zero length chunk and 1687 empty trailer MAY be used to prematurely mark the end of the message. 1688 If the body was preceded by a Content-Length header, the client MUST 1689 close the connection. 1691 7.2.3. Use of the 100 (Continue) Status 1693 The purpose of the 100 (Continue) status (see Section 9.1.1 of 1694 [Part2]) is to allow a client that is sending a request message with 1695 a request body to determine if the origin server is willing to accept 1696 the request (based on the request headers) before the client sends 1697 the request body. In some cases, it might either be inappropriate or 1698 highly inefficient for the client to send the body if the server will 1699 reject the message without looking at the body. 1701 Requirements for HTTP/1.1 clients: 1703 o If a client will wait for a 100 (Continue) response before sending 1704 the request body, it MUST send an Expect request-header field 1705 (Section 10.2 of [Part2]) with the "100-continue" expectation. 1707 o A client MUST NOT send an Expect request-header field (Section 1708 10.2 of [Part2]) with the "100-continue" expectation if it does 1709 not intend to send a request body. 1711 Because of the presence of older implementations, the protocol allows 1712 ambiguous situations in which a client may send "Expect: 100- 1713 continue" without receiving either a 417 (Expectation Failed) status 1714 or a 100 (Continue) status. Therefore, when a client sends this 1715 header field to an origin server (possibly via a proxy) from which it 1716 has never seen a 100 (Continue) status, the client SHOULD NOT wait 1717 for an indefinite period before sending the request body. 1719 Requirements for HTTP/1.1 origin servers: 1721 o Upon receiving a request which includes an Expect request-header 1722 field with the "100-continue" expectation, an origin server MUST 1723 either respond with 100 (Continue) status and continue to read 1724 from the input stream, or respond with a final status code. The 1725 origin server MUST NOT wait for the request body before sending 1726 the 100 (Continue) response. If it responds with a final status 1727 code, it MAY close the transport connection or it MAY continue to 1728 read and discard the rest of the request. It MUST NOT perform the 1729 requested method if it returns a final status code. 1731 o An origin server SHOULD NOT send a 100 (Continue) response if the 1732 request message does not include an Expect request-header field 1733 with the "100-continue" expectation, and MUST NOT send a 100 1734 (Continue) response if such a request comes from an HTTP/1.0 (or 1735 earlier) client. There is an exception to this rule: for 1736 compatibility with [RFC2068], a server MAY send a 100 (Continue) 1737 status in response to an HTTP/1.1 PUT or POST request that does 1738 not include an Expect request-header field with the "100-continue" 1739 expectation. This exception, the purpose of which is to minimize 1740 any client processing delays associated with an undeclared wait 1741 for 100 (Continue) status, applies only to HTTP/1.1 requests, and 1742 not to requests with any other HTTP-version value. 1744 o An origin server MAY omit a 100 (Continue) response if it has 1745 already received some or all of the request body for the 1746 corresponding request. 1748 o An origin server that sends a 100 (Continue) response MUST 1749 ultimately send a final status code, once the request body is 1750 received and processed, unless it terminates the transport 1751 connection prematurely. 1753 o If an origin server receives a request that does not include an 1754 Expect request-header field with the "100-continue" expectation, 1755 the request includes a request body, and the server responds with 1756 a final status code before reading the entire request body from 1757 the transport connection, then the server SHOULD NOT close the 1758 transport connection until it has read the entire request, or 1759 until the client closes the connection. Otherwise, the client 1760 might not reliably receive the response message. However, this 1761 requirement is not be construed as preventing a server from 1762 defending itself against denial-of-service attacks, or from badly 1763 broken client implementations. 1765 Requirements for HTTP/1.1 proxies: 1767 o If a proxy receives a request that includes an Expect request- 1768 header field with the "100-continue" expectation, and the proxy 1769 either knows that the next-hop server complies with HTTP/1.1 or 1770 higher, or does not know the HTTP version of the next-hop server, 1771 it MUST forward the request, including the Expect header field. 1773 o If the proxy knows that the version of the next-hop server is 1774 HTTP/1.0 or lower, it MUST NOT forward the request, and it MUST 1775 respond with a 417 (Expectation Failed) status. 1777 o Proxies SHOULD maintain a cache recording the HTTP version numbers 1778 received from recently-referenced next-hop servers. 1780 o A proxy MUST NOT forward a 100 (Continue) response if the request 1781 message was received from an HTTP/1.0 (or earlier) client and did 1782 not include an Expect request-header field with the "100-continue" 1783 expectation. This requirement overrides the general rule for 1784 forwarding of 1xx responses (see Section 9.1 of [Part2]). 1786 7.2.4. Client Behavior if Server Prematurely Closes Connection 1788 If an HTTP/1.1 client sends a request which includes a request body, 1789 but which does not include an Expect request-header field with the 1790 "100-continue" expectation, and if the client is not directly 1791 connected to an HTTP/1.1 origin server, and if the client sees the 1792 connection close before receiving any status from the server, the 1793 client SHOULD retry the request. If the client does retry this 1794 request, it MAY use the following "binary exponential backoff" 1795 algorithm to be assured of obtaining a reliable response: 1797 1. Initiate a new connection to the server 1799 2. Transmit the request-headers 1801 3. Initialize a variable R to the estimated round-trip time to the 1802 server (e.g., based on the time it took to establish the 1803 connection), or to a constant value of 5 seconds if the round- 1804 trip time is not available. 1806 4. Compute T = R * (2**N), where N is the number of previous retries 1807 of this request. 1809 5. Wait either for an error response from the server, or for T 1810 seconds (whichever comes first) 1812 6. If no error response is received, after T seconds transmit the 1813 body of the request. 1815 7. If client sees that the connection is closed prematurely, repeat 1816 from step 1 until the request is accepted, an error response is 1817 received, or the user becomes impatient and terminates the retry 1818 process. 1820 If at any point an error status is received, the client 1822 o SHOULD NOT continue and 1824 o SHOULD close the connection if it has not completed sending the 1825 request message. 1827 8. Header Field Definitions 1829 This section defines the syntax and semantics of HTTP/1.1 header 1830 fields related to message framing and transport protocols. 1832 For entity-header fields, both sender and recipient refer to either 1833 the client or the server, depending on who sends and who receives the 1834 entity. 1836 8.1. Connection 1838 The Connection general-header field allows the sender to specify 1839 options that are desired for that particular connection and MUST NOT 1840 be communicated by proxies over further connections. 1842 The Connection header has the following grammar: 1844 Connection = "Connection" ":" 1#(connection-token) 1845 connection-token = token 1847 HTTP/1.1 proxies MUST parse the Connection header field before a 1848 message is forwarded and, for each connection-token in this field, 1849 remove any header field(s) from the message with the same name as the 1850 connection-token. Connection options are signaled by the presence of 1851 a connection-token in the Connection header field, not by any 1852 corresponding additional header field(s), since the additional header 1853 field may not be sent if there are no parameters associated with that 1854 connection option. 1856 Message headers listed in the Connection header MUST NOT include end- 1857 to-end headers, such as Cache-Control. 1859 HTTP/1.1 defines the "close" connection option for the sender to 1860 signal that the connection will be closed after completion of the 1861 response. For example, 1863 Connection: close 1865 in either the request or the response header fields indicates that 1866 the connection SHOULD NOT be considered `persistent' (Section 7.1) 1867 after the current request/response is complete. 1869 An HTTP/1.1 client that does not support persistent connections MUST 1870 include the "close" connection option in every request message. 1872 An HTTP/1.1 server that does not support persistent connections MUST 1873 include the "close" connection option in every response message that 1874 does not have a 1xx (informational) status code. 1876 A system receiving an HTTP/1.0 (or lower-version) message that 1877 includes a Connection header MUST, for each connection-token in this 1878 field, remove and ignore any header field(s) from the message with 1879 the same name as the connection-token. This protects against 1880 mistaken forwarding of such header fields by pre-HTTP/1.1 proxies. 1881 See Appendix C.2. 1883 8.2. Content-Length 1885 The Content-Length entity-header field indicates the size of the 1886 entity-body, in decimal number of OCTETs, sent to the recipient or, 1887 in the case of the HEAD method, the size of the entity-body that 1888 would have been sent had the request been a GET. 1890 Content-Length = "Content-Length" ":" 1*DIGIT 1892 An example is 1894 Content-Length: 3495 1896 Applications SHOULD use this field to indicate the transfer-length of 1897 the message-body, unless this is prohibited by the rules in 1898 Section 4.4. 1900 Any Content-Length greater than or equal to zero is a valid value. 1901 Section 4.4 describes how to determine the length of a message-body 1902 if a Content-Length is not given. 1904 Note that the meaning of this field is significantly different from 1905 the corresponding definition in MIME, where it is an optional field 1906 used within the "message/external-body" content-type. In HTTP, it 1907 SHOULD be sent whenever the message's length can be determined prior 1908 to being transferred, unless this is prohibited by the rules in 1909 Section 4.4. 1911 8.3. Date 1913 The Date general-header field represents the date and time at which 1914 the message was originated, having the same semantics as orig-date in 1915 Section 3.6.1 of [RFC2822]. The field value is an HTTP-date, as 1916 described in Section 3.3.1; it MUST be sent in rfc1123-date format. 1918 Date = "Date" ":" HTTP-date 1920 An example is 1922 Date: Tue, 15 Nov 1994 08:12:31 GMT 1924 Origin servers MUST include a Date header field in all responses, 1925 except in these cases: 1927 1. If the response status code is 100 (Continue) or 101 (Switching 1928 Protocols), the response MAY include a Date header field, at the 1929 server's option. 1931 2. If the response status code conveys a server error, e.g. 500 1932 (Internal Server Error) or 503 (Service Unavailable), and it is 1933 inconvenient or impossible to generate a valid Date. 1935 3. If the server does not have a clock that can provide a reasonable 1936 approximation of the current time, its responses MUST NOT include 1937 a Date header field. In this case, the rules in Section 8.3.1 1938 MUST be followed. 1940 A received message that does not have a Date header field MUST be 1941 assigned one by the recipient if the message will be cached by that 1942 recipient or gatewayed via a protocol which requires a Date. An HTTP 1943 implementation without a clock MUST NOT cache responses without 1944 revalidating them on every use. An HTTP cache, especially a shared 1945 cache, SHOULD use a mechanism, such as NTP [RFC1305], to synchronize 1946 its clock with a reliable external standard. 1948 Clients SHOULD only send a Date header field in messages that include 1949 an entity-body, as in the case of the PUT and POST requests, and even 1950 then it is optional. A client without a clock MUST NOT send a Date 1951 header field in a request. 1953 The HTTP-date sent in a Date header SHOULD NOT represent a date and 1954 time subsequent to the generation of the message. It SHOULD 1955 represent the best available approximation of the date and time of 1956 message generation, unless the implementation has no means of 1957 generating a reasonably accurate date and time. In theory, the date 1958 ought to represent the moment just before the entity is generated. 1960 In practice, the date can be generated at any time during the message 1961 origination without affecting its semantic value. 1963 8.3.1. Clockless Origin Server Operation 1965 Some origin server implementations might not have a clock available. 1966 An origin server without a clock MUST NOT assign Expires or Last- 1967 Modified values to a response, unless these values were associated 1968 with the resource by a system or user with a reliable clock. It MAY 1969 assign an Expires value that is known, at or before server 1970 configuration time, to be in the past (this allows "pre-expiration" 1971 of responses without storing separate Expires values for each 1972 resource). 1974 8.4. Host 1976 The Host request-header field specifies the Internet host and port 1977 number of the resource being requested, as obtained from the original 1978 URI given by the user or referring resource (generally an HTTP URL, 1979 as described in Section 3.2.2). The Host field value MUST represent 1980 the naming authority of the origin server or gateway given by the 1981 original URL. This allows the origin server or gateway to 1982 differentiate between internally-ambiguous URLs, such as the root "/" 1983 URL of a server for multiple host names on a single IP address. 1985 Host = "Host" ":" uri-host [ ":" port ] ; Section 3.2.2 1987 A "host" without any trailing port information implies the default 1988 port for the service requested (e.g., "80" for an HTTP URL). For 1989 example, a request on the origin server for 1990 would properly include: 1992 GET /pub/WWW/ HTTP/1.1 1993 Host: www.example.org 1995 A client MUST include a Host header field in all HTTP/1.1 request 1996 messages. If the requested URI does not include an Internet host 1997 name for the service being requested, then the Host header field MUST 1998 be given with an empty value. An HTTP/1.1 proxy MUST ensure that any 1999 request message it forwards does contain an appropriate Host header 2000 field that identifies the service being requested by the proxy. All 2001 Internet-based HTTP/1.1 servers MUST respond with a 400 (Bad Request) 2002 status code to any HTTP/1.1 request message which lacks a Host header 2003 field. 2005 See Sections 5.2 and C.1.1 for other requirements relating to Host. 2007 8.5. TE 2009 The TE request-header field indicates what extension transfer-codings 2010 it is willing to accept in the response and whether or not it is 2011 willing to accept trailer fields in a chunked transfer-coding. Its 2012 value may consist of the keyword "trailers" and/or a comma-separated 2013 list of extension transfer-coding names with optional accept 2014 parameters (as described in Section 3.4). 2016 TE = "TE" ":" #( t-codings ) 2017 t-codings = "trailers" | ( transfer-extension [ accept-params ] ) 2019 The presence of the keyword "trailers" indicates that the client is 2020 willing to accept trailer fields in a chunked transfer-coding, as 2021 defined in Section 3.4.1. This keyword is reserved for use with 2022 transfer-coding values even though it does not itself represent a 2023 transfer-coding. 2025 Examples of its use are: 2027 TE: deflate 2028 TE: 2029 TE: trailers, deflate;q=0.5 2031 The TE header field only applies to the immediate connection. 2032 Therefore, the keyword MUST be supplied within a Connection header 2033 field (Section 8.1) whenever TE is present in an HTTP/1.1 message. 2035 A server tests whether a transfer-coding is acceptable, according to 2036 a TE field, using these rules: 2038 1. The "chunked" transfer-coding is always acceptable. If the 2039 keyword "trailers" is listed, the client indicates that it is 2040 willing to accept trailer fields in the chunked response on 2041 behalf of itself and any downstream clients. The implication is 2042 that, if given, the client is stating that either all downstream 2043 clients are willing to accept trailer fields in the forwarded 2044 response, or that it will attempt to buffer the response on 2045 behalf of downstream recipients. 2047 Note: HTTP/1.1 does not define any means to limit the size of a 2048 chunked response such that a client can be assured of buffering 2049 the entire response. 2051 2. If the transfer-coding being tested is one of the transfer- 2052 codings listed in the TE field, then it is acceptable unless it 2053 is accompanied by a qvalue of 0. (As defined in Section 3.4 of 2054 [Part3], a qvalue of 0 means "not acceptable.") 2056 3. If multiple transfer-codings are acceptable, then the acceptable 2057 transfer-coding with the highest non-zero qvalue is preferred. 2058 The "chunked" transfer-coding always has a qvalue of 1. 2060 If the TE field-value is empty or if no TE field is present, the only 2061 transfer-coding is "chunked". A message with no transfer-coding is 2062 always acceptable. 2064 8.6. Trailer 2066 The Trailer general field value indicates that the given set of 2067 header fields is present in the trailer of a message encoded with 2068 chunked transfer-coding. 2070 Trailer = "Trailer" ":" 1#field-name 2072 An HTTP/1.1 message SHOULD include a Trailer header field in a 2073 message using chunked transfer-coding with a non-empty trailer. 2074 Doing so allows the recipient to know which header fields to expect 2075 in the trailer. 2077 If no Trailer header field is present, the trailer SHOULD NOT include 2078 any header fields. See Section 3.4.1 for restrictions on the use of 2079 trailer fields in a "chunked" transfer-coding. 2081 Message header fields listed in the Trailer header field MUST NOT 2082 include the following header fields: 2084 o Transfer-Encoding 2086 o Content-Length 2088 o Trailer 2090 8.7. Transfer-Encoding 2092 The Transfer-Encoding general-header field indicates what (if any) 2093 type of transformation has been applied to the message body in order 2094 to safely transfer it between the sender and the recipient. This 2095 differs from the content-coding in that the transfer-coding is a 2096 property of the message, not of the entity. 2098 Transfer-Encoding = "Transfer-Encoding" ":" 1#transfer-coding 2100 Transfer-codings are defined in Section 3.4. An example is: 2102 Transfer-Encoding: chunked 2104 If multiple encodings have been applied to an entity, the transfer- 2105 codings MUST be listed in the order in which they were applied. 2106 Additional information about the encoding parameters MAY be provided 2107 by other entity-header fields not defined by this specification. 2109 Many older HTTP/1.0 applications do not understand the Transfer- 2110 Encoding header. 2112 8.8. Upgrade 2114 The Upgrade general-header allows the client to specify what 2115 additional communication protocols it supports and would like to use 2116 if the server finds it appropriate to switch protocols. The server 2117 MUST use the Upgrade header field within a 101 (Switching Protocols) 2118 response to indicate which protocol(s) are being switched. 2120 Upgrade = "Upgrade" ":" 1#product 2122 For example, 2124 Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11 2126 The Upgrade header field is intended to provide a simple mechanism 2127 for transition from HTTP/1.1 to some other, incompatible protocol. 2128 It does so by allowing the client to advertise its desire to use 2129 another protocol, such as a later version of HTTP with a higher major 2130 version number, even though the current request has been made using 2131 HTTP/1.1. This eases the difficult transition between incompatible 2132 protocols by allowing the client to initiate a request in the more 2133 commonly supported protocol while indicating to the server that it 2134 would like to use a "better" protocol if available (where "better" is 2135 determined by the server, possibly according to the nature of the 2136 method and/or resource being requested). 2138 The Upgrade header field only applies to switching application-layer 2139 protocols upon the existing transport-layer connection. Upgrade 2140 cannot be used to insist on a protocol change; its acceptance and use 2141 by the server is optional. The capabilities and nature of the 2142 application-layer communication after the protocol change is entirely 2143 dependent upon the new protocol chosen, although the first action 2144 after changing the protocol MUST be a response to the initial HTTP 2145 request containing the Upgrade header field. 2147 The Upgrade header field only applies to the immediate connection. 2148 Therefore, the upgrade keyword MUST be supplied within a Connection 2149 header field (Section 8.1) whenever Upgrade is present in an HTTP/1.1 2150 message. 2152 The Upgrade header field cannot be used to indicate a switch to a 2153 protocol on a different connection. For that purpose, it is more 2154 appropriate to use a 301, 302, 303, or 305 redirection response. 2156 This specification only defines the protocol name "HTTP" for use by 2157 the family of Hypertext Transfer Protocols, as defined by the HTTP 2158 version rules of Section 3.1 and future updates to this 2159 specification. Any token can be used as a protocol name; however, it 2160 will only be useful if both the client and server associate the name 2161 with the same protocol. 2163 8.9. Via 2165 The Via general-header field MUST be used by gateways and proxies to 2166 indicate the intermediate protocols and recipients between the user 2167 agent and the server on requests, and between the origin server and 2168 the client on responses. It is analogous to the "Received" field 2169 defined in Section 3.6.7 of [RFC2822] and is intended to be used for 2170 tracking message forwards, avoiding request loops, and identifying 2171 the protocol capabilities of all senders along the request/response 2172 chain. 2174 Via = "Via" ":" 1#( received-protocol received-by [ comment ] ) 2175 received-protocol = [ protocol-name "/" ] protocol-version 2176 protocol-name = token 2177 protocol-version = token 2178 received-by = ( uri-host [ ":" port ] ) | pseudonym 2179 pseudonym = token 2181 The received-protocol indicates the protocol version of the message 2182 received by the server or client along each segment of the request/ 2183 response chain. The received-protocol version is appended to the Via 2184 field value when the message is forwarded so that information about 2185 the protocol capabilities of upstream applications remains visible to 2186 all recipients. 2188 The protocol-name is optional if and only if it would be "HTTP". The 2189 received-by field is normally the host and optional port number of a 2190 recipient server or client that subsequently forwarded the message. 2191 However, if the real host is considered to be sensitive information, 2192 it MAY be replaced by a pseudonym. If the port is not given, it MAY 2193 be assumed to be the default port of the received-protocol. 2195 Multiple Via field values represents each proxy or gateway that has 2196 forwarded the message. Each recipient MUST append its information 2197 such that the end result is ordered according to the sequence of 2198 forwarding applications. 2200 Comments MAY be used in the Via header field to identify the software 2201 of the recipient proxy or gateway, analogous to the User-Agent and 2202 Server header fields. However, all comments in the Via field are 2203 optional and MAY be removed by any recipient prior to forwarding the 2204 message. 2206 For example, a request message could be sent from an HTTP/1.0 user 2207 agent to an internal proxy code-named "fred", which uses HTTP/1.1 to 2208 forward the request to a public proxy at p.example.net, which 2209 completes the request by forwarding it to the origin server at 2210 www.example.com. The request received by www.example.com would then 2211 have the following Via header field: 2213 Via: 1.0 fred, 1.1 p.example.net (Apache/1.1) 2215 Proxies and gateways used as a portal through a network firewall 2216 SHOULD NOT, by default, forward the names and ports of hosts within 2217 the firewall region. This information SHOULD only be propagated if 2218 explicitly enabled. If not enabled, the received-by host of any host 2219 behind the firewall SHOULD be replaced by an appropriate pseudonym 2220 for that host. 2222 For organizations that have strong privacy requirements for hiding 2223 internal structures, a proxy MAY combine an ordered subsequence of 2224 Via header field entries with identical received-protocol values into 2225 a single such entry. For example, 2227 Via: 1.0 ricky, 1.1 ethel, 1.1 fred, 1.0 lucy 2229 could be collapsed to 2231 Via: 1.0 ricky, 1.1 mertz, 1.0 lucy 2233 Applications SHOULD NOT combine multiple entries unless they are all 2234 under the same organizational control and the hosts have already been 2235 replaced by pseudonyms. Applications MUST NOT combine entries which 2236 have different received-protocol values. 2238 9. IANA Considerations 2240 9.1. Message Header Registration 2242 The Message Header Registry located at should be 2244 updated with the permanent registrations below (see [RFC3864]): 2246 +-------------------+----------+----------+-------------+ 2247 | Header Field Name | Protocol | Status | Reference | 2248 +-------------------+----------+----------+-------------+ 2249 | Connection | http | standard | Section 8.1 | 2250 | Content-Length | http | standard | Section 8.2 | 2251 | Date | http | standard | Section 8.3 | 2252 | Host | http | standard | Section 8.4 | 2253 | TE | http | standard | Section 8.5 | 2254 | Trailer | http | standard | Section 8.6 | 2255 | Transfer-Encoding | http | standard | Section 8.7 | 2256 | Upgrade | http | standard | Section 8.8 | 2257 | Via | http | standard | Section 8.9 | 2258 +-------------------+----------+----------+-------------+ 2260 The change controller is: "IETF (iesg@ietf.org) - Internet 2261 Engineering Task Force". 2263 9.2. URI Scheme Registration 2265 The entry for the "http" URI Scheme in the registry located at 2266 should be updated 2267 to point to Section 3.2.2 of this document (see [RFC4395]). 2269 9.3. Internet Media Type Registrations 2271 This document serves as the specification for the Internet media 2272 types "message/http" and "application/http". The following is to be 2273 registered with IANA (see [RFC4288]). 2275 9.3.1. Internet Media Type message/http 2277 The message/http type can be used to enclose a single HTTP request or 2278 response message, provided that it obeys the MIME restrictions for 2279 all "message" types regarding line length and encodings. 2281 Type name: message 2283 Subtype name: http 2285 Required parameters: none 2287 Optional parameters: version, msgtype 2289 version: The HTTP-Version number of the enclosed message (e.g., 2290 "1.1"). If not present, the version can be determined from the 2291 first line of the body. 2293 msgtype: The message type -- "request" or "response". If not 2294 present, the type can be determined from the first line of the 2295 body. 2297 Encoding considerations: only "7bit", "8bit", or "binary" are 2298 permitted 2300 Security considerations: none 2302 Interoperability considerations: none 2304 Published specification: This specification (see Section 9.3.1). 2306 Applications that use this media type: 2308 Additional information: 2310 Magic number(s): none 2312 File extension(s): none 2314 Macintosh file type code(s): none 2316 Person and email address to contact for further information: See 2317 Authors Section. 2319 Intended usage: COMMON 2321 Restrictions on usage: none 2323 Author/Change controller: IESG 2325 9.3.2. Internet Media Type application/http 2327 The application/http type can be used to enclose a pipeline of one or 2328 more HTTP request or response messages (not intermixed). 2330 Type name: application 2332 Subtype name: http 2334 Required parameters: none 2336 Optional parameters: version, msgtype 2337 version: The HTTP-Version number of the enclosed messages (e.g., 2338 "1.1"). If not present, the version can be determined from the 2339 first line of the body. 2341 msgtype: The message type -- "request" or "response". If not 2342 present, the type can be determined from the first line of the 2343 body. 2345 Encoding considerations: HTTP messages enclosed by this type are in 2346 "binary" format; use of an appropriate Content-Transfer-Encoding 2347 is required when transmitted via E-mail. 2349 Security considerations: none 2351 Interoperability considerations: none 2353 Published specification: This specification (see Section 9.3.2). 2355 Applications that use this media type: 2357 Additional information: 2359 Magic number(s): none 2361 File extension(s): none 2363 Macintosh file type code(s): none 2365 Person and email address to contact for further information: See 2366 Authors Section. 2368 Intended usage: COMMON 2370 Restrictions on usage: none 2372 Author/Change controller: IESG 2374 10. Security Considerations 2376 This section is meant to inform application developers, information 2377 providers, and users of the security limitations in HTTP/1.1 as 2378 described by this document. The discussion does not include 2379 definitive solutions to the problems revealed, though it does make 2380 some suggestions for reducing security risks. 2382 10.1. Personal Information 2384 HTTP clients are often privy to large amounts of personal information 2385 (e.g. the user's name, location, mail address, passwords, encryption 2386 keys, etc.), and SHOULD be very careful to prevent unintentional 2387 leakage of this information. We very strongly recommend that a 2388 convenient interface be provided for the user to control 2389 dissemination of such information, and that designers and 2390 implementors be particularly careful in this area. History shows 2391 that errors in this area often create serious security and/or privacy 2392 problems and generate highly adverse publicity for the implementor's 2393 company. 2395 10.2. Abuse of Server Log Information 2397 A server is in the position to save personal data about a user's 2398 requests which might identify their reading patterns or subjects of 2399 interest. This information is clearly confidential in nature and its 2400 handling can be constrained by law in certain countries. People 2401 using HTTP to provide data are responsible for ensuring that such 2402 material is not distributed without the permission of any individuals 2403 that are identifiable by the published results. 2405 10.3. Attacks Based On File and Path Names 2407 Implementations of HTTP origin servers SHOULD be careful to restrict 2408 the documents returned by HTTP requests to be only those that were 2409 intended by the server administrators. If an HTTP server translates 2410 HTTP URIs directly into file system calls, the server MUST take 2411 special care not to serve files that were not intended to be 2412 delivered to HTTP clients. For example, UNIX, Microsoft Windows, and 2413 other operating systems use ".." as a path component to indicate a 2414 directory level above the current one. On such a system, an HTTP 2415 server MUST disallow any such construct in the Request-URI if it 2416 would otherwise allow access to a resource outside those intended to 2417 be accessible via the HTTP server. Similarly, files intended for 2418 reference only internally to the server (such as access control 2419 files, configuration files, and script code) MUST be protected from 2420 inappropriate retrieval, since they might contain sensitive 2421 information. Experience has shown that minor bugs in such HTTP 2422 server implementations have turned into security risks. 2424 10.4. DNS Spoofing 2426 Clients using HTTP rely heavily on the Domain Name Service, and are 2427 thus generally prone to security attacks based on the deliberate mis- 2428 association of IP addresses and DNS names. Clients need to be 2429 cautious in assuming the continuing validity of an IP number/DNS name 2430 association. 2432 In particular, HTTP clients SHOULD rely on their name resolver for 2433 confirmation of an IP number/DNS name association, rather than 2434 caching the result of previous host name lookups. Many platforms 2435 already can cache host name lookups locally when appropriate, and 2436 they SHOULD be configured to do so. It is proper for these lookups 2437 to be cached, however, only when the TTL (Time To Live) information 2438 reported by the name server makes it likely that the cached 2439 information will remain useful. 2441 If HTTP clients cache the results of host name lookups in order to 2442 achieve a performance improvement, they MUST observe the TTL 2443 information reported by DNS. 2445 If HTTP clients do not observe this rule, they could be spoofed when 2446 a previously-accessed server's IP address changes. As network 2447 renumbering is expected to become increasingly common [RFC1900], the 2448 possibility of this form of attack will grow. Observing this 2449 requirement thus reduces this potential security vulnerability. 2451 This requirement also improves the load-balancing behavior of clients 2452 for replicated servers using the same DNS name and reduces the 2453 likelihood of a user's experiencing failure in accessing sites which 2454 use that strategy. 2456 10.5. Proxies and Caching 2458 By their very nature, HTTP proxies are men-in-the-middle, and 2459 represent an opportunity for man-in-the-middle attacks. Compromise 2460 of the systems on which the proxies run can result in serious 2461 security and privacy problems. Proxies have access to security- 2462 related information, personal information about individual users and 2463 organizations, and proprietary information belonging to users and 2464 content providers. A compromised proxy, or a proxy implemented or 2465 configured without regard to security and privacy considerations, 2466 might be used in the commission of a wide range of potential attacks. 2468 Proxy operators should protect the systems on which proxies run as 2469 they would protect any system that contains or transports sensitive 2470 information. In particular, log information gathered at proxies 2471 often contains highly sensitive personal information, and/or 2472 information about organizations. Log information should be carefully 2473 guarded, and appropriate guidelines for use developed and followed. 2474 (Section 10.2). 2476 Proxy implementors should consider the privacy and security 2477 implications of their design and coding decisions, and of the 2478 configuration options they provide to proxy operators (especially the 2479 default configuration). 2481 Users of a proxy need to be aware that they are no trustworthier than 2482 the people who run the proxy; HTTP itself cannot solve this problem. 2484 The judicious use of cryptography, when appropriate, may suffice to 2485 protect against a broad range of security and privacy attacks. Such 2486 cryptography is beyond the scope of the HTTP/1.1 specification. 2488 10.6. Denial of Service Attacks on Proxies 2490 They exist. They are hard to defend against. Research continues. 2491 Beware. 2493 11. Acknowledgments 2495 This specification makes heavy use of the augmented BNF and generic 2496 constructs defined by David H. Crocker for [RFC822ABNF]. Similarly, 2497 it reuses many of the definitions provided by Nathaniel Borenstein 2498 and Ned Freed for MIME [RFC2045]. We hope that their inclusion in 2499 this specification will help reduce past confusion over the 2500 relationship between HTTP and Internet mail message formats. 2502 HTTP has evolved considerably over the years. It has benefited from 2503 a large and active developer community--the many people who have 2504 participated on the www-talk mailing list--and it is that community 2505 which has been most responsible for the success of HTTP and of the 2506 World-Wide Web in general. Marc Andreessen, Robert Cailliau, Daniel 2507 W. Connolly, Bob Denny, John Franks, Jean-Francois Groff, Phillip M. 2508 Hallam-Baker, Hakon W. Lie, Ari Luotonen, Rob McCool, Lou Montulli, 2509 Dave Raggett, Tony Sanders, and Marc VanHeyningen deserve special 2510 recognition for their efforts in defining early aspects of the 2511 protocol. 2513 This document has benefited greatly from the comments of all those 2514 participating in the HTTP-WG. In addition to those already 2515 mentioned, the following individuals have contributed to this 2516 specification: 2518 Gary Adams, Harald Tveit Alvestrand, Keith Ball, Brian Behlendorf, 2519 Paul Burchard, Maurizio Codogno, Mike Cowlishaw, Roman Czyborra, 2520 Michael A. Dolan, Daniel DuBois, David J. Fiander, Alan Freier, Marc 2521 Hedlund, Greg Herlihy, Koen Holtman, Alex Hopmann, Bob Jernigan, Shel 2522 Kaphan, Rohit Khare, John Klensin, Martijn Koster, Alexei Kosut, 2523 David M. Kristol, Daniel LaLiberte, Ben Laurie, Paul J. Leach, Albert 2524 Lunde, John C. Mallery, Jean-Philippe Martin-Flatin, Mitra, David 2525 Morris, Gavin Nicol, Ross Patterson, Bill Perry, Jeffrey Perry, Scott 2526 Powers, Owen Rees, Luigi Rizzo, David Robinson, Marc Salomon, Rich 2527 Salz, Allan M. Schiffman, Jim Seidman, Chuck Shotton, Eric W. Sink, 2528 Simon E. Spero, Richard N. Taylor, Robert S. Thau, Bill (BearHeart) 2529 Weinman, Francois Yergeau, Mary Ellen Zurko, Josh Cohen. 2531 Thanks to the "cave men" of Palo Alto. You know who you are. 2533 Jim Gettys (the editor of [RFC2616]) wishes particularly to thank Roy 2534 Fielding, the editor of [RFC2068], along with John Klensin, Jeff 2535 Mogul, Paul Leach, Dave Kristol, Koen Holtman, John Franks, Josh 2536 Cohen, Alex Hopmann, Scott Lawrence, and Larry Masinter for their 2537 help. And thanks go particularly to Jeff Mogul and Scott Lawrence 2538 for performing the "MUST/MAY/SHOULD" audit. 2540 The Apache Group, Anselm Baird-Smith, author of Jigsaw, and Henrik 2541 Frystyk implemented RFC 2068 early, and we wish to thank them for the 2542 discovery of many of the problems that this document attempts to 2543 rectify. 2545 12. References 2547 12.1. Normative References 2549 [ISO-8859-1] 2550 International Organization for Standardization, 2551 "Information technology -- 8-bit single-byte coded graphic 2552 character sets -- Part 1: Latin alphabet No. 1", ISO/ 2553 IEC 8859-1:1998, 1998. 2555 [Part2] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., 2556 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., 2557 and J. Reschke, Ed., "HTTP/1.1, part 2: Message 2558 Semantics", draft-ietf-httpbis-p2-semantics-04 (work in 2559 progress), August 2008. 2561 [Part3] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., 2562 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., 2563 and J. Reschke, Ed., "HTTP/1.1, part 3: Message Payload 2564 and Content Negotiation", draft-ietf-httpbis-p3-payload-04 2565 (work in progress), August 2008. 2567 [Part5] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., 2568 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., 2569 and J. Reschke, Ed., "HTTP/1.1, part 5: Range Requests and 2570 Partial Responses", draft-ietf-httpbis-p5-range-04 (work 2571 in progress), August 2008. 2573 [Part6] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., 2574 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., 2575 and J. Reschke, Ed., "HTTP/1.1, part 6: Caching", 2576 draft-ietf-httpbis-p6-cache-04 (work in progress), 2577 August 2008. 2579 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 2580 Extensions (MIME) Part One: Format of Internet Message 2581 Bodies", RFC 2045, November 1996. 2583 [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) 2584 Part Three: Message Header Extensions for Non-ASCII Text", 2585 RFC 2047, November 1996. 2587 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2588 Requirement Levels", BCP 14, RFC 2119, March 1997. 2590 [RFC2396] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 2591 Resource Identifiers (URI): Generic Syntax", RFC 2396, 2592 August 1998. 2594 [RFC822ABNF] 2595 Crocker, D., "Standard for the format of ARPA Internet 2596 text messages", STD 11, RFC 822, August 1982. 2598 [USASCII] American National Standards Institute, "Coded Character 2599 Set -- 7-bit American Standard Code for Information 2600 Interchange", ANSI X3.4, 1986. 2602 12.2. Informative References 2604 [Kri2001] Kristol, D., "HTTP Cookies: Standards, Privacy, and 2605 Politics", ACM Transactions on Internet Technology Vol. 1, 2606 #2, November 2001, . 2608 [Nie1997] Nielsen, H., Gettys, J., Prud'hommeaux, E., Lie, H., and 2609 C. Lilley, "Network Performance Effects of HTTP/1.1, CSS1, 2610 and PNG", ACM Proceedings of the ACM SIGCOMM '97 2611 conference on Applications, technologies, architectures, 2612 and protocols for computer communication SIGCOMM '97, 2613 September 1997, 2614 . 2616 [Pad1995] Padmanabhan, V. and J. Mogul, "Improving HTTP Latency", 2617 Computer Networks and ISDN Systems v. 28, pp. 25-35, 2618 December 1995, 2619 . 2621 [RFC1123] Braden, R., "Requirements for Internet Hosts - Application 2622 and Support", STD 3, RFC 1123, October 1989. 2624 [RFC1305] Mills, D., "Network Time Protocol (Version 3) 2625 Specification, Implementation", RFC 1305, March 1992. 2627 [RFC1436] Anklesaria, F., McCahill, M., Lindner, P., Johnson, D., 2628 Torrey, D., and B. Alberti, "The Internet Gopher Protocol 2629 (a distributed document search and retrieval protocol)", 2630 RFC 1436, March 1993. 2632 [RFC1630] Berners-Lee, T., "Universal Resource Identifiers in WWW: A 2633 Unifying Syntax for the Expression of Names and Addresses 2634 of Objects on the Network as used in the World-Wide Web", 2635 RFC 1630, June 1994. 2637 [RFC1737] Masinter, L. and K. Sollins, "Functional Requirements for 2638 Uniform Resource Names", RFC 1737, December 1994. 2640 [RFC1738] Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform 2641 Resource Locators (URL)", RFC 1738, December 1994. 2643 [RFC1808] Fielding, R., "Relative Uniform Resource Locators", 2644 RFC 1808, June 1995. 2646 [RFC1900] Carpenter, B. and Y. Rekhter, "Renumbering Needs Work", 2647 RFC 1900, February 1996. 2649 [RFC1945] Berners-Lee, T., Fielding, R., and H. Nielsen, "Hypertext 2650 Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996. 2652 [RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and T. 2653 Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", 2654 RFC 2068, January 1997. 2656 [RFC2109] Kristol, D. and L. Montulli, "HTTP State Management 2657 Mechanism", RFC 2109, February 1997. 2659 [RFC2145] Mogul, J., Fielding, R., Gettys, J., and H. Nielsen, "Use 2660 and Interpretation of HTTP Version Numbers", RFC 2145, 2661 May 1997. 2663 [RFC2324] Masinter, L., "Hyper Text Coffee Pot Control Protocol 2664 (HTCPCP/1.0)", RFC 2324, April 1998. 2666 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 2667 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 2668 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 2670 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 2672 [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, 2673 April 2001. 2675 [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, 2676 April 2001. 2678 [RFC2965] Kristol, D. and L. Montulli, "HTTP State Management 2679 Mechanism", RFC 2965, October 2000. 2681 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration 2682 Procedures for Message Header Fields", BCP 90, RFC 3864, 2683 September 2004. 2685 [RFC3977] Feather, C., "Network News Transfer Protocol (NNTP)", 2686 RFC 3977, October 2006. 2688 [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and 2689 Registration Procedures", BCP 13, RFC 4288, December 2005. 2691 [RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and 2692 Registration Procedures for New URI Schemes", BCP 115, 2693 RFC 4395, February 2006. 2695 [RFC822] Crocker, D., "Standard for the format of ARPA Internet 2696 text messages", STD 11, RFC 822, August 1982. 2698 [RFC959] Postel, J. and J. Reynolds, "File Transfer Protocol", 2699 STD 9, RFC 959, October 1985. 2701 [Spe] Spero, S., "Analysis of HTTP Performance Problems", 2702 . 2704 [Tou1998] Touch, J., Heidemann, J., and K. Obraczka, "Analysis of 2705 HTTP Performance", ISI Research Report ISI/RR-98-463, 2706 Aug 1998, . 2708 (original report dated Aug. 1996) 2710 [WAIS] Davis, F., Kahle, B., Morris, H., Salem, J., Shen, T., 2711 Wang, R., Sui, J., and M. Grinbaum, "WAIS Interface 2712 Protocol Prototype Functional Specification (v1.5)", 2713 Thinking Machines Corporation , April 1990. 2715 Appendix A. Tolerant Applications 2717 Although this document specifies the requirements for the generation 2718 of HTTP/1.1 messages, not all applications will be correct in their 2719 implementation. We therefore recommend that operational applications 2720 be tolerant of deviations whenever those deviations can be 2721 interpreted unambiguously. 2723 Clients SHOULD be tolerant in parsing the Status-Line and servers 2724 tolerant when parsing the Request-Line. In particular, they SHOULD 2725 accept any amount of SP or HTAB characters between fields, even 2726 though only a single SP is required. 2728 The line terminator for message-header fields is the sequence CRLF. 2729 However, we recommend that applications, when parsing such headers, 2730 recognize a single LF as a line terminator and ignore the leading CR. 2732 The character set of an entity-body SHOULD be labeled as the lowest 2733 common denominator of the character codes used within that body, with 2734 the exception that not labeling the entity is preferred over labeling 2735 the entity with the labels US-ASCII or ISO-8859-1. See [Part3]. 2737 Additional rules for requirements on parsing and encoding of dates 2738 and other potential problems with date encodings include: 2740 o HTTP/1.1 clients and caches SHOULD assume that an RFC-850 date 2741 which appears to be more than 50 years in the future is in fact in 2742 the past (this helps solve the "year 2000" problem). 2744 o An HTTP/1.1 implementation MAY internally represent a parsed 2745 Expires date as earlier than the proper value, but MUST NOT 2746 internally represent a parsed Expires date as later than the 2747 proper value. 2749 o All expiration-related calculations MUST be done in GMT. The 2750 local time zone MUST NOT influence the calculation or comparison 2751 of an age or expiration time. 2753 o If an HTTP header incorrectly carries a date value with a time 2754 zone other than GMT, it MUST be converted into GMT using the most 2755 conservative possible conversion. 2757 Appendix B. Conversion of Date Formats 2759 HTTP/1.1 uses a restricted set of date formats (Section 3.3.1) to 2760 simplify the process of date comparison. Proxies and gateways from 2761 other protocols SHOULD ensure that any Date header field present in a 2762 message conforms to one of the HTTP/1.1 formats and rewrite the date 2763 if necessary. 2765 Appendix C. Compatibility with Previous Versions 2767 It is beyond the scope of a protocol specification to mandate 2768 compliance with previous versions. HTTP/1.1 was deliberately 2769 designed, however, to make supporting previous versions easy. It is 2770 worth noting that, at the time of composing this specification 2771 (1996), we would expect commercial HTTP/1.1 servers to: 2773 o recognize the format of the Request-Line for HTTP/0.9, 1.0, and 2774 1.1 requests; 2776 o understand any valid request in the format of HTTP/0.9, 1.0, or 2777 1.1; 2779 o respond appropriately with a message in the same major version 2780 used by the client. 2782 And we would expect HTTP/1.1 clients to: 2784 o recognize the format of the Status-Line for HTTP/1.0 and 1.1 2785 responses; 2787 o understand any valid response in the format of HTTP/0.9, 1.0, or 2788 1.1. 2790 For most implementations of HTTP/1.0, each connection is established 2791 by the client prior to the request and closed by the server after 2792 sending the response. Some implementations implement the Keep-Alive 2793 version of persistent connections described in Section 19.7.1 of 2794 [RFC2068]. 2796 C.1. Changes from HTTP/1.0 2798 This section summarizes major differences between versions HTTP/1.0 2799 and HTTP/1.1. 2801 C.1.1. Changes to Simplify Multi-homed Web Servers and Conserve IP 2802 Addresses 2804 The requirements that clients and servers support the Host request- 2805 header, report an error if the Host request-header (Section 8.4) is 2806 missing from an HTTP/1.1 request, and accept absolute URIs 2807 (Section 5.1.2) are among the most important changes defined by this 2808 specification. 2810 Older HTTP/1.0 clients assumed a one-to-one relationship of IP 2811 addresses and servers; there was no other established mechanism for 2812 distinguishing the intended server of a request than the IP address 2813 to which that request was directed. The changes outlined above will 2814 allow the Internet, once older HTTP clients are no longer common, to 2815 support multiple Web sites from a single IP address, greatly 2816 simplifying large operational Web servers, where allocation of many 2817 IP addresses to a single host has created serious problems. The 2818 Internet will also be able to recover the IP addresses that have been 2819 allocated for the sole purpose of allowing special-purpose domain 2820 names to be used in root-level HTTP URLs. Given the rate of growth 2821 of the Web, and the number of servers already deployed, it is 2822 extremely important that all implementations of HTTP (including 2823 updates to existing HTTP/1.0 applications) correctly implement these 2824 requirements: 2826 o Both clients and servers MUST support the Host request-header. 2828 o A client that sends an HTTP/1.1 request MUST send a Host header. 2830 o Servers MUST report a 400 (Bad Request) error if an HTTP/1.1 2831 request does not include a Host request-header. 2833 o Servers MUST accept absolute URIs. 2835 C.2. Compatibility with HTTP/1.0 Persistent Connections 2837 Some clients and servers might wish to be compatible with some 2838 previous implementations of persistent connections in HTTP/1.0 2839 clients and servers. Persistent connections in HTTP/1.0 are 2840 explicitly negotiated as they are not the default behavior. HTTP/1.0 2841 experimental implementations of persistent connections are faulty, 2842 and the new facilities in HTTP/1.1 are designed to rectify these 2843 problems. The problem was that some existing 1.0 clients may be 2844 sending Keep-Alive to a proxy server that doesn't understand 2845 Connection, which would then erroneously forward it to the next 2846 inbound server, which would establish the Keep-Alive connection and 2847 result in a hung HTTP/1.0 proxy waiting for the close on the 2848 response. The result is that HTTP/1.0 clients must be prevented from 2849 using Keep-Alive when talking to proxies. 2851 However, talking to proxies is the most important use of persistent 2852 connections, so that prohibition is clearly unacceptable. Therefore, 2853 we need some other mechanism for indicating a persistent connection 2854 is desired, which is safe to use even when talking to an old proxy 2855 that ignores Connection. Persistent connections are the default for 2856 HTTP/1.1 messages; we introduce a new keyword (Connection: close) for 2857 declaring non-persistence. See Section 8.1. 2859 The original HTTP/1.0 form of persistent connections (the Connection: 2860 Keep-Alive and Keep-Alive header) is documented in [RFC2068]. 2862 C.3. Changes from RFC 2068 2864 This specification has been carefully audited to correct and 2865 disambiguate key word usage; RFC 2068 had many problems in respect to 2866 the conventions laid out in [RFC2119]. 2868 Transfer-coding and message lengths all interact in ways that 2869 required fixing exactly when chunked encoding is used (to allow for 2870 transfer encoding that may not be self delimiting); it was important 2871 to straighten out exactly how message lengths are computed. 2872 (Sections 3.4, 4.4, 8.2, see also [Part3], [Part5] and [Part6]) 2874 The use and interpretation of HTTP version numbers has been clarified 2875 by [RFC2145]. Require proxies to upgrade requests to highest 2876 protocol version they support to deal with problems discovered in 2877 HTTP/1.0 implementations (Section 3.1) 2879 Transfer-coding had significant problems, particularly with 2880 interactions with chunked encoding. The solution is that transfer- 2881 codings become as full fledged as content-codings. This involves 2882 adding an IANA registry for transfer-codings (separate from content 2883 codings), a new header field (TE) and enabling trailer headers in the 2884 future. Transfer encoding is a major performance benefit, so it was 2885 worth fixing [Nie1997]. TE also solves another, obscure, downward 2886 interoperability problem that could have occurred due to interactions 2887 between authentication trailers, chunked encoding and HTTP/1.0 2888 clients.(Section 3.4, 3.4.1, and 8.5) 2890 C.4. Changes from RFC 2616 2892 The CHAR rule does not allow the NUL character anymore (this affects 2893 the comment and quoted-string rules). Furthermore, the quoted-pair 2894 rule does not allow escaping NUL, CR or LF anymore. (Section 2.2) 2896 Clarify that HTTP-Version is case sensitive. (Section 3.1) 2898 Remove reference to non-existant identity transfer-coding value 2899 tokens. (Sections 3.4 and 4.4) 2901 Clarification that the chunk length does not include the count of the 2902 octets in the chunk header and trailer. (Section 3.4.1) 2904 Fix BNF to add query, as the abs_path production in Section 3 of 2905 [RFC2396] doesn't define it. (Section 5.1.2) 2906 Clarify exactly when close connection options must be sent. 2907 (Section 8.1) 2909 Appendix D. Change Log (to be removed by RFC Editor before publication) 2911 D.1. Since RFC2616 2913 Extracted relevant partitions from [RFC2616]. 2915 D.2. Since draft-ietf-httpbis-p1-messaging-00 2917 Closed issues: 2919 o : "HTTP 2920 Version should be case sensitive" 2921 () 2923 o : "'unsafe' 2924 characters" () 2926 o : "Chunk Size 2927 Definition" () 2929 o : "Message 2930 Length" () 2932 o : "Media Type 2933 Registrations" () 2935 o : "URI 2936 includes query" () 2938 o : "No close 2939 on 1xx responses" () 2941 o : "Remove 2942 'identity' token references" 2943 () 2945 o : "Import 2946 query BNF" 2948 o : "qdtext 2949 BNF" 2951 o : "Normative 2952 and Informative references" 2954 o : "RFC2606 2955 Compliance" 2957 o : "RFC977 2958 reference" 2960 o : "RFC1700 2961 references" 2963 o : 2964 "inconsistency in date format explanation" 2966 o : "Date 2967 reference typo" 2969 o : 2970 "Informative references" 2972 o : 2973 "ISO-8859-1 Reference" 2975 o : "Normative 2976 up-to-date references" 2978 Other changes: 2980 o Update media type registrations to use RFC4288 template. 2982 o Use names of RFC4234 core rules DQUOTE and HTAB, fix broken ABNF 2983 for chunk-data (work in progress on 2984 ) 2986 D.3. Since draft-ietf-httpbis-p1-messaging-01 2988 Closed issues: 2990 o : "Bodies on 2991 GET (and other) requests" 2993 o : "Updating 2994 to RFC4288" 2996 o : "Status 2997 Code and Reason Phrase" 2999 o : "rel_path 3000 not used" 3002 Ongoing work on ABNF conversion 3003 (): 3005 o Get rid of duplicate BNF rule names ("host" -> "uri-host", 3006 "trailer" -> "trailer-part"). 3008 o Avoid underscore character in rule names ("http_URL" -> "http- 3009 URL", "abs_path" -> "path-absolute"). 3011 o Add rules for terms imported from URI spec ("absoluteURI", 3012 "authority", "path-absolute", "port", "query", "relativeURI", 3013 "host) -- these will have to be updated when switching over to 3014 RFC3986. 3016 o Synchronize core rules with RFC5234 (this includes a change to 3017 CHAR which now excludes NUL). 3019 o Get rid of prose rules that span multiple lines. 3021 o Get rid of unused rules LOALPHA and UPALPHA. 3023 o Move "Product Tokens" section (back) into Part 1, as "token" is 3024 used in the definition of the Upgrade header. 3026 o Add explicit references to BNF syntax and rules imported from 3027 other parts of the specification. 3029 o Rewrite prose rule "token" in terms of "tchar", rewrite prose rule 3030 "TEXT". 3032 D.4. Since draft-ietf-httpbis-p1-messaging-02 3034 Closed issues: 3036 o : "HTTP-date 3037 vs. rfc1123-date" 3039 o : "WS in 3040 quoted-pair" 3042 Ongoing work on IANA Message Header Registration 3043 (): 3045 o Reference RFC 3984, and update header registrations for headers 3046 defined in this document. 3048 Ongoing work on ABNF conversion 3049 (): 3051 o Replace string literals when the string really is case-sensitive 3052 (HTTP-Version). 3054 D.5. Since draft-ietf-httpbis-p1-messaging-03 3056 Closed issues: 3058 o : 3059 "Connection closing" 3061 o : "Move 3062 registrations and registry information to IANA Considerations" 3064 o : "need new 3065 URL for PAD1995 reference" 3067 o : "IANA 3068 Considerations: update HTTP URI scheme registration" 3070 o : "Cite 3071 HTTPS URI scheme definition" 3073 o : "List- 3074 type headers vs Set-Cookie" 3076 Ongoing work on ABNF conversion 3077 (): 3079 o Replace string literals when the string really is case-sensitive 3080 (HTTP-Date). 3082 o Replace HEX by HEXDIG for future consistence with RFC 5234's core 3083 rules. 3085 Index 3087 A 3088 application/http Media Type 50 3090 C 3091 cache 8 3092 cacheable 9 3093 client 7 3094 connection 6 3095 Connection header 40 3096 content negotiation 7 3097 Content-Length header 41 3099 D 3100 Date header 42 3101 downstream 9 3103 E 3104 entity 7 3106 G 3107 gateway 8 3108 Grammar 3109 absoluteURI 18 3110 ALPHA 14 3111 asctime-date 20 3112 attribute 21 3113 authority 18 3114 CHAR 14 3115 chunk 22 3116 chunk-data 22 3117 chunk-ext-name 22 3118 chunk-ext-val 22 3119 chunk-extension 22 3120 chunk-size 22 3121 Chunked-Body 22 3122 comment 15 3123 Connection 40 3124 connection-token 40 3125 Content-Length 41 3126 CR 14 3127 CRLF 14 3128 ctext 15 3129 CTL 14 3130 Date 42 3131 date1 20 3132 date2 20 3133 date3 20 3134 DIGIT 14 3135 DQUOTE 14 3136 extension-code 33 3137 extension-method 29 3138 field-content 25 3139 field-name 25 3140 field-value 25 3141 general-header 29 3142 generic-message 25 3143 HEXDIG 15 3144 Host 43 3145 HTAB 14 3146 HTTP-date 20 3147 HTTP-message 24 3148 HTTP-Prot-Name 16 3149 http-URL 18 3150 HTTP-Version 16 3151 last-chunk 22 3152 LF 14 3153 LWS 14 3154 message-body 26 3155 message-header 25 3156 Method 29 3157 month 20 3158 obsolete-date 20 3159 OCTET 14 3160 parameter 21 3161 path-absolute 18 3162 port 18 3163 product 24 3164 product-version 24 3165 protocol-name 47 3166 protocol-version 47 3167 pseudonym 47 3168 qdtext 15 3169 query 18 3170 quoted-pair 15 3171 quoted-string 15 3172 quoted-text 15 3173 Reason-Phrase 33 3174 received-by 47 3175 received-protocol 47 3176 relativeURI 18 3177 Request 29 3178 Request-Line 29 3179 Request-URI 30 3180 Response 32 3181 rfc850-date 20 3182 rfc1123-date 20 3183 separators 15 3184 SP 14 3185 start-line 25 3186 Status-Code 33 3187 Status-Line 32 3188 t-codings 44 3189 tchar 15 3190 TE 44 3191 TEXT 14 3192 time 20 3193 token 15 3194 Trailer 45 3195 trailer-part 22 3196 transfer-coding 21 3197 Transfer-Encoding 45 3198 transfer-extension 21 3199 Upgrade 46 3200 uri-host 18 3201 value 21 3202 Via 47 3203 weekday 20 3204 wkday 20 3206 H 3207 Headers 3208 Connection 40 3209 Content-Length 41 3210 Date 42 3211 Host 43 3212 TE 44 3213 Trailer 45 3214 Transfer-Encoding 45 3215 Upgrade 46 3216 Via 47 3217 Host header 43 3218 http URI scheme 18 3219 https URI scheme 18 3221 I 3222 implied *LWS 13 3223 inbound 9 3225 M 3226 Media Type 3227 application/http 50 3228 message/http 49 3229 message 6 3230 message/http Media Type 49 3232 O 3233 origin server 8 3234 outbound 9 3236 P 3237 proxy 8 3239 R 3240 representation 7 3241 request 6 3242 resource 7 3243 response 6 3245 S 3246 server 8 3248 T 3249 TE header 44 3250 Trailer header 45 3251 Transfer-Encoding header 45 3252 tunnel 8 3254 U 3255 Upgrade header 46 3256 upstream 9 3257 URI scheme 3258 http 18 3259 https 18 3260 user agent 7 3262 V 3263 variant 7 3264 Via header 47 3266 Authors' Addresses 3268 Roy T. Fielding (editor) 3269 Day Software 3270 23 Corporate Plaza DR, Suite 280 3271 Newport Beach, CA 92660 3272 USA 3274 Phone: +1-949-706-5300 3275 Fax: +1-949-706-5305 3276 Email: fielding@gbiv.com 3277 URI: http://roy.gbiv.com/ 3279 Jim Gettys 3280 One Laptop per Child 3281 21 Oak Knoll Road 3282 Carlisle, MA 01741 3283 USA 3285 Email: jg@laptop.org 3286 URI: http://www.laptop.org/ 3287 Jeffrey C. Mogul 3288 Hewlett-Packard Company 3289 HP Labs, Large Scale Systems Group 3290 1501 Page Mill Road, MS 1177 3291 Palo Alto, CA 94304 3292 USA 3294 Email: JeffMogul@acm.org 3296 Henrik Frystyk Nielsen 3297 Microsoft Corporation 3298 1 Microsoft Way 3299 Redmond, WA 98052 3300 USA 3302 Email: henrikn@microsoft.com 3304 Larry Masinter 3305 Adobe Systems, Incorporated 3306 345 Park Ave 3307 San Jose, CA 95110 3308 USA 3310 Email: LMM@acm.org 3311 URI: http://larry.masinter.net/ 3313 Paul J. Leach 3314 Microsoft Corporation 3315 1 Microsoft Way 3316 Redmond, WA 98052 3318 Email: paulle@microsoft.com 3320 Tim Berners-Lee 3321 World Wide Web Consortium 3322 MIT Computer Science and Artificial Intelligence Laboratory 3323 The Stata Center, Building 32 3324 32 Vassar Street 3325 Cambridge, MA 02139 3326 USA 3328 Email: timbl@w3.org 3329 URI: http://www.w3.org/People/Berners-Lee/ 3330 Yves Lafon (editor) 3331 World Wide Web Consortium 3332 W3C / ERCIM 3333 2004, rte des Lucioles 3334 Sophia-Antipolis, AM 06902 3335 France 3337 Email: ylafon@w3.org 3338 URI: http://www.raubacapeu.net/people/yves/ 3340 Julian F. Reschke (editor) 3341 greenbytes GmbH 3342 Hafenweg 16 3343 Muenster, NW 48155 3344 Germany 3346 Phone: +49 251 2807760 3347 Fax: +49 251 2807761 3348 Email: julian.reschke@greenbytes.de 3349 URI: http://greenbytes.de/tech/webdav/ 3351 Full Copyright Statement 3353 Copyright (C) The IETF Trust (2008). 3355 This document is subject to the rights, licenses and restrictions 3356 contained in BCP 78, and except as set forth therein, the authors 3357 retain all their rights. 3359 This document and the information contained herein are provided on an 3360 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 3361 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 3362 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 3363 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 3364 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 3365 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 3367 Intellectual Property 3369 The IETF takes no position regarding the validity or scope of any 3370 Intellectual Property Rights or other rights that might be claimed to 3371 pertain to the implementation or use of the technology described in 3372 this document or the extent to which any license under such rights 3373 might or might not be available; nor does it represent that it has 3374 made any independent effort to identify any such rights. Information 3375 on the procedures with respect to rights in RFC documents can be 3376 found in BCP 78 and BCP 79. 3378 Copies of IPR disclosures made to the IETF Secretariat and any 3379 assurances of licenses to be made available, or the result of an 3380 attempt made to obtain a general license or permission for the use of 3381 such proprietary rights by implementers or users of this 3382 specification can be obtained from the IETF on-line IPR repository at 3383 http://www.ietf.org/ipr. 3385 The IETF invites any interested party to bring to its attention any 3386 copyrights, patents or patent applications, or other proprietary 3387 rights that may cover technology that may be required to implement 3388 this standard. Please address the information to the IETF at 3389 ietf-ipr@ietf.org.