idnits 2.17.1 draft-ietf-httpbis-p1-messaging-01.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 3089. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 3100. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 3107. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 3113. 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 (January 12, 2008) is 5948 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) == Missing Reference: 'CRLF' is mentioned on line 616, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO-8859-1' == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p2-semantics-01 == Outdated reference: A later version (-20) exists of draft-ietf-httpbis-p3-payload-01 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p5-range-01 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p6-cache-01 ** Obsolete normative reference: RFC 2396 (Obsoleted by RFC 3986) ** Obsolete normative reference: RFC 4288 (Obsoleted by RFC 6838) ** 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 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 2821 (Obsoleted by RFC 5321) -- Obsolete informational reference (is this intentional?): RFC 2822 (Obsoleted by RFC 5322) -- Duplicate reference: RFC822, mentioned in 'RFC822', was also mentioned in 'RFC822ABNF'. -- Obsolete informational reference (is this intentional?): RFC 822 (Obsoleted by RFC 2822) Summary: 4 errors (**), 0 flaws (~~), 6 warnings (==), 20 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: July 15, 2008 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 January 12, 2008 22 HTTP/1.1, part 1: URIs, Connections, and Message Parsing 23 draft-ietf-httpbis-p1-messaging-01 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 July 15, 2008. 50 Copyright Notice 52 Copyright (C) The IETF Trust (2008). 54 Abstract 56 The Hypertext Transfer Protocol (HTTP) is an application-level 57 protocol for distributed, collaborative, hypermedia information 58 systems. HTTP has been in use by the World Wide Web global 59 information initiative since 1990. This document is Part 1 of the 60 seven-part specification that defines the protocol referred to as 61 "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 1 provides 62 an overview of HTTP and its associated terminology, defines the 63 "http" and "https" Uniform Resource Identifier (URI) schemes, defines 64 the generic message syntax and parsing requirements for HTTP message 65 frames, and describes general security concerns for implementations. 67 Editorial Note (To be removed by RFC Editor) 69 Discussion of this draft should take place on the HTTPBIS working 70 group mailing list (ietf-http-wg@w3.org). The current issues list is 71 at and related 72 documents (including fancy diffs) can be found at 73 . 75 This draft incorporates those issue resolutions that were either 76 collected in the original RFC2616 errata list 77 (), or which were agreed upon on the 78 mailing list between October 2006 and November 2007 (as published in 79 "draft-lafon-rfc2616bis-03"). 81 Table of Contents 83 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 84 1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 5 85 1.2. Requirements . . . . . . . . . . . . . . . . . . . . . . . 6 86 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 87 1.4. Overall Operation . . . . . . . . . . . . . . . . . . . . 9 88 2. Notational Conventions and Generic Grammar . . . . . . . . . . 11 89 2.1. Augmented BNF . . . . . . . . . . . . . . . . . . . . . . 11 90 2.2. Basic Rules . . . . . . . . . . . . . . . . . . . . . . . 13 91 3. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 15 92 3.1. HTTP Version . . . . . . . . . . . . . . . . . . . . . . . 15 93 3.2. Uniform Resource Identifiers . . . . . . . . . . . . . . . 16 94 3.2.1. General Syntax . . . . . . . . . . . . . . . . . . . . 17 95 3.2.2. http URL . . . . . . . . . . . . . . . . . . . . . . . 17 96 3.2.3. URI Comparison . . . . . . . . . . . . . . . . . . . . 18 97 3.3. Date/Time Formats . . . . . . . . . . . . . . . . . . . . 18 98 3.3.1. Full Date . . . . . . . . . . . . . . . . . . . . . . 18 99 3.4. Transfer Codings . . . . . . . . . . . . . . . . . . . . . 19 100 3.4.1. Chunked Transfer Coding . . . . . . . . . . . . . . . 20 101 4. HTTP Message . . . . . . . . . . . . . . . . . . . . . . . . . 22 102 4.1. Message Types . . . . . . . . . . . . . . . . . . . . . . 22 103 4.2. Message Headers . . . . . . . . . . . . . . . . . . . . . 23 104 4.3. Message Body . . . . . . . . . . . . . . . . . . . . . . . 24 105 4.4. Message Length . . . . . . . . . . . . . . . . . . . . . . 25 106 4.5. General Header Fields . . . . . . . . . . . . . . . . . . 26 107 5. Request . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 108 5.1. Request-Line . . . . . . . . . . . . . . . . . . . . . . . 27 109 5.1.1. Method . . . . . . . . . . . . . . . . . . . . . . . . 27 110 5.1.2. Request-URI . . . . . . . . . . . . . . . . . . . . . 27 111 5.2. The Resource Identified by a Request . . . . . . . . . . . 29 112 6. Response . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 113 6.1. Status-Line . . . . . . . . . . . . . . . . . . . . . . . 30 114 6.1.1. Status Code and Reason Phrase . . . . . . . . . . . . 30 115 7. Connections . . . . . . . . . . . . . . . . . . . . . . . . . 30 116 7.1. Persistent Connections . . . . . . . . . . . . . . . . . . 31 117 7.1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . 31 118 7.1.2. Overall Operation . . . . . . . . . . . . . . . . . . 31 119 7.1.3. Proxy Servers . . . . . . . . . . . . . . . . . . . . 33 120 7.1.4. Practical Considerations . . . . . . . . . . . . . . . 33 121 7.2. Message Transmission Requirements . . . . . . . . . . . . 34 122 7.2.1. Persistent Connections and Flow Control . . . . . . . 34 123 7.2.2. Monitoring Connections for Error Status Messages . . . 34 124 7.2.3. Use of the 100 (Continue) Status . . . . . . . . . . . 35 125 7.2.4. Client Behavior if Server Prematurely Closes 126 Connection . . . . . . . . . . . . . . . . . . . . . . 37 127 8. Header Field Definitions . . . . . . . . . . . . . . . . . . . 37 128 8.1. Connection . . . . . . . . . . . . . . . . . . . . . . . . 38 129 8.2. Content-Length . . . . . . . . . . . . . . . . . . . . . . 39 130 8.3. Date . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 131 8.3.1. Clockless Origin Server Operation . . . . . . . . . . 40 132 8.4. Host . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 133 8.5. TE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 134 8.6. Trailer . . . . . . . . . . . . . . . . . . . . . . . . . 42 135 8.7. Transfer-Encoding . . . . . . . . . . . . . . . . . . . . 43 136 8.8. Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . 43 137 8.9. Via . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 138 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 46 139 10. Security Considerations . . . . . . . . . . . . . . . . . . . 46 140 10.1. Personal Information . . . . . . . . . . . . . . . . . . . 46 141 10.2. Abuse of Server Log Information . . . . . . . . . . . . . 46 142 10.3. Attacks Based On File and Path Names . . . . . . . . . . . 47 143 10.4. DNS Spoofing . . . . . . . . . . . . . . . . . . . . . . . 47 144 10.5. Proxies and Caching . . . . . . . . . . . . . . . . . . . 48 145 10.6. Denial of Service Attacks on Proxies . . . . . . . . . . . 48 146 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 49 147 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 50 148 12.1. Normative References . . . . . . . . . . . . . . . . . . . 50 149 12.2. Informative References . . . . . . . . . . . . . . . . . . 51 150 Appendix A. Internet Media Types . . . . . . . . . . . . . . . . 53 151 A.1. Internet Media Type message/http . . . . . . . . . . . . . 53 152 A.2. Internet Media Type application/http . . . . . . . . . . . 54 153 Appendix B. Tolerant Applications . . . . . . . . . . . . . . . . 55 154 Appendix C. Conversion of Date Formats . . . . . . . . . . . . . 56 155 Appendix D. Compatibility with Previous Versions . . . . . . . . 56 156 D.1. Changes from HTTP/1.0 . . . . . . . . . . . . . . . . . . 57 157 D.1.1. Changes to Simplify Multi-homed Web Servers and 158 Conserve IP Addresses . . . . . . . . . . . . . . . . 57 159 D.2. Compatibility with HTTP/1.0 Persistent Connections . . . . 58 160 D.3. Changes from RFC 2068 . . . . . . . . . . . . . . . . . . 58 161 D.4. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 59 162 Appendix E. Change Log (to be removed by RFC Editor before 163 publication) . . . . . . . . . . . . . . . . . . . . 59 164 E.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 59 165 E.2. Since draft-ietf-httpbis-p1-messaging-00 . . . . . . . . . 59 166 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 167 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 64 168 Intellectual Property and Copyright Statements . . . . . . . . . . 68 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 3 of [Part3]. 281 representation 283 An entity included with a response that is subject to content 284 negotiation, as described in Section 4 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 4 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 The HTTP protocol is a request/response protocol. A client sends a 391 request to the server in the form of a request method, URI, and 392 protocol version, followed by a MIME-like message containing request 393 modifiers, client information, and possible body content over a 394 connection with a server. The server responds with a status line, 395 including the message's protocol version and a success or error code, 396 followed by a 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 = 589 CHAR = 590 UPALPHA = 591 LOALPHA = 592 ALPHA = UPALPHA | LOALPHA 593 DIGIT = 594 CTL = 596 CR = 597 LF = 598 SP = 599 HTAB = 600 DQUOTE = 602 HTTP/1.1 defines the sequence CR LF as the end-of-line marker for all 603 protocol elements except the entity-body (see Appendix B for tolerant 604 applications). The end-of-line marker within an entity-body is 605 defined by its associated media type, as described in Section 2.3 of 606 [Part3]. 608 CRLF = CR LF 610 HTTP/1.1 header field values can be folded onto multiple lines if the 611 continuation line begins with a space or horizontal tab. All linear 612 white space, including folding, has the same semantics as SP. A 613 recipient MAY replace any linear white space with a single SP before 614 interpreting the field value or forwarding the message downstream. 616 LWS = [CRLF] 1*( SP | HTAB ) 618 The TEXT rule is only used for descriptive field contents and values 619 that are not intended to be interpreted by the message parser. Words 620 of *TEXT MAY contain characters from character sets other than ISO- 621 8859-1 [ISO-8859-1] only when encoded according to the rules of 622 [RFC2047]. 624 TEXT = 627 A CRLF is allowed in the definition of TEXT only as part of a header 628 field continuation. It is expected that the folding LWS will be 629 replaced with a single SP before interpretation of the TEXT value. 631 Hexadecimal numeric characters are used in several protocol elements. 633 HEX = "A" | "B" | "C" | "D" | "E" | "F" 634 | "a" | "b" | "c" | "d" | "e" | "f" | DIGIT 636 Many HTTP/1.1 header field values consist of words separated by LWS 637 or special characters. These special characters MUST be in a quoted 638 string to be used within a parameter value (as defined in 639 Section 3.4). 641 token = 1* 642 separators = "(" | ")" | "<" | ">" | "@" 643 | "," | ";" | ":" | "\" | DQUOTE 644 | "/" | "[" | "]" | "?" | "=" 645 | "{" | "}" | SP | HTAB 647 Comments can be included in some HTTP header fields by surrounding 648 the comment text with parentheses. Comments are only allowed in 649 fields containing "comment" as part of their field value definition. 650 In all other fields, parentheses are considered part of the field 651 value. 653 comment = "(" *( ctext | quoted-pair | comment ) ")" 654 ctext = 656 A string of text is parsed as a single word if it is quoted using 657 double-quote marks. 659 quoted-string = ( DQUOTE *(qdtext | quoted-pair ) DQUOTE ) 660 qdtext = 662 The backslash character ("\") MAY be used as a single-character 663 quoting mechanism only within quoted-string and comment constructs. 665 quoted-pair = "\" CHAR 667 3. Protocol Parameters 669 3.1. HTTP Version 671 HTTP uses a "." numbering scheme to indicate versions 672 of the protocol. The protocol versioning policy is intended to allow 673 the sender to indicate the format of a message and its capacity for 674 understanding further HTTP communication, rather than the features 675 obtained via that communication. No change is made to the version 676 number for the addition of message components which do not affect 677 communication behavior or which only add to extensible field values. 678 The number is incremented when the changes made to the 679 protocol add features which do not change the general message parsing 680 algorithm, but which may add to the message semantics and imply 681 additional capabilities of the sender. The number is 682 incremented when the format of a message within the protocol is 683 changed. See [RFC2145] for a fuller explanation. 685 The version of an HTTP message is indicated by an HTTP-Version field 686 in the first line of the message. HTTP-Version is case-sensitive. 688 HTTP-Version = "HTTP" "/" 1*DIGIT "." 1*DIGIT 690 Note that the major and minor numbers MUST be treated as separate 691 integers and that each MAY be incremented higher than a single digit. 692 Thus, HTTP/2.4 is a lower version than HTTP/2.13, which in turn is 693 lower than HTTP/12.3. Leading zeros MUST be ignored by recipients 694 and MUST NOT be sent. 696 An application that sends a request or response message that includes 697 HTTP-Version of "HTTP/1.1" MUST be at least conditionally compliant 698 with this specification. Applications that are at least 699 conditionally compliant with this specification SHOULD use an HTTP- 700 Version of "HTTP/1.1" in their messages, and MUST do so for any 701 message that is not compatible with HTTP/1.0. For more details on 702 when to send specific HTTP-Version values, see [RFC2145]. 704 The HTTP version of an application is the highest HTTP version for 705 which the application is at least conditionally compliant. 707 Proxy and gateway applications need to be careful when forwarding 708 messages in protocol versions different from that of the application. 709 Since the protocol version indicates the protocol capability of the 710 sender, a proxy/gateway MUST NOT send a message with a version 711 indicator which is greater than its actual version. If a higher 712 version request is received, the proxy/gateway MUST either downgrade 713 the request version, or respond with an error, or switch to tunnel 714 behavior. 716 Due to interoperability problems with HTTP/1.0 proxies discovered 717 since the publication of [RFC2068], caching proxies MUST, gateways 718 MAY, and tunnels MUST NOT upgrade the request to the highest version 719 they support. The proxy/gateway's response to that request MUST be 720 in the same major version as the request. 722 Note: Converting between versions of HTTP may involve modification 723 of header fields required or forbidden by the versions involved. 725 3.2. Uniform Resource Identifiers 727 URIs have been known by many names: WWW addresses, Universal Document 728 Identifiers, Universal Resource Identifiers [RFC1630], and finally 729 the combination of Uniform Resource Locators (URL) [RFC1738] and 730 Names (URN) [RFC1737]. As far as HTTP is concerned, Uniform Resource 731 Identifiers are simply formatted strings which identify--via name, 732 location, or any other characteristic--a resource. 734 3.2.1. General Syntax 736 URIs in HTTP can be represented in absolute form or relative to some 737 known base URI [RFC1808], depending upon the context of their use. 738 The two forms are differentiated by the fact that absolute URIs 739 always begin with a scheme name followed by a colon. For definitive 740 information on URL syntax and semantics, see "Uniform Resource 741 Identifiers (URI): Generic Syntax and Semantics," [RFC2396] (which 742 replaces [RFC1738] and [RFC1808]). This specification adopts the 743 definitions of "URI-reference", "absoluteURI", "relativeURI", "port", 744 "host", "abs_path", "rel_path", "query", and "authority" from that 745 specification. 747 The HTTP protocol does not place any a priori limit on the length of 748 a URI. Servers MUST be able to handle the URI of any resource they 749 serve, and SHOULD be able to handle URIs of unbounded length if they 750 provide GET-based forms that could generate such URIs. A server 751 SHOULD return 414 (Request-URI Too Long) status if a URI is longer 752 than the server can handle (see Section 9.4.15 of [Part2]). 754 Note: Servers ought to be cautious about depending on URI lengths 755 above 255 bytes, because some older client or proxy 756 implementations might not properly support these lengths. 758 3.2.2. http URL 760 The "http" scheme is used to locate network resources via the HTTP 761 protocol. This section defines the scheme-specific syntax and 762 semantics for http URLs. 764 http_URL = "http:" "//" host [ ":" port ] [ abs_path [ "?" query ]] 766 If the port is empty or not given, port 80 is assumed. The semantics 767 are that the identified resource is located at the server listening 768 for TCP connections on that port of that host, and the Request-URI 769 for the resource is abs_path (Section 5.1.2). The use of IP 770 addresses in URLs SHOULD be avoided whenever possible (see 771 [RFC1900]). If the abs_path is not present in the URL, it MUST be 772 given as "/" when used as a Request-URI for a resource 773 (Section 5.1.2). If a proxy receives a host name which is not a 774 fully qualified domain name, it MAY add its domain to the host name 775 it received. If a proxy receives a fully qualified domain name, the 776 proxy MUST NOT change the host name. 778 3.2.3. URI Comparison 780 When comparing two URIs to decide if they match or not, a client 781 SHOULD use a case-sensitive octet-by-octet comparison of the entire 782 URIs, with these exceptions: 784 o A port that is empty or not given is equivalent to the default 785 port for that URI-reference; 787 o Comparisons of host names MUST be case-insensitive; 789 o Comparisons of scheme names MUST be case-insensitive; 791 o An empty abs_path is equivalent to an abs_path of "/". 793 Characters other than those in the "reserved" set (see [RFC2396]) are 794 equivalent to their ""%" HEX HEX" encoding. 796 For example, the following three URIs are equivalent: 798 http://example.com:80/~smith/home.html 799 http://EXAMPLE.com/%7Esmith/home.html 800 http://EXAMPLE.com:/%7esmith/home.html 802 3.3. Date/Time Formats 804 3.3.1. Full Date 806 HTTP applications have historically allowed three different formats 807 for the representation of date/time stamps: 809 Sun, 06 Nov 1994 08:49:37 GMT ; RFC 822, updated by RFC 1123 810 Sunday, 06-Nov-94 08:49:37 GMT ; obsolete RFC 850 format 811 Sun Nov 6 08:49:37 1994 ; ANSI C's asctime() format 813 The first format is preferred as an Internet standard and represents 814 a fixed-length subset of that defined by [RFC1123] (an update to 815 [RFC822]). The other formats are described here only for 816 compatibility with obsolete implementations. HTTP/1.1 clients and 817 servers that parse the date value MUST accept all three formats (for 818 compatibility with HTTP/1.0), though they MUST only generate the RFC 819 1123 format for representing HTTP-date values in header fields. See 820 Appendix B for further information. 822 Note: Recipients of date values are encouraged to be robust in 823 accepting date values that may have been sent by non-HTTP 824 applications, as is sometimes the case when retrieving or posting 825 messages via proxies/gateways to SMTP or NNTP. 827 All HTTP date/time stamps MUST be represented in Greenwich Mean Time 828 (GMT), without exception. For the purposes of HTTP, GMT is exactly 829 equal to UTC (Coordinated Universal Time). This is indicated in the 830 first two formats by the inclusion of "GMT" as the three-letter 831 abbreviation for time zone, and MUST be assumed when reading the 832 asctime format. HTTP-date is case sensitive and MUST NOT include 833 additional LWS beyond that specifically included as SP in the 834 grammar. 836 HTTP-date = rfc1123-date | rfc850-date | asctime-date 837 rfc1123-date = wkday "," SP date1 SP time SP "GMT" 838 rfc850-date = weekday "," SP date2 SP time SP "GMT" 839 asctime-date = wkday SP date3 SP time SP 4DIGIT 840 date1 = 2DIGIT SP month SP 4DIGIT 841 ; day month year (e.g., 02 Jun 1982) 842 date2 = 2DIGIT "-" month "-" 2DIGIT 843 ; day-month-year (e.g., 02-Jun-82) 844 date3 = month SP ( 2DIGIT | ( SP 1DIGIT )) 845 ; month day (e.g., Jun 2) 846 time = 2DIGIT ":" 2DIGIT ":" 2DIGIT 847 ; 00:00:00 - 23:59:59 848 wkday = "Mon" | "Tue" | "Wed" 849 | "Thu" | "Fri" | "Sat" | "Sun" 850 weekday = "Monday" | "Tuesday" | "Wednesday" 851 | "Thursday" | "Friday" | "Saturday" | "Sunday" 852 month = "Jan" | "Feb" | "Mar" | "Apr" 853 | "May" | "Jun" | "Jul" | "Aug" 854 | "Sep" | "Oct" | "Nov" | "Dec" 856 Note: HTTP requirements for the date/time stamp format apply only to 857 their usage within the protocol stream. Clients and servers are not 858 required to use these formats for user presentation, request logging, 859 etc. 861 3.4. Transfer Codings 863 Transfer-coding values are used to indicate an encoding 864 transformation that has been, can be, or may need to be applied to an 865 entity-body in order to ensure "safe transport" through the network. 866 This differs from a content coding in that the transfer-coding is a 867 property of the message, not of the original entity. 869 transfer-coding = "chunked" | transfer-extension 870 transfer-extension = token *( ";" parameter ) 872 Parameters are in the form of attribute/value pairs. 874 parameter = attribute "=" value 875 attribute = token 876 value = token | quoted-string 878 All transfer-coding values are case-insensitive. HTTP/1.1 uses 879 transfer-coding values in the TE header field (Section 8.5) and in 880 the Transfer-Encoding header field (Section 8.7). 882 Whenever a transfer-coding is applied to a message-body, the set of 883 transfer-codings MUST include "chunked", unless the message is 884 terminated by closing the connection. When the "chunked" transfer- 885 coding is used, it MUST be the last transfer-coding applied to the 886 message-body. The "chunked" transfer-coding MUST NOT be applied more 887 than once to a message-body. These rules allow the recipient to 888 determine the transfer-length of the message (Section 4.4). 890 Transfer-codings are analogous to the Content-Transfer-Encoding 891 values of MIME [RFC2045], which were designed to enable safe 892 transport of binary data over a 7-bit transport service. However, 893 safe transport has a different focus for an 8bit-clean transfer 894 protocol. In HTTP, the only unsafe characteristic of message-bodies 895 is the difficulty in determining the exact body length (Section 4.4), 896 or the desire to encrypt data over a shared transport. 898 The Internet Assigned Numbers Authority (IANA) acts as a registry for 899 transfer-coding value tokens. Initially, the registry contains the 900 following tokens: "chunked" (Section 3.4.1), "gzip", "compress", and 901 "deflate" (Section 2.2 of [Part3]). 903 New transfer-coding value tokens SHOULD be registered in the same way 904 as new content-coding value tokens (Section 2.2 of [Part3]). 906 A server which receives an entity-body with a transfer-coding it does 907 not understand SHOULD return 501 (Not Implemented), and close the 908 connection. A server MUST NOT send transfer-codings to an HTTP/1.0 909 client. 911 3.4.1. Chunked Transfer Coding 913 The chunked encoding modifies the body of a message in order to 914 transfer it as a series of chunks, each with its own size indicator, 915 followed by an OPTIONAL trailer containing entity-header fields. 916 This allows dynamically produced content to be transferred along with 917 the information necessary for the recipient to verify that it has 918 received the full message. 920 Chunked-Body = *chunk 921 last-chunk 922 trailer 923 CRLF 925 chunk = chunk-size [ chunk-extension ] CRLF 926 chunk-data CRLF 927 chunk-size = 1*HEX 928 last-chunk = 1*("0") [ chunk-extension ] CRLF 930 chunk-extension= *( ";" chunk-ext-name [ "=" chunk-ext-val ] ) 931 chunk-ext-name = token 932 chunk-ext-val = token | quoted-string 933 chunk-data = 1*OCTET ; a sequence of chunk-size octets 934 trailer = *(entity-header CRLF) 936 The chunk-size field is a string of hex digits indicating the size of 937 the chunk-data in octets. The chunked encoding is ended by any chunk 938 whose size is zero, followed by the trailer, which is terminated by 939 an empty line. 941 The trailer allows the sender to include additional HTTP header 942 fields at the end of the message. The Trailer header field can be 943 used to indicate which header fields are included in a trailer (see 944 Section 8.6). 946 A server using chunked transfer-coding in a response MUST NOT use the 947 trailer for any header fields unless at least one of the following is 948 true: 950 1. the request included a TE header field that indicates "trailers" 951 is acceptable in the transfer-coding of the response, as 952 described in Section 8.5; or, 954 2. the server is the origin server for the response, the trailer 955 fields consist entirely of optional metadata, and the recipient 956 could use the message (in a manner acceptable to the origin 957 server) without receiving this metadata. In other words, the 958 origin server is willing to accept the possibility that the 959 trailer fields might be silently discarded along the path to the 960 client. 962 This requirement prevents an interoperability failure when the 963 message is being received by an HTTP/1.1 (or later) proxy and 964 forwarded to an HTTP/1.0 recipient. It avoids a situation where 965 compliance with the protocol would have necessitated a possibly 966 infinite buffer on the proxy. 968 A process for decoding the "chunked" transfer-coding can be 969 represented in pseudo-code as: 971 length := 0 972 read chunk-size, chunk-extension (if any) and CRLF 973 while (chunk-size > 0) { 974 read chunk-data and CRLF 975 append chunk-data to entity-body 976 length := length + chunk-size 977 read chunk-size and CRLF 978 } 979 read entity-header 980 while (entity-header not empty) { 981 append entity-header to existing header fields 982 read entity-header 983 } 984 Content-Length := length 985 Remove "chunked" from Transfer-Encoding 987 All HTTP/1.1 applications MUST be able to receive and decode the 988 "chunked" transfer-coding, and MUST ignore chunk-extension extensions 989 they do not understand. 991 4. HTTP Message 993 4.1. Message Types 995 HTTP messages consist of requests from client to server and responses 996 from server to client. 998 HTTP-message = Request | Response ; HTTP/1.1 messages 1000 Request (Section 5) and Response (Section 6) messages use the generic 1001 message format of [RFC2822] for transferring entities (the payload of 1002 the message). Both types of message consist of a start-line, zero or 1003 more header fields (also known as "headers"), an empty line (i.e., a 1004 line with nothing preceding the CRLF) indicating the end of the 1005 header fields, and possibly a message-body. 1007 generic-message = start-line 1008 *(message-header CRLF) 1009 CRLF 1010 [ message-body ] 1011 start-line = Request-Line | Status-Line 1013 In the interest of robustness, servers SHOULD ignore any empty 1014 line(s) received where a Request-Line is expected. In other words, 1015 if the server is reading the protocol stream at the beginning of a 1016 message and receives a CRLF first, it should ignore the CRLF. 1018 Certain buggy HTTP/1.0 client implementations generate extra CRLF's 1019 after a POST request. To restate what is explicitly forbidden by the 1020 BNF, an HTTP/1.1 client MUST NOT preface or follow a request with an 1021 extra CRLF. 1023 4.2. Message Headers 1025 HTTP header fields, which include general-header (Section 4.5), 1026 request-header (Section 4 of [Part2]), response-header (Section 6 of 1027 [Part2]), and entity-header (Section 3.1 of [Part3]) fields, follow 1028 the same generic format as that given in Section 2.1 of [RFC2822]. 1029 Each header field consists of a name followed by a colon (":") and 1030 the field value. Field names are case-insensitive. The field value 1031 MAY be preceded by any amount of LWS, though a single SP is 1032 preferred. Header fields can be extended over multiple lines by 1033 preceding each extra line with at least one SP or HTAB. Applications 1034 ought to follow "common form", where one is known or indicated, when 1035 generating HTTP constructs, since there might exist some 1036 implementations that fail to accept anything beyond the common forms. 1038 message-header = field-name ":" [ field-value ] 1039 field-name = token 1040 field-value = *( field-content | LWS ) 1041 field-content = 1045 The field-content does not include any leading or trailing LWS: 1046 linear white space occurring before the first non-whitespace 1047 character of the field-value or after the last non-whitespace 1048 character of the field-value. Such leading or trailing LWS MAY be 1049 removed without changing the semantics of the field value. Any LWS 1050 that occurs between field-content MAY be replaced with a single SP 1051 before interpreting the field value or forwarding the message 1052 downstream. 1054 The order in which header fields with differing field names are 1055 received is not significant. However, it is "good practice" to send 1056 general-header fields first, followed by request-header or response- 1057 header fields, and ending with the entity-header fields. 1059 Multiple message-header fields with the same field-name MAY be 1060 present in a message if and only if the entire field-value for that 1061 header field is defined as a comma-separated list [i.e., #(values)]. 1062 It MUST be possible to combine the multiple header fields into one 1063 "field-name: field-value" pair, without changing the semantics of the 1064 message, by appending each subsequent field-value to the first, each 1065 separated by a comma. The order in which header fields with the same 1066 field-name are received is therefore significant to the 1067 interpretation of the combined field value, and thus a proxy MUST NOT 1068 change the order of these field values when a message is forwarded. 1070 4.3. Message Body 1072 The message-body (if any) of an HTTP message is used to carry the 1073 entity-body associated with the request or response. The message- 1074 body differs from the entity-body only when a transfer-coding has 1075 been applied, as indicated by the Transfer-Encoding header field 1076 (Section 8.7). 1078 message-body = entity-body 1079 | 1081 Transfer-Encoding MUST be used to indicate any transfer-codings 1082 applied by an application to ensure safe and proper transfer of the 1083 message. Transfer-Encoding is a property of the message, not of the 1084 entity, and thus MAY be added or removed by any application along the 1085 request/response chain. (However, Section 3.4 places restrictions on 1086 when certain transfer-codings may be used.) 1088 The rules for when a message-body is allowed in a message differ for 1089 requests and responses. 1091 The presence of a message-body in a request is signaled by the 1092 inclusion of a Content-Length or Transfer-Encoding header field in 1093 the request's message-headers. A message-body MUST NOT be included 1094 in a request if the specification of the request method (Section 3 of 1095 [Part2]) does not allow sending an entity-body in requests. A server 1096 SHOULD read and forward a message-body on any request; if the request 1097 method does not include defined semantics for an entity-body, then 1098 the message-body SHOULD be ignored when handling the request. 1100 For response messages, whether or not a message-body is included with 1101 a message is dependent on both the request method and the response 1102 status code (Section 6.1.1). All responses to the HEAD request 1103 method MUST NOT include a message-body, even though the presence of 1104 entity-header fields might lead one to believe they do. All 1xx 1105 (informational), 204 (No Content), and 304 (Not Modified) responses 1106 MUST NOT include a message-body. All other responses do include a 1107 message-body, although it MAY be of zero length. 1109 4.4. Message Length 1111 The transfer-length of a message is the length of the message-body as 1112 it appears in the message; that is, after any transfer-codings have 1113 been applied. When a message-body is included with a message, the 1114 transfer-length of that body is determined by one of the following 1115 (in order of precedence): 1117 1. Any response message which "MUST NOT" include a message-body 1118 (such as the 1xx, 204, and 304 responses and any response to a 1119 HEAD request) is always terminated by the first empty line after 1120 the header fields, regardless of the entity-header fields present 1121 in the message. 1123 2. If a Transfer-Encoding header field (Section 8.7) is present, 1124 then the transfer-length is defined by use of the "chunked" 1125 transfer-coding (Section 3.4), unless the message is terminated 1126 by closing the connection. 1128 3. If a Content-Length header field (Section 8.2) is present, its 1129 decimal value in OCTETs represents both the entity-length and the 1130 transfer-length. The Content-Length header field MUST NOT be 1131 sent if these two lengths are different (i.e., if a Transfer- 1132 Encoding header field is present). If a message is received with 1133 both a Transfer-Encoding header field and a Content-Length header 1134 field, the latter MUST be ignored. 1136 4. If the message uses the media type "multipart/byteranges", and 1137 the transfer-length is not otherwise specified, then this self- 1138 delimiting media type defines the transfer-length. This media 1139 type MUST NOT be used unless the sender knows that the recipient 1140 can parse it; the presence in a request of a Range header with 1141 multiple byte-range specifiers from a 1.1 client implies that the 1142 client can parse multipart/byteranges responses. 1144 A range header might be forwarded by a 1.0 proxy that does not 1145 understand multipart/byteranges; in this case the server MUST 1146 delimit the message using methods defined in items 1, 3 or 5 1147 of this section. 1149 5. By the server closing the connection. (Closing the connection 1150 cannot be used to indicate the end of a request body, since that 1151 would leave no possibility for the server to send back a 1152 response.) 1154 For compatibility with HTTP/1.0 applications, HTTP/1.1 requests 1155 containing a message-body MUST include a valid Content-Length header 1156 field unless the server is known to be HTTP/1.1 compliant. If a 1157 request contains a message-body and a Content-Length is not given, 1158 the server SHOULD respond with 400 (Bad Request) if it cannot 1159 determine the length of the message, or with 411 (Length Required) if 1160 it wishes to insist on receiving a valid Content-Length. 1162 All HTTP/1.1 applications that receive entities MUST accept the 1163 "chunked" transfer-coding (Section 3.4), thus allowing this mechanism 1164 to be used for messages when the message length cannot be determined 1165 in advance. 1167 Messages MUST NOT include both a Content-Length header field and a 1168 transfer-coding. If the message does include a transfer-coding, the 1169 Content-Length MUST be ignored. 1171 When a Content-Length is given in a message where a message-body is 1172 allowed, its field value MUST exactly match the number of OCTETs in 1173 the message-body. HTTP/1.1 user agents MUST notify the user when an 1174 invalid length is received and detected. 1176 4.5. General Header Fields 1178 There are a few header fields which have general applicability for 1179 both request and response messages, but which do not apply to the 1180 entity being transferred. These header fields apply only to the 1181 message being transmitted. 1183 general-header = Cache-Control ; [Part6], Section 15.2 1184 | Connection ; Section 8.1 1185 | Date ; Section 8.3 1186 | Pragma ; [Part6], Section 15.4 1187 | Trailer ; Section 8.6 1188 | Transfer-Encoding ; Section 8.7 1189 | Upgrade ; Section 8.8 1190 | Via ; Section 8.9 1191 | Warning ; [Part6], Section 15.6 1193 General-header field names can be extended reliably only in 1194 combination with a change in the protocol version. However, new or 1195 experimental header fields may be given the semantics of general 1196 header fields if all parties in the communication recognize them to 1197 be general-header fields. Unrecognized header fields are treated as 1198 entity-header fields. 1200 5. Request 1202 A request message from a client to a server includes, within the 1203 first line of that message, the method to be applied to the resource, 1204 the identifier of the resource, and the protocol version in use. 1206 Request = Request-Line ; Section 5.1 1207 *(( general-header ; Section 4.5 1208 | request-header ; [Part2], Section 4 1209 | entity-header ) CRLF) ; [Part3], Section 3.1 1210 CRLF 1211 [ message-body ] ; Section 4.3 1213 5.1. Request-Line 1215 The Request-Line begins with a method token, followed by the Request- 1216 URI and the protocol version, and ending with CRLF. The elements are 1217 separated by SP characters. No CR or LF is allowed except in the 1218 final CRLF sequence. 1220 Request-Line = Method SP Request-URI SP HTTP-Version CRLF 1222 5.1.1. Method 1224 The Method token indicates the method to be performed on the resource 1225 identified by the Request-URI. The method is case-sensitive. 1227 Method = token 1229 5.1.2. Request-URI 1231 The Request-URI is a Uniform Resource Identifier (Section 3.2) and 1232 identifies the resource upon which to apply the request. 1234 Request-URI = "*" 1235 | absoluteURI 1236 | ( abs_path [ "?" query ] ) 1237 | authority 1239 The four options for Request-URI are dependent on the nature of the 1240 request. The asterisk "*" means that the request does not apply to a 1241 particular resource, but to the server itself, and is only allowed 1242 when the method used does not necessarily apply to a resource. One 1243 example would be 1245 OPTIONS * HTTP/1.1 1247 The absoluteURI form is REQUIRED when the request is being made to a 1248 proxy. The proxy is requested to forward the request or service it 1249 from a valid cache, and return the response. Note that the proxy MAY 1250 forward the request on to another proxy or directly to the server 1251 specified by the absoluteURI. In order to avoid request loops, a 1252 proxy MUST be able to recognize all of its server names, including 1253 any aliases, local variations, and the numeric IP address. An 1254 example Request-Line would be: 1256 GET http://www.example.org/pub/WWW/TheProject.html HTTP/1.1 1258 To allow for transition to absoluteURIs in all requests in future 1259 versions of HTTP, all HTTP/1.1 servers MUST accept the absoluteURI 1260 form in requests, even though HTTP/1.1 clients will only generate 1261 them in requests to proxies. 1263 The authority form is only used by the CONNECT method (Section 8.9 of 1264 [Part2]). 1266 The most common form of Request-URI is that used to identify a 1267 resource on an origin server or gateway. In this case the absolute 1268 path of the URI MUST be transmitted (see Section 3.2.1, abs_path) as 1269 the Request-URI, and the network location of the URI (authority) MUST 1270 be transmitted in a Host header field. For example, a client wishing 1271 to retrieve the resource above directly from the origin server would 1272 create a TCP connection to port 80 of the host "www.example.org" and 1273 send the lines: 1275 GET /pub/WWW/TheProject.html HTTP/1.1 1276 Host: www.example.org 1278 followed by the remainder of the Request. Note that the absolute 1279 path cannot be empty; if none is present in the original URI, it MUST 1280 be given as "/" (the server root). 1282 The Request-URI is transmitted in the format specified in 1283 Section 3.2.1. If the Request-URI is encoded using the "% HEX HEX" 1284 encoding [RFC2396], the origin server MUST decode the Request-URI in 1285 order to properly interpret the request. Servers SHOULD respond to 1286 invalid Request-URIs with an appropriate status code. 1288 A transparent proxy MUST NOT rewrite the "abs_path" part of the 1289 received Request-URI when forwarding it to the next inbound server, 1290 except as noted above to replace a null abs_path with "/". 1292 Note: The "no rewrite" rule prevents the proxy from changing the 1293 meaning of the request when the origin server is improperly using 1294 a non-reserved URI character for a reserved purpose. Implementors 1295 should be aware that some pre-HTTP/1.1 proxies have been known to 1296 rewrite the Request-URI. 1298 5.2. The Resource Identified by a Request 1300 The exact resource identified by an Internet request is determined by 1301 examining both the Request-URI and the Host header field. 1303 An origin server that does not allow resources to differ by the 1304 requested host MAY ignore the Host header field value when 1305 determining the resource identified by an HTTP/1.1 request. (But see 1306 Appendix D.1.1 for other requirements on Host support in HTTP/1.1.) 1308 An origin server that does differentiate resources based on the host 1309 requested (sometimes referred to as virtual hosts or vanity host 1310 names) MUST use the following rules for determining the requested 1311 resource on an HTTP/1.1 request: 1313 1. If Request-URI is an absoluteURI, the host is part of the 1314 Request-URI. Any Host header field value in the request MUST be 1315 ignored. 1317 2. If the Request-URI is not an absoluteURI, and the request 1318 includes a Host header field, the host is determined by the Host 1319 header field value. 1321 3. If the host as determined by rule 1 or 2 is not a valid host on 1322 the server, the response MUST be a 400 (Bad Request) error 1323 message. 1325 Recipients of an HTTP/1.0 request that lacks a Host header field MAY 1326 attempt to use heuristics (e.g., examination of the URI path for 1327 something unique to a particular host) in order to determine what 1328 exact resource is being requested. 1330 6. Response 1332 After receiving and interpreting a request message, a server responds 1333 with an HTTP response message. 1335 Response = Status-Line ; Section 6.1 1336 *(( general-header ; Section 4.5 1337 | response-header ; [Part2], Section 6 1338 | entity-header ) CRLF) ; [Part3], Section 3.1 1339 CRLF 1340 [ message-body ] ; Section 4.3 1342 6.1. Status-Line 1344 The first line of a Response message is the Status-Line, consisting 1345 of the protocol version followed by a numeric status code and its 1346 associated textual phrase, with each element separated by SP 1347 characters. No CR or LF is allowed except in the final CRLF 1348 sequence. 1350 Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF 1352 6.1.1. Status Code and Reason Phrase 1354 The Status-Code element is a 3-digit integer result code of the 1355 attempt to understand and satisfy the request. These codes are fully 1356 defined in Section 9 of [Part2]. The Reason-Phrase is intended to 1357 give a short textual description of the Status-Code. The Status-Code 1358 is intended for use by automata and the Reason-Phrase is intended for 1359 the human user. The client is not required to examine or display the 1360 Reason-Phrase. 1362 The first digit of the Status-Code defines the class of response. 1363 The last two digits do not have any categorization role. There are 5 1364 values for the first digit: 1366 o 1xx: Informational - Request received, continuing process 1368 o 2xx: Success - The action was successfully received, understood, 1369 and accepted 1371 o 3xx: Redirection - Further action must be taken in order to 1372 complete the request 1374 o 4xx: Client Error - The request contains bad syntax or cannot be 1375 fulfilled 1377 o 5xx: Server Error - The server failed to fulfill an apparently 1378 valid request 1380 Status-Code = 3DIGIT 1381 Reason-Phrase = * 1383 7. Connections 1384 7.1. Persistent Connections 1386 7.1.1. Purpose 1388 Prior to persistent connections, a separate TCP connection was 1389 established to fetch each URL, increasing the load on HTTP servers 1390 and causing congestion on the Internet. The use of inline images and 1391 other associated data often require a client to make multiple 1392 requests of the same server in a short amount of time. Analysis of 1393 these performance problems and results from a prototype 1394 implementation are available [Pad1995] [Spe]. Implementation 1395 experience and measurements of actual HTTP/1.1 (RFC 2068) 1396 implementations show good results [Nie1997]. Alternatives have also 1397 been explored, for example, T/TCP [Tou1998]. 1399 Persistent HTTP connections have a number of advantages: 1401 o By opening and closing fewer TCP connections, CPU time is saved in 1402 routers and hosts (clients, servers, proxies, gateways, tunnels, 1403 or caches), and memory used for TCP protocol control blocks can be 1404 saved in hosts. 1406 o HTTP requests and responses can be pipelined on a connection. 1407 Pipelining allows a client to make multiple requests without 1408 waiting for each response, allowing a single TCP connection to be 1409 used much more efficiently, with much lower elapsed time. 1411 o Network congestion is reduced by reducing the number of packets 1412 caused by TCP opens, and by allowing TCP sufficient time to 1413 determine the congestion state of the network. 1415 o Latency on subsequent requests is reduced since there is no time 1416 spent in TCP's connection opening handshake. 1418 o HTTP can evolve more gracefully, since errors can be reported 1419 without the penalty of closing the TCP connection. Clients using 1420 future versions of HTTP might optimistically try a new feature, 1421 but if communicating with an older server, retry with old 1422 semantics after an error is reported. 1424 HTTP implementations SHOULD implement persistent connections. 1426 7.1.2. Overall Operation 1428 A significant difference between HTTP/1.1 and earlier versions of 1429 HTTP is that persistent connections are the default behavior of any 1430 HTTP connection. That is, unless otherwise indicated, the client 1431 SHOULD assume that the server will maintain a persistent connection, 1432 even after error responses from the server. 1434 Persistent connections provide a mechanism by which a client and a 1435 server can signal the close of a TCP connection. This signaling 1436 takes place using the Connection header field (Section 8.1). Once a 1437 close has been signaled, the client MUST NOT send any more requests 1438 on that connection. 1440 7.1.2.1. Negotiation 1442 An HTTP/1.1 server MAY assume that a HTTP/1.1 client intends to 1443 maintain a persistent connection unless a Connection header including 1444 the connection-token "close" was sent in the request. If the server 1445 chooses to close the connection immediately after sending the 1446 response, it SHOULD send a Connection header including the 1447 connection-token close. 1449 An HTTP/1.1 client MAY expect a connection to remain open, but would 1450 decide to keep it open based on whether the response from a server 1451 contains a Connection header with the connection-token close. In 1452 case the client does not want to maintain a connection for more than 1453 that request, it SHOULD send a Connection header including the 1454 connection-token close. 1456 If either the client or the server sends the close token in the 1457 Connection header, that request becomes the last one for the 1458 connection. 1460 Clients and servers SHOULD NOT assume that a persistent connection is 1461 maintained for HTTP versions less than 1.1 unless it is explicitly 1462 signaled. See Appendix D.2 for more information on backward 1463 compatibility with HTTP/1.0 clients. 1465 In order to remain persistent, all messages on the connection MUST 1466 have a self-defined message length (i.e., one not defined by closure 1467 of the connection), as described in Section 4.4. 1469 7.1.2.2. Pipelining 1471 A client that supports persistent connections MAY "pipeline" its 1472 requests (i.e., send multiple requests without waiting for each 1473 response). A server MUST send its responses to those requests in the 1474 same order that the requests were received. 1476 Clients which assume persistent connections and pipeline immediately 1477 after connection establishment SHOULD be prepared to retry their 1478 connection if the first pipelined attempt fails. If a client does 1479 such a retry, it MUST NOT pipeline before it knows the connection is 1480 persistent. Clients MUST also be prepared to resend their requests 1481 if the server closes the connection before sending all of the 1482 corresponding responses. 1484 Clients SHOULD NOT pipeline requests using non-idempotent methods or 1485 non-idempotent sequences of methods (see Section 8.1.2 of [Part2]). 1486 Otherwise, a premature termination of the transport connection could 1487 lead to indeterminate results. A client wishing to send a non- 1488 idempotent request SHOULD wait to send that request until it has 1489 received the response status for the previous request. 1491 7.1.3. Proxy Servers 1493 It is especially important that proxies correctly implement the 1494 properties of the Connection header field as specified in 1495 Section 8.1. 1497 The proxy server MUST signal persistent connections separately with 1498 its clients and the origin servers (or other proxy servers) that it 1499 connects to. Each persistent connection applies to only one 1500 transport link. 1502 A proxy server MUST NOT establish a HTTP/1.1 persistent connection 1503 with an HTTP/1.0 client (but see [RFC2068] for information and 1504 discussion of the problems with the Keep-Alive header implemented by 1505 many HTTP/1.0 clients). 1507 7.1.4. Practical Considerations 1509 Servers will usually have some time-out value beyond which they will 1510 no longer maintain an inactive connection. Proxy servers might make 1511 this a higher value since it is likely that the client will be making 1512 more connections through the same server. The use of persistent 1513 connections places no requirements on the length (or existence) of 1514 this time-out for either the client or the server. 1516 When a client or server wishes to time-out it SHOULD issue a graceful 1517 close on the transport connection. Clients and servers SHOULD both 1518 constantly watch for the other side of the transport close, and 1519 respond to it as appropriate. If a client or server does not detect 1520 the other side's close promptly it could cause unnecessary resource 1521 drain on the network. 1523 A client, server, or proxy MAY close the transport connection at any 1524 time. For example, a client might have started to send a new request 1525 at the same time that the server has decided to close the "idle" 1526 connection. From the server's point of view, the connection is being 1527 closed while it was idle, but from the client's point of view, a 1528 request is in progress. 1530 This means that clients, servers, and proxies MUST be able to recover 1531 from asynchronous close events. Client software SHOULD reopen the 1532 transport connection and retransmit the aborted sequence of requests 1533 without user interaction so long as the request sequence is 1534 idempotent (see Section 8.1.2 of [Part2]). Non-idempotent methods or 1535 sequences MUST NOT be automatically retried, although user agents MAY 1536 offer a human operator the choice of retrying the request(s). 1537 Confirmation by user-agent software with semantic understanding of 1538 the application MAY substitute for user confirmation. The automatic 1539 retry SHOULD NOT be repeated if the second sequence of requests 1540 fails. 1542 Servers SHOULD always respond to at least one request per connection, 1543 if at all possible. Servers SHOULD NOT close a connection in the 1544 middle of transmitting a response, unless a network or client failure 1545 is suspected. 1547 Clients that use persistent connections SHOULD limit the number of 1548 simultaneous connections that they maintain to a given server. A 1549 single-user client SHOULD NOT maintain more than 2 connections with 1550 any server or proxy. A proxy SHOULD use up to 2*N connections to 1551 another server or proxy, where N is the number of simultaneously 1552 active users. These guidelines are intended to improve HTTP response 1553 times and avoid congestion. 1555 7.2. Message Transmission Requirements 1557 7.2.1. Persistent Connections and Flow Control 1559 HTTP/1.1 servers SHOULD maintain persistent connections and use TCP's 1560 flow control mechanisms to resolve temporary overloads, rather than 1561 terminating connections with the expectation that clients will retry. 1562 The latter technique can exacerbate network congestion. 1564 7.2.2. Monitoring Connections for Error Status Messages 1566 An HTTP/1.1 (or later) client sending a message-body SHOULD monitor 1567 the network connection for an error status while it is transmitting 1568 the request. If the client sees an error status, it SHOULD 1569 immediately cease transmitting the body. If the body is being sent 1570 using a "chunked" encoding (Section 3.4), a zero length chunk and 1571 empty trailer MAY be used to prematurely mark the end of the message. 1572 If the body was preceded by a Content-Length header, the client MUST 1573 close the connection. 1575 7.2.3. Use of the 100 (Continue) Status 1577 The purpose of the 100 (Continue) status (see Section 9.1.1 of 1578 [Part2]) is to allow a client that is sending a request message with 1579 a request body to determine if the origin server is willing to accept 1580 the request (based on the request headers) before the client sends 1581 the request body. In some cases, it might either be inappropriate or 1582 highly inefficient for the client to send the body if the server will 1583 reject the message without looking at the body. 1585 Requirements for HTTP/1.1 clients: 1587 o If a client will wait for a 100 (Continue) response before sending 1588 the request body, it MUST send an Expect request-header field 1589 (Section 10.2 of [Part2]) with the "100-continue" expectation. 1591 o A client MUST NOT send an Expect request-header field (Section 1592 10.2 of [Part2]) with the "100-continue" expectation if it does 1593 not intend to send a request body. 1595 Because of the presence of older implementations, the protocol allows 1596 ambiguous situations in which a client may send "Expect: 100- 1597 continue" without receiving either a 417 (Expectation Failed) status 1598 or a 100 (Continue) status. Therefore, when a client sends this 1599 header field to an origin server (possibly via a proxy) from which it 1600 has never seen a 100 (Continue) status, the client SHOULD NOT wait 1601 for an indefinite period before sending the request body. 1603 Requirements for HTTP/1.1 origin servers: 1605 o Upon receiving a request which includes an Expect request-header 1606 field with the "100-continue" expectation, an origin server MUST 1607 either respond with 100 (Continue) status and continue to read 1608 from the input stream, or respond with a final status code. The 1609 origin server MUST NOT wait for the request body before sending 1610 the 100 (Continue) response. If it responds with a final status 1611 code, it MAY close the transport connection or it MAY continue to 1612 read and discard the rest of the request. It MUST NOT perform the 1613 requested method if it returns a final status code. 1615 o An origin server SHOULD NOT send a 100 (Continue) response if the 1616 request message does not include an Expect request-header field 1617 with the "100-continue" expectation, and MUST NOT send a 100 1618 (Continue) response if such a request comes from an HTTP/1.0 (or 1619 earlier) client. There is an exception to this rule: for 1620 compatibility with [RFC2068], a server MAY send a 100 (Continue) 1621 status in response to an HTTP/1.1 PUT or POST request that does 1622 not include an Expect request-header field with the "100-continue" 1623 expectation. This exception, the purpose of which is to minimize 1624 any client processing delays associated with an undeclared wait 1625 for 100 (Continue) status, applies only to HTTP/1.1 requests, and 1626 not to requests with any other HTTP-version value. 1628 o An origin server MAY omit a 100 (Continue) response if it has 1629 already received some or all of the request body for the 1630 corresponding request. 1632 o An origin server that sends a 100 (Continue) response MUST 1633 ultimately send a final status code, once the request body is 1634 received and processed, unless it terminates the transport 1635 connection prematurely. 1637 o If an origin server receives a request that does not include an 1638 Expect request-header field with the "100-continue" expectation, 1639 the request includes a request body, and the server responds with 1640 a final status code before reading the entire request body from 1641 the transport connection, then the server SHOULD NOT close the 1642 transport connection until it has read the entire request, or 1643 until the client closes the connection. Otherwise, the client 1644 might not reliably receive the response message. However, this 1645 requirement is not be construed as preventing a server from 1646 defending itself against denial-of-service attacks, or from badly 1647 broken client implementations. 1649 Requirements for HTTP/1.1 proxies: 1651 o If a proxy receives a request that includes an Expect request- 1652 header field with the "100-continue" expectation, and the proxy 1653 either knows that the next-hop server complies with HTTP/1.1 or 1654 higher, or does not know the HTTP version of the next-hop server, 1655 it MUST forward the request, including the Expect header field. 1657 o If the proxy knows that the version of the next-hop server is 1658 HTTP/1.0 or lower, it MUST NOT forward the request, and it MUST 1659 respond with a 417 (Expectation Failed) status. 1661 o Proxies SHOULD maintain a cache recording the HTTP version numbers 1662 received from recently-referenced next-hop servers. 1664 o A proxy MUST NOT forward a 100 (Continue) response if the request 1665 message was received from an HTTP/1.0 (or earlier) client and did 1666 not include an Expect request-header field with the "100-continue" 1667 expectation. This requirement overrides the general rule for 1668 forwarding of 1xx responses (see Section 9.1 of [Part2]). 1670 7.2.4. Client Behavior if Server Prematurely Closes Connection 1672 If an HTTP/1.1 client sends a request which includes a request body, 1673 but which does not include an Expect request-header field with the 1674 "100-continue" expectation, and if the client is not directly 1675 connected to an HTTP/1.1 origin server, and if the client sees the 1676 connection close before receiving any status from the server, the 1677 client SHOULD retry the request. If the client does retry this 1678 request, it MAY use the following "binary exponential backoff" 1679 algorithm to be assured of obtaining a reliable response: 1681 1. Initiate a new connection to the server 1683 2. Transmit the request-headers 1685 3. Initialize a variable R to the estimated round-trip time to the 1686 server (e.g., based on the time it took to establish the 1687 connection), or to a constant value of 5 seconds if the round- 1688 trip time is not available. 1690 4. Compute T = R * (2**N), where N is the number of previous retries 1691 of this request. 1693 5. Wait either for an error response from the server, or for T 1694 seconds (whichever comes first) 1696 6. If no error response is received, after T seconds transmit the 1697 body of the request. 1699 7. If client sees that the connection is closed prematurely, repeat 1700 from step 1 until the request is accepted, an error response is 1701 received, or the user becomes impatient and terminates the retry 1702 process. 1704 If at any point an error status is received, the client 1706 o SHOULD NOT continue and 1708 o SHOULD close the connection if it has not completed sending the 1709 request message. 1711 8. Header Field Definitions 1713 This section defines the syntax and semantics of HTTP/1.1 header 1714 fields related to message framing and transport protocols. 1716 For entity-header fields, both sender and recipient refer to either 1717 the client or the server, depending on who sends and who receives the 1718 entity. 1720 8.1. Connection 1722 The Connection general-header field allows the sender to specify 1723 options that are desired for that particular connection and MUST NOT 1724 be communicated by proxies over further connections. 1726 The Connection header has the following grammar: 1728 Connection = "Connection" ":" 1#(connection-token) 1729 connection-token = token 1731 HTTP/1.1 proxies MUST parse the Connection header field before a 1732 message is forwarded and, for each connection-token in this field, 1733 remove any header field(s) from the message with the same name as the 1734 connection-token. Connection options are signaled by the presence of 1735 a connection-token in the Connection header field, not by any 1736 corresponding additional header field(s), since the additional header 1737 field may not be sent if there are no parameters associated with that 1738 connection option. 1740 Message headers listed in the Connection header MUST NOT include end- 1741 to-end headers, such as Cache-Control. 1743 HTTP/1.1 defines the "close" connection option for the sender to 1744 signal that the connection will be closed after completion of the 1745 response. For example, 1747 Connection: close 1749 in either the request or the response header fields indicates that 1750 the connection SHOULD NOT be considered `persistent' (Section 7.1) 1751 after the current request/response is complete. 1753 An HTTP/1.1 client that does not support persistent connections MUST 1754 include the "close" connection option in every request message. 1756 An HTTP/1.1 server that does not support persistent connections MUST 1757 include the "close" connection option in every response message that 1758 does not have a 1xx (informational) status code. 1760 A system receiving an HTTP/1.0 (or lower-version) message that 1761 includes a Connection header MUST, for each connection-token in this 1762 field, remove and ignore any header field(s) from the message with 1763 the same name as the connection-token. This protects against 1764 mistaken forwarding of such header fields by pre-HTTP/1.1 proxies. 1766 See Appendix D.2. 1768 8.2. Content-Length 1770 The Content-Length entity-header field indicates the size of the 1771 entity-body, in decimal number of OCTETs, sent to the recipient or, 1772 in the case of the HEAD method, the size of the entity-body that 1773 would have been sent had the request been a GET. 1775 Content-Length = "Content-Length" ":" 1*DIGIT 1777 An example is 1779 Content-Length: 3495 1781 Applications SHOULD use this field to indicate the transfer-length of 1782 the message-body, unless this is prohibited by the rules in 1783 Section 4.4. 1785 Any Content-Length greater than or equal to zero is a valid value. 1786 Section 4.4 describes how to determine the length of a message-body 1787 if a Content-Length is not given. 1789 Note that the meaning of this field is significantly different from 1790 the corresponding definition in MIME, where it is an optional field 1791 used within the "message/external-body" content-type. In HTTP, it 1792 SHOULD be sent whenever the message's length can be determined prior 1793 to being transferred, unless this is prohibited by the rules in 1794 Section 4.4. 1796 8.3. Date 1798 The Date general-header field represents the date and time at which 1799 the message was originated, having the same semantics as orig-date in 1800 Section 3.6.1 of [RFC2822]. The field value is an HTTP-date, as 1801 described in Section 3.3.1; it MUST be sent in rfc1123-date format. 1803 Date = "Date" ":" HTTP-date 1805 An example is 1807 Date: Tue, 15 Nov 1994 08:12:31 GMT 1809 Origin servers MUST include a Date header field in all responses, 1810 except in these cases: 1812 1. If the response status code is 100 (Continue) or 101 (Switching 1813 Protocols), the response MAY include a Date header field, at the 1814 server's option. 1816 2. If the response status code conveys a server error, e.g. 500 1817 (Internal Server Error) or 503 (Service Unavailable), and it is 1818 inconvenient or impossible to generate a valid Date. 1820 3. If the server does not have a clock that can provide a reasonable 1821 approximation of the current time, its responses MUST NOT include 1822 a Date header field. In this case, the rules in Section 8.3.1 1823 MUST be followed. 1825 A received message that does not have a Date header field MUST be 1826 assigned one by the recipient if the message will be cached by that 1827 recipient or gatewayed via a protocol which requires a Date. An HTTP 1828 implementation without a clock MUST NOT cache responses without 1829 revalidating them on every use. An HTTP cache, especially a shared 1830 cache, SHOULD use a mechanism, such as NTP [RFC1305], to synchronize 1831 its clock with a reliable external standard. 1833 Clients SHOULD only send a Date header field in messages that include 1834 an entity-body, as in the case of the PUT and POST requests, and even 1835 then it is optional. A client without a clock MUST NOT send a Date 1836 header field in a request. 1838 The HTTP-date sent in a Date header SHOULD NOT represent a date and 1839 time subsequent to the generation of the message. It SHOULD 1840 represent the best available approximation of the date and time of 1841 message generation, unless the implementation has no means of 1842 generating a reasonably accurate date and time. In theory, the date 1843 ought to represent the moment just before the entity is generated. 1844 In practice, the date can be generated at any time during the message 1845 origination without affecting its semantic value. 1847 8.3.1. Clockless Origin Server Operation 1849 Some origin server implementations might not have a clock available. 1850 An origin server without a clock MUST NOT assign Expires or Last- 1851 Modified values to a response, unless these values were associated 1852 with the resource by a system or user with a reliable clock. It MAY 1853 assign an Expires value that is known, at or before server 1854 configuration time, to be in the past (this allows "pre-expiration" 1855 of responses without storing separate Expires values for each 1856 resource). 1858 8.4. Host 1860 The Host request-header field specifies the Internet host and port 1861 number of the resource being requested, as obtained from the original 1862 URI given by the user or referring resource (generally an HTTP URL, 1863 as described in Section 3.2.2). The Host field value MUST represent 1864 the naming authority of the origin server or gateway given by the 1865 original URL. This allows the origin server or gateway to 1866 differentiate between internally-ambiguous URLs, such as the root "/" 1867 URL of a server for multiple host names on a single IP address. 1869 Host = "Host" ":" host [ ":" port ] ; Section 3.2.2 1871 A "host" without any trailing port information implies the default 1872 port for the service requested (e.g., "80" for an HTTP URL). For 1873 example, a request on the origin server for 1874 would properly include: 1876 GET /pub/WWW/ HTTP/1.1 1877 Host: www.example.org 1879 A client MUST include a Host header field in all HTTP/1.1 request 1880 messages. If the requested URI does not include an Internet host 1881 name for the service being requested, then the Host header field MUST 1882 be given with an empty value. An HTTP/1.1 proxy MUST ensure that any 1883 request message it forwards does contain an appropriate Host header 1884 field that identifies the service being requested by the proxy. All 1885 Internet-based HTTP/1.1 servers MUST respond with a 400 (Bad Request) 1886 status code to any HTTP/1.1 request message which lacks a Host header 1887 field. 1889 See Sections 5.2 and D.1.1 for other requirements relating to Host. 1891 8.5. TE 1893 The TE request-header field indicates what extension transfer-codings 1894 it is willing to accept in the response and whether or not it is 1895 willing to accept trailer fields in a chunked transfer-coding. Its 1896 value may consist of the keyword "trailers" and/or a comma-separated 1897 list of extension transfer-coding names with optional accept 1898 parameters (as described in Section 3.4). 1900 TE = "TE" ":" #( t-codings ) 1901 t-codings = "trailers" | ( transfer-extension [ accept-params ] ) 1903 The presence of the keyword "trailers" indicates that the client is 1904 willing to accept trailer fields in a chunked transfer-coding, as 1905 defined in Section 3.4.1. This keyword is reserved for use with 1906 transfer-coding values even though it does not itself represent a 1907 transfer-coding. 1909 Examples of its use are: 1911 TE: deflate 1912 TE: 1913 TE: trailers, deflate;q=0.5 1915 The TE header field only applies to the immediate connection. 1916 Therefore, the keyword MUST be supplied within a Connection header 1917 field (Section 8.1) whenever TE is present in an HTTP/1.1 message. 1919 A server tests whether a transfer-coding is acceptable, according to 1920 a TE field, using these rules: 1922 1. The "chunked" transfer-coding is always acceptable. If the 1923 keyword "trailers" is listed, the client indicates that it is 1924 willing to accept trailer fields in the chunked response on 1925 behalf of itself and any downstream clients. The implication is 1926 that, if given, the client is stating that either all downstream 1927 clients are willing to accept trailer fields in the forwarded 1928 response, or that it will attempt to buffer the response on 1929 behalf of downstream recipients. 1931 Note: HTTP/1.1 does not define any means to limit the size of a 1932 chunked response such that a client can be assured of buffering 1933 the entire response. 1935 2. If the transfer-coding being tested is one of the transfer- 1936 codings listed in the TE field, then it is acceptable unless it 1937 is accompanied by a qvalue of 0. (As defined in Section 2.4 of 1938 [Part3], a qvalue of 0 means "not acceptable.") 1940 3. If multiple transfer-codings are acceptable, then the acceptable 1941 transfer-coding with the highest non-zero qvalue is preferred. 1942 The "chunked" transfer-coding always has a qvalue of 1. 1944 If the TE field-value is empty or if no TE field is present, the only 1945 transfer-coding is "chunked". A message with no transfer-coding is 1946 always acceptable. 1948 8.6. Trailer 1950 The Trailer general field value indicates that the given set of 1951 header fields is present in the trailer of a message encoded with 1952 chunked transfer-coding. 1954 Trailer = "Trailer" ":" 1#field-name 1956 An HTTP/1.1 message SHOULD include a Trailer header field in a 1957 message using chunked transfer-coding with a non-empty trailer. 1958 Doing so allows the recipient to know which header fields to expect 1959 in the trailer. 1961 If no Trailer header field is present, the trailer SHOULD NOT include 1962 any header fields. See Section 3.4.1 for restrictions on the use of 1963 trailer fields in a "chunked" transfer-coding. 1965 Message header fields listed in the Trailer header field MUST NOT 1966 include the following header fields: 1968 o Transfer-Encoding 1970 o Content-Length 1972 o Trailer 1974 8.7. Transfer-Encoding 1976 The Transfer-Encoding general-header field indicates what (if any) 1977 type of transformation has been applied to the message body in order 1978 to safely transfer it between the sender and the recipient. This 1979 differs from the content-coding in that the transfer-coding is a 1980 property of the message, not of the entity. 1982 Transfer-Encoding = "Transfer-Encoding" ":" 1#transfer-coding 1984 Transfer-codings are defined in Section 3.4. An example is: 1986 Transfer-Encoding: chunked 1988 If multiple encodings have been applied to an entity, the transfer- 1989 codings MUST be listed in the order in which they were applied. 1990 Additional information about the encoding parameters MAY be provided 1991 by other entity-header fields not defined by this specification. 1993 Many older HTTP/1.0 applications do not understand the Transfer- 1994 Encoding header. 1996 8.8. Upgrade 1998 The Upgrade general-header allows the client to specify what 1999 additional communication protocols it supports and would like to use 2000 if the server finds it appropriate to switch protocols. The server 2001 MUST use the Upgrade header field within a 101 (Switching Protocols) 2002 response to indicate which protocol(s) are being switched. 2004 Upgrade = "Upgrade" ":" 1#product 2006 For example, 2007 Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11 2009 The Upgrade header field is intended to provide a simple mechanism 2010 for transition from HTTP/1.1 to some other, incompatible protocol. 2011 It does so by allowing the client to advertise its desire to use 2012 another protocol, such as a later version of HTTP with a higher major 2013 version number, even though the current request has been made using 2014 HTTP/1.1. This eases the difficult transition between incompatible 2015 protocols by allowing the client to initiate a request in the more 2016 commonly supported protocol while indicating to the server that it 2017 would like to use a "better" protocol if available (where "better" is 2018 determined by the server, possibly according to the nature of the 2019 method and/or resource being requested). 2021 The Upgrade header field only applies to switching application-layer 2022 protocols upon the existing transport-layer connection. Upgrade 2023 cannot be used to insist on a protocol change; its acceptance and use 2024 by the server is optional. The capabilities and nature of the 2025 application-layer communication after the protocol change is entirely 2026 dependent upon the new protocol chosen, although the first action 2027 after changing the protocol MUST be a response to the initial HTTP 2028 request containing the Upgrade header field. 2030 The Upgrade header field only applies to the immediate connection. 2031 Therefore, the upgrade keyword MUST be supplied within a Connection 2032 header field (Section 8.1) whenever Upgrade is present in an HTTP/1.1 2033 message. 2035 The Upgrade header field cannot be used to indicate a switch to a 2036 protocol on a different connection. For that purpose, it is more 2037 appropriate to use a 301, 302, 303, or 305 redirection response. 2039 This specification only defines the protocol name "HTTP" for use by 2040 the family of Hypertext Transfer Protocols, as defined by the HTTP 2041 version rules of Section 3.1 and future updates to this 2042 specification. Any token can be used as a protocol name; however, it 2043 will only be useful if both the client and server associate the name 2044 with the same protocol. 2046 8.9. Via 2048 The Via general-header field MUST be used by gateways and proxies to 2049 indicate the intermediate protocols and recipients between the user 2050 agent and the server on requests, and between the origin server and 2051 the client on responses. It is analogous to the "Received" field of 2052 [RFC2822] and is intended to be used for tracking message forwards, 2053 avoiding request loops, and identifying the protocol capabilities of 2054 all senders along the request/response chain. 2056 Via = "Via" ":" 1#( received-protocol received-by [ comment ] ) 2057 received-protocol = [ protocol-name "/" ] protocol-version 2058 protocol-name = token 2059 protocol-version = token 2060 received-by = ( host [ ":" port ] ) | pseudonym 2061 pseudonym = token 2063 The received-protocol indicates the protocol version of the message 2064 received by the server or client along each segment of the request/ 2065 response chain. The received-protocol version is appended to the Via 2066 field value when the message is forwarded so that information about 2067 the protocol capabilities of upstream applications remains visible to 2068 all recipients. 2070 The protocol-name is optional if and only if it would be "HTTP". The 2071 received-by field is normally the host and optional port number of a 2072 recipient server or client that subsequently forwarded the message. 2073 However, if the real host is considered to be sensitive information, 2074 it MAY be replaced by a pseudonym. If the port is not given, it MAY 2075 be assumed to be the default port of the received-protocol. 2077 Multiple Via field values represents each proxy or gateway that has 2078 forwarded the message. Each recipient MUST append its information 2079 such that the end result is ordered according to the sequence of 2080 forwarding applications. 2082 Comments MAY be used in the Via header field to identify the software 2083 of the recipient proxy or gateway, analogous to the User-Agent and 2084 Server header fields. However, all comments in the Via field are 2085 optional and MAY be removed by any recipient prior to forwarding the 2086 message. 2088 For example, a request message could be sent from an HTTP/1.0 user 2089 agent to an internal proxy code-named "fred", which uses HTTP/1.1 to 2090 forward the request to a public proxy at p.example.net, which 2091 completes the request by forwarding it to the origin server at 2092 www.example.com. The request received by www.example.com would then 2093 have the following Via header field: 2095 Via: 1.0 fred, 1.1 p.example.net (Apache/1.1) 2097 Proxies and gateways used as a portal through a network firewall 2098 SHOULD NOT, by default, forward the names and ports of hosts within 2099 the firewall region. This information SHOULD only be propagated if 2100 explicitly enabled. If not enabled, the received-by host of any host 2101 behind the firewall SHOULD be replaced by an appropriate pseudonym 2102 for that host. 2104 For organizations that have strong privacy requirements for hiding 2105 internal structures, a proxy MAY combine an ordered subsequence of 2106 Via header field entries with identical received-protocol values into 2107 a single such entry. For example, 2109 Via: 1.0 ricky, 1.1 ethel, 1.1 fred, 1.0 lucy 2111 could be collapsed to 2113 Via: 1.0 ricky, 1.1 mertz, 1.0 lucy 2115 Applications SHOULD NOT combine multiple entries unless they are all 2116 under the same organizational control and the hosts have already been 2117 replaced by pseudonyms. Applications MUST NOT combine entries which 2118 have different received-protocol values. 2120 9. IANA Considerations 2122 TBD. 2124 10. Security Considerations 2126 This section is meant to inform application developers, information 2127 providers, and users of the security limitations in HTTP/1.1 as 2128 described by this document. The discussion does not include 2129 definitive solutions to the problems revealed, though it does make 2130 some suggestions for reducing security risks. 2132 10.1. Personal Information 2134 HTTP clients are often privy to large amounts of personal information 2135 (e.g. the user's name, location, mail address, passwords, encryption 2136 keys, etc.), and SHOULD be very careful to prevent unintentional 2137 leakage of this information via the HTTP protocol to other sources. 2138 We very strongly recommend that a convenient interface be provided 2139 for the user to control dissemination of such information, and that 2140 designers and implementors be particularly careful in this area. 2141 History shows that errors in this area often create serious security 2142 and/or privacy problems and generate highly adverse publicity for the 2143 implementor's company. 2145 10.2. Abuse of Server Log Information 2147 A server is in the position to save personal data about a user's 2148 requests which might identify their reading patterns or subjects of 2149 interest. This information is clearly confidential in nature and its 2150 handling can be constrained by law in certain countries. People 2151 using the HTTP protocol to provide data are responsible for ensuring 2152 that such material is not distributed without the permission of any 2153 individuals that are identifiable by the published results. 2155 10.3. Attacks Based On File and Path Names 2157 Implementations of HTTP origin servers SHOULD be careful to restrict 2158 the documents returned by HTTP requests to be only those that were 2159 intended by the server administrators. If an HTTP server translates 2160 HTTP URIs directly into file system calls, the server MUST take 2161 special care not to serve files that were not intended to be 2162 delivered to HTTP clients. For example, UNIX, Microsoft Windows, and 2163 other operating systems use ".." as a path component to indicate a 2164 directory level above the current one. On such a system, an HTTP 2165 server MUST disallow any such construct in the Request-URI if it 2166 would otherwise allow access to a resource outside those intended to 2167 be accessible via the HTTP server. Similarly, files intended for 2168 reference only internally to the server (such as access control 2169 files, configuration files, and script code) MUST be protected from 2170 inappropriate retrieval, since they might contain sensitive 2171 information. Experience has shown that minor bugs in such HTTP 2172 server implementations have turned into security risks. 2174 10.4. DNS Spoofing 2176 Clients using HTTP rely heavily on the Domain Name Service, and are 2177 thus generally prone to security attacks based on the deliberate mis- 2178 association of IP addresses and DNS names. Clients need to be 2179 cautious in assuming the continuing validity of an IP number/DNS name 2180 association. 2182 In particular, HTTP clients SHOULD rely on their name resolver for 2183 confirmation of an IP number/DNS name association, rather than 2184 caching the result of previous host name lookups. Many platforms 2185 already can cache host name lookups locally when appropriate, and 2186 they SHOULD be configured to do so. It is proper for these lookups 2187 to be cached, however, only when the TTL (Time To Live) information 2188 reported by the name server makes it likely that the cached 2189 information will remain useful. 2191 If HTTP clients cache the results of host name lookups in order to 2192 achieve a performance improvement, they MUST observe the TTL 2193 information reported by DNS. 2195 If HTTP clients do not observe this rule, they could be spoofed when 2196 a previously-accessed server's IP address changes. As network 2197 renumbering is expected to become increasingly common [RFC1900], the 2198 possibility of this form of attack will grow. Observing this 2199 requirement thus reduces this potential security vulnerability. 2201 This requirement also improves the load-balancing behavior of clients 2202 for replicated servers using the same DNS name and reduces the 2203 likelihood of a user's experiencing failure in accessing sites which 2204 use that strategy. 2206 10.5. Proxies and Caching 2208 By their very nature, HTTP proxies are men-in-the-middle, and 2209 represent an opportunity for man-in-the-middle attacks. Compromise 2210 of the systems on which the proxies run can result in serious 2211 security and privacy problems. Proxies have access to security- 2212 related information, personal information about individual users and 2213 organizations, and proprietary information belonging to users and 2214 content providers. A compromised proxy, or a proxy implemented or 2215 configured without regard to security and privacy considerations, 2216 might be used in the commission of a wide range of potential attacks. 2218 Proxy operators should protect the systems on which proxies run as 2219 they would protect any system that contains or transports sensitive 2220 information. In particular, log information gathered at proxies 2221 often contains highly sensitive personal information, and/or 2222 information about organizations. Log information should be carefully 2223 guarded, and appropriate guidelines for use developed and followed. 2224 (Section 10.2). 2226 Proxy implementors should consider the privacy and security 2227 implications of their design and coding decisions, and of the 2228 configuration options they provide to proxy operators (especially the 2229 default configuration). 2231 Users of a proxy need to be aware that they are no trustworthier than 2232 the people who run the proxy; HTTP itself cannot solve this problem. 2234 The judicious use of cryptography, when appropriate, may suffice to 2235 protect against a broad range of security and privacy attacks. Such 2236 cryptography is beyond the scope of the HTTP/1.1 specification. 2238 10.6. Denial of Service Attacks on Proxies 2240 They exist. They are hard to defend against. Research continues. 2241 Beware. 2243 11. Acknowledgments 2245 This specification makes heavy use of the augmented BNF and generic 2246 constructs defined by David H. Crocker for [RFC822ABNF]. Similarly, 2247 it reuses many of the definitions provided by Nathaniel Borenstein 2248 and Ned Freed for MIME [RFC2045]. We hope that their inclusion in 2249 this specification will help reduce past confusion over the 2250 relationship between HTTP and Internet mail message formats. 2252 The HTTP protocol has evolved considerably over the years. It has 2253 benefited from a large and active developer community--the many 2254 people who have participated on the www-talk mailing list--and it is 2255 that community which has been most responsible for the success of 2256 HTTP and of the World-Wide Web in general. Marc Andreessen, Robert 2257 Cailliau, Daniel W. Connolly, Bob Denny, John Franks, Jean-Francois 2258 Groff, Phillip M. Hallam-Baker, Hakon W. Lie, Ari Luotonen, Rob 2259 McCool, Lou Montulli, Dave Raggett, Tony Sanders, and Marc 2260 VanHeyningen deserve special recognition for their efforts in 2261 defining early aspects of the protocol. 2263 This document has benefited greatly from the comments of all those 2264 participating in the HTTP-WG. In addition to those already 2265 mentioned, the following individuals have contributed to this 2266 specification: 2268 Gary Adams, Harald Tveit Alvestrand, Keith Ball, Brian Behlendorf, 2269 Paul Burchard, Maurizio Codogno, Mike Cowlishaw, Roman Czyborra, 2270 Michael A. Dolan, Daniel DuBois, David J. Fiander, Alan Freier, Marc 2271 Hedlund, Greg Herlihy, Koen Holtman, Alex Hopmann, Bob Jernigan, Shel 2272 Kaphan, Rohit Khare, John Klensin, Martijn Koster, Alexei Kosut, 2273 David M. Kristol, Daniel LaLiberte, Ben Laurie, Paul J. Leach, Albert 2274 Lunde, John C. Mallery, Jean-Philippe Martin-Flatin, Mitra, David 2275 Morris, Gavin Nicol, Ross Patterson, Bill Perry, Jeffrey Perry, Scott 2276 Powers, Owen Rees, Luigi Rizzo, David Robinson, Marc Salomon, Rich 2277 Salz, Allan M. Schiffman, Jim Seidman, Chuck Shotton, Eric W. Sink, 2278 Simon E. Spero, Richard N. Taylor, Robert S. Thau, Bill (BearHeart) 2279 Weinman, Francois Yergeau, Mary Ellen Zurko, Josh Cohen. 2281 Thanks to the "cave men" of Palo Alto. You know who you are. 2283 Jim Gettys (the editor of [RFC2616]) wishes particularly to thank Roy 2284 Fielding, the editor of [RFC2068], along with John Klensin, Jeff 2285 Mogul, Paul Leach, Dave Kristol, Koen Holtman, John Franks, Josh 2286 Cohen, Alex Hopmann, Scott Lawrence, and Larry Masinter for their 2287 help. And thanks go particularly to Jeff Mogul and Scott Lawrence 2288 for performing the "MUST/MAY/SHOULD" audit. 2290 The Apache Group, Anselm Baird-Smith, author of Jigsaw, and Henrik 2291 Frystyk implemented RFC 2068 early, and we wish to thank them for the 2292 discovery of many of the problems that this document attempts to 2293 rectify. 2295 12. References 2297 12.1. Normative References 2299 [ISO-8859-1] 2300 International Organization for Standardization, 2301 "Information technology -- 8-bit single-byte coded graphic 2302 character sets -- Part 1: Latin alphabet No. 1", ISO/ 2303 IEC 8859-1:1998, 1998. 2305 [Part2] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., 2306 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., 2307 and J. Reschke, Ed., "HTTP/1.1, part 2: Message 2308 Semantics", draft-ietf-httpbis-p2-semantics-01 (work in 2309 progress), January 2008. 2311 [Part3] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., 2312 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., 2313 and J. Reschke, Ed., "HTTP/1.1, part 3: Message Payload 2314 and Content Negotiation", draft-ietf-httpbis-p3-payload-01 2315 (work in progress), January 2008. 2317 [Part5] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., 2318 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., 2319 and J. Reschke, Ed., "HTTP/1.1, part 5: Range Requests and 2320 Partial Responses", draft-ietf-httpbis-p5-range-01 (work 2321 in progress), January 2008. 2323 [Part6] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., 2324 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., 2325 and J. Reschke, Ed., "HTTP/1.1, part 6: Caching", 2326 draft-ietf-httpbis-p6-cache-01 (work in progress), 2327 January 2008. 2329 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 2330 Extensions (MIME) Part One: Format of Internet Message 2331 Bodies", RFC 2045, November 1996. 2333 [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) 2334 Part Three: Message Header Extensions for Non-ASCII Text", 2335 RFC 2047, November 1996. 2337 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2338 Requirement Levels", BCP 14, RFC 2119, March 1997. 2340 [RFC2396] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 2341 Resource Identifiers (URI): Generic Syntax", RFC 2396, 2342 August 1998. 2344 [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and 2345 Registration Procedures", BCP 13, RFC 4288, December 2005. 2347 [RFC822ABNF] 2348 Crocker, D., "Standard for the format of ARPA Internet 2349 text messages", STD 11, RFC 822, August 1982. 2351 [USASCII] American National Standards Institute, "Coded Character 2352 Set -- 7-bit American Standard Code for Information 2353 Interchange", ANSI X3.4, 1986. 2355 12.2. Informative References 2357 [Nie1997] Nielsen, H., Gettys, J., Prud'hommeaux, E., Lie, H., and 2358 C. Lilley, "Network Performance Effects of HTTP/1.1, CSS1, 2359 and PNG", ACM Proceedings of the ACM SIGCOMM '97 2360 conference on Applications, technologies, architectures, 2361 and protocols for computer communication SIGCOMM '97, 2362 September 1997, 2363 . 2365 [Pad1995] Padmanabhan, V. and J. Mogul, "Improving HTTP Latency", 2366 Computer Networks and ISDN Systems v. 28, pp. 25-35, 2367 December 1995. 2369 Slightly revised version of paper in Proc. 2nd 2370 International WWW Conference '94: Mosaic and the Web, Oct. 2371 1994, which is available at . 2374 [RFC1123] Braden, R., "Requirements for Internet Hosts - Application 2375 and Support", STD 3, RFC 1123, October 1989. 2377 [RFC1305] Mills, D., "Network Time Protocol (Version 3) 2378 Specification, Implementation", RFC 1305, March 1992. 2380 [RFC1436] Anklesaria, F., McCahill, M., Lindner, P., Johnson, D., 2381 Torrey, D., and B. Alberti, "The Internet Gopher Protocol 2382 (a distributed document search and retrieval protocol)", 2383 RFC 1436, March 1993. 2385 [RFC1630] Berners-Lee, T., "Universal Resource Identifiers in WWW: A 2386 Unifying Syntax for the Expression of Names and Addresses 2387 of Objects on the Network as used in the World-Wide Web", 2388 RFC 1630, June 1994. 2390 [RFC1737] Masinter, L. and K. Sollins, "Functional Requirements for 2391 Uniform Resource Names", RFC 1737, December 1994. 2393 [RFC1738] Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform 2394 Resource Locators (URL)", RFC 1738, December 1994. 2396 [RFC1808] Fielding, R., "Relative Uniform Resource Locators", 2397 RFC 1808, June 1995. 2399 [RFC1900] Carpenter, B. and Y. Rekhter, "Renumbering Needs Work", 2400 RFC 1900, February 1996. 2402 [RFC1945] Berners-Lee, T., Fielding, R., and H. Nielsen, "Hypertext 2403 Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996. 2405 [RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and T. 2406 Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", 2407 RFC 2068, January 1997. 2409 [RFC2145] Mogul, J., Fielding, R., Gettys, J., and H. Nielsen, "Use 2410 and Interpretation of HTTP Version Numbers", RFC 2145, 2411 May 1997. 2413 [RFC2324] Masinter, L., "Hyper Text Coffee Pot Control Protocol 2414 (HTCPCP/1.0)", RFC 2324, April 1998. 2416 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 2417 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 2418 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 2420 [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, 2421 April 2001. 2423 [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, 2424 April 2001. 2426 [RFC3977] Feather, C., "Network News Transfer Protocol (NNTP)", 2427 RFC 3977, October 2006. 2429 [RFC822] Crocker, D., "Standard for the format of ARPA Internet 2430 text messages", STD 11, RFC 822, August 1982. 2432 [RFC959] Postel, J. and J. Reynolds, "File Transfer Protocol", 2433 STD 9, RFC 959, October 1985. 2435 [Spe] Spero, S., "Analysis of HTTP Performance Problems", 2436 . 2438 [Tou1998] Touch, J., Heidemann, J., and K. Obraczka, "Analysis of 2439 HTTP Performance", ISI Research Report ISI/RR-98-463, 2440 Aug 1998, . 2442 (original report dated Aug. 1996) 2444 [WAIS] Davis, F., Kahle, B., Morris, H., Salem, J., Shen, T., 2445 Wang, R., Sui, J., and M. Grinbaum, "WAIS Interface 2446 Protocol Prototype Functional Specification (v1.5)", 2447 Thinking Machines Corporation , April 1990. 2449 Appendix A. Internet Media Types 2451 In addition to defining the HTTP/1.1 protocol, this document serves 2452 as the specification for the Internet media type "message/http" and 2453 "application/http". The following is to be registered with IANA 2454 [RFC4288]. 2456 A.1. Internet Media Type message/http 2458 The message/http type can be used to enclose a single HTTP request or 2459 response message, provided that it obeys the MIME restrictions for 2460 all "message" types regarding line length and encodings. 2462 Type name: message 2464 Subtype name: http 2466 Required parameters: none 2468 Optional parameters: version, msgtype 2470 version: The HTTP-Version number of the enclosed message (e.g., 2471 "1.1"). If not present, the version can be determined from the 2472 first line of the body. 2474 msgtype: The message type -- "request" or "response". If not 2475 present, the type can be determined from the first line of the 2476 body. 2478 Encoding considerations: only "7bit", "8bit", or "binary" are 2479 permitted 2481 Security considerations: none 2483 Interoperability considerations: none 2485 Published specification: This specification (see Appendix A.1). 2487 Applications that use this media type: 2489 Additional information: 2491 Magic number(s): none 2493 File extension(s): none 2495 Macintosh file type code(s): none 2497 Person and email address to contact for further information: See 2498 Authors Section. 2500 Intended usage: COMMON 2502 Restrictions on usage: none 2504 Author/Change controller: IESG 2506 A.2. Internet Media Type application/http 2508 The application/http type can be used to enclose a pipeline of one or 2509 more HTTP request or response messages (not intermixed). 2511 Type name: application 2513 Subtype name: http 2515 Required parameters: none 2517 Optional parameters: version, msgtype 2519 version: The HTTP-Version number of the enclosed messages (e.g., 2520 "1.1"). If not present, the version can be determined from the 2521 first line of the body. 2523 msgtype: The message type -- "request" or "response". If not 2524 present, the type can be determined from the first line of the 2525 body. 2527 Encoding considerations: HTTP messages enclosed by this type are in 2528 "binary" format; use of an appropriate Content-Transfer-Encoding 2529 is required when transmitted via E-mail. 2531 Security considerations: none 2533 Interoperability considerations: none 2535 Published specification: This specification (see Appendix A.2). 2537 Applications that use this media type: 2539 Additional information: 2541 Magic number(s): none 2543 File extension(s): none 2545 Macintosh file type code(s): none 2547 Person and email address to contact for further information: See 2548 Authors Section. 2550 Intended usage: COMMON 2552 Restrictions on usage: none 2554 Author/Change controller: IESG 2556 Appendix B. Tolerant Applications 2558 Although this document specifies the requirements for the generation 2559 of HTTP/1.1 messages, not all applications will be correct in their 2560 implementation. We therefore recommend that operational applications 2561 be tolerant of deviations whenever those deviations can be 2562 interpreted unambiguously. 2564 Clients SHOULD be tolerant in parsing the Status-Line and servers 2565 tolerant when parsing the Request-Line. In particular, they SHOULD 2566 accept any amount of SP or HTAB characters between fields, even 2567 though only a single SP is required. 2569 The line terminator for message-header fields is the sequence CRLF. 2571 However, we recommend that applications, when parsing such headers, 2572 recognize a single LF as a line terminator and ignore the leading CR. 2574 The character set of an entity-body SHOULD be labeled as the lowest 2575 common denominator of the character codes used within that body, with 2576 the exception that not labeling the entity is preferred over labeling 2577 the entity with the labels US-ASCII or ISO-8859-1. See [Part3]. 2579 Additional rules for requirements on parsing and encoding of dates 2580 and other potential problems with date encodings include: 2582 o HTTP/1.1 clients and caches SHOULD assume that an RFC-850 date 2583 which appears to be more than 50 years in the future is in fact in 2584 the past (this helps solve the "year 2000" problem). 2586 o An HTTP/1.1 implementation MAY internally represent a parsed 2587 Expires date as earlier than the proper value, but MUST NOT 2588 internally represent a parsed Expires date as later than the 2589 proper value. 2591 o All expiration-related calculations MUST be done in GMT. The 2592 local time zone MUST NOT influence the calculation or comparison 2593 of an age or expiration time. 2595 o If an HTTP header incorrectly carries a date value with a time 2596 zone other than GMT, it MUST be converted into GMT using the most 2597 conservative possible conversion. 2599 Appendix C. Conversion of Date Formats 2601 HTTP/1.1 uses a restricted set of date formats (Section 3.3.1) to 2602 simplify the process of date comparison. Proxies and gateways from 2603 other protocols SHOULD ensure that any Date header field present in a 2604 message conforms to one of the HTTP/1.1 formats and rewrite the date 2605 if necessary. 2607 Appendix D. Compatibility with Previous Versions 2609 It is beyond the scope of a protocol specification to mandate 2610 compliance with previous versions. HTTP/1.1 was deliberately 2611 designed, however, to make supporting previous versions easy. It is 2612 worth noting that, at the time of composing this specification 2613 (1996), we would expect commercial HTTP/1.1 servers to: 2615 o recognize the format of the Request-Line for HTTP/0.9, 1.0, and 2616 1.1 requests; 2618 o understand any valid request in the format of HTTP/0.9, 1.0, or 2619 1.1; 2621 o respond appropriately with a message in the same major version 2622 used by the client. 2624 And we would expect HTTP/1.1 clients to: 2626 o recognize the format of the Status-Line for HTTP/1.0 and 1.1 2627 responses; 2629 o understand any valid response in the format of HTTP/0.9, 1.0, or 2630 1.1. 2632 For most implementations of HTTP/1.0, each connection is established 2633 by the client prior to the request and closed by the server after 2634 sending the response. Some implementations implement the Keep-Alive 2635 version of persistent connections described in Section 19.7.1 of 2636 [RFC2068]. 2638 D.1. Changes from HTTP/1.0 2640 This section summarizes major differences between versions HTTP/1.0 2641 and HTTP/1.1. 2643 D.1.1. Changes to Simplify Multi-homed Web Servers and Conserve IP 2644 Addresses 2646 The requirements that clients and servers support the Host request- 2647 header, report an error if the Host request-header (Section 8.4) is 2648 missing from an HTTP/1.1 request, and accept absolute URIs 2649 (Section 5.1.2) are among the most important changes defined by this 2650 specification. 2652 Older HTTP/1.0 clients assumed a one-to-one relationship of IP 2653 addresses and servers; there was no other established mechanism for 2654 distinguishing the intended server of a request than the IP address 2655 to which that request was directed. The changes outlined above will 2656 allow the Internet, once older HTTP clients are no longer common, to 2657 support multiple Web sites from a single IP address, greatly 2658 simplifying large operational Web servers, where allocation of many 2659 IP addresses to a single host has created serious problems. The 2660 Internet will also be able to recover the IP addresses that have been 2661 allocated for the sole purpose of allowing special-purpose domain 2662 names to be used in root-level HTTP URLs. Given the rate of growth 2663 of the Web, and the number of servers already deployed, it is 2664 extremely important that all implementations of HTTP (including 2665 updates to existing HTTP/1.0 applications) correctly implement these 2666 requirements: 2668 o Both clients and servers MUST support the Host request-header. 2670 o A client that sends an HTTP/1.1 request MUST send a Host header. 2672 o Servers MUST report a 400 (Bad Request) error if an HTTP/1.1 2673 request does not include a Host request-header. 2675 o Servers MUST accept absolute URIs. 2677 D.2. Compatibility with HTTP/1.0 Persistent Connections 2679 Some clients and servers might wish to be compatible with some 2680 previous implementations of persistent connections in HTTP/1.0 2681 clients and servers. Persistent connections in HTTP/1.0 are 2682 explicitly negotiated as they are not the default behavior. HTTP/1.0 2683 experimental implementations of persistent connections are faulty, 2684 and the new facilities in HTTP/1.1 are designed to rectify these 2685 problems. The problem was that some existing 1.0 clients may be 2686 sending Keep-Alive to a proxy server that doesn't understand 2687 Connection, which would then erroneously forward it to the next 2688 inbound server, which would establish the Keep-Alive connection and 2689 result in a hung HTTP/1.0 proxy waiting for the close on the 2690 response. The result is that HTTP/1.0 clients must be prevented from 2691 using Keep-Alive when talking to proxies. 2693 However, talking to proxies is the most important use of persistent 2694 connections, so that prohibition is clearly unacceptable. Therefore, 2695 we need some other mechanism for indicating a persistent connection 2696 is desired, which is safe to use even when talking to an old proxy 2697 that ignores Connection. Persistent connections are the default for 2698 HTTP/1.1 messages; we introduce a new keyword (Connection: close) for 2699 declaring non-persistence. See Section 8.1. 2701 The original HTTP/1.0 form of persistent connections (the Connection: 2702 Keep-Alive and Keep-Alive header) is documented in [RFC2068]. 2704 D.3. Changes from RFC 2068 2706 This specification has been carefully audited to correct and 2707 disambiguate key word usage; RFC 2068 had many problems in respect to 2708 the conventions laid out in [RFC2119]. 2710 Transfer-coding and message lengths all interact in ways that 2711 required fixing exactly when chunked encoding is used (to allow for 2712 transfer encoding that may not be self delimiting); it was important 2713 to straighten out exactly how message lengths are computed. 2715 (Sections 3.4, 4.4, 8.2, see also [Part3], [Part5] and [Part6]) 2717 The use and interpretation of HTTP version numbers has been clarified 2718 by [RFC2145]. Require proxies to upgrade requests to highest 2719 protocol version they support to deal with problems discovered in 2720 HTTP/1.0 implementations (Section 3.1) 2722 Transfer-coding had significant problems, particularly with 2723 interactions with chunked encoding. The solution is that transfer- 2724 codings become as full fledged as content-codings. This involves 2725 adding an IANA registry for transfer-codings (separate from content 2726 codings), a new header field (TE) and enabling trailer headers in the 2727 future. Transfer encoding is a major performance benefit, so it was 2728 worth fixing [Nie1997]. TE also solves another, obscure, downward 2729 interoperability problem that could have occurred due to interactions 2730 between authentication trailers, chunked encoding and HTTP/1.0 2731 clients.(Section 3.4, 3.4.1, and 8.5) 2733 D.4. Changes from RFC 2616 2735 Clarify that HTTP-Version is case sensitive. (Section 3.1) 2737 Remove reference to non-existant identity transfer-coding value 2738 tokens. (Sections 3.4 and 4.4) 2740 Clarification that the chunk length does not include the count of the 2741 octets in the chunk header and trailer. (Section 3.4.1) 2743 Fix BNF to add query, as the abs_path production in Section 3 of 2744 [RFC2396] doesn't define it. (Section 5.1.2) 2746 Clarify exactly when close connection options must be sent. 2747 (Section 8.1) 2749 Appendix E. Change Log (to be removed by RFC Editor before publication) 2751 E.1. Since RFC2616 2753 Extracted relevant partitions from [RFC2616]. 2755 E.2. Since draft-ietf-httpbis-p1-messaging-00 2757 Closed issues: 2759 o : "HTTP 2760 Version should be case sensitive" 2761 () 2763 o : "'unsafe' 2764 characters" () 2766 o : "Chunk Size 2767 Definition" () 2769 o : "Message 2770 Length" () 2772 o : "Media Type 2773 Registrations" () 2775 o : "URI 2776 includes query" () 2778 o : "No close 2779 on 1xx responses" () 2781 o : "Remove 2782 'identity' token references" 2783 () 2785 o : "Import 2786 query BNF" 2788 o : "qdtext 2789 BNF" 2791 o : "Normative 2792 and Informative references" 2794 o : "RFC2606 2795 Compliance" 2797 o : "RFC977 2798 reference" 2800 o : "RFC1700 2801 references" 2803 o : 2804 "inconsistency in date format explanation" 2806 o : "Date 2807 reference typo" 2809 o : 2810 "Informative references" 2812 o : 2813 "ISO-8859-1 Reference" 2815 o : "Normative 2816 up-to-date references" 2818 Other changes: 2820 o Update media type registrations to use RFC4288 template. 2822 o Use names of RFC4234 core rules DQUOTE and HTAB, fix broken ABNF 2823 for chunk-data (work in progress on 2824 ) 2826 Index 2828 A 2829 application/http Media Type 54 2831 C 2832 cache 8 2833 cacheable 9 2834 client 7 2835 connection 6 2836 Connection header 38 2837 content negotiation 7 2838 Content-Length header 39 2840 D 2841 Date header 39 2842 downstream 9 2844 E 2845 entity 7 2847 G 2848 gateway 8 2849 Grammar 2850 ALPHA 14 2851 asctime-date 19 2852 attribute 20 2853 CHAR 14 2854 chunk 21 2855 chunk-data 21 2856 chunk-ext-name 21 2857 chunk-ext-val 21 2858 chunk-extension 21 2859 chunk-size 21 2860 Chunked-Body 21 2861 comment 15 2862 Connection 38 2863 connection-token 38 2864 Content-Length 39 2865 CR 14 2866 CRLF 14 2867 ctext 15 2868 CTL 14 2869 Date 39 2870 date1 19 2871 date2 19 2872 date3 19 2873 DIGIT 14 2874 DQUOTE 14 2875 extension-code 30 2876 extension-method 27 2877 field-content 23 2878 field-name 23 2879 field-value 23 2880 general-header 26 2881 generic-message 22 2882 HEX 14 2883 Host 41 2884 HTAB 14 2885 HTTP-date 19 2886 HTTP-message 22 2887 HTTP-Version 16 2888 http_URL 17 2889 last-chunk 21 2890 LF 14 2891 LOALPHA 14 2892 LWS 14 2893 message-body 24 2894 message-header 23 2895 Method 27 2896 month 19 2897 OCTET 14 2898 parameter 20 2899 protocol-name 45 2900 protocol-version 45 2901 pseudonym 45 2902 qdtext 15 2903 quoted-pair 15 2904 quoted-string 15 2905 Reason-Phrase 30 2906 received-by 45 2907 received-protocol 45 2908 Request 27 2909 Request-Line 27 2910 Request-URI 27 2911 Response 29 2912 rfc850-date 19 2913 rfc1123-date 19 2914 separators 15 2915 SP 14 2916 start-line 22 2917 Status-Code 30 2918 Status-Line 30 2919 t-codings 41 2920 TE 41 2921 TEXT 14 2922 time 19 2923 token 15 2924 Trailer 42 2925 trailer 21 2926 transfer-coding 19 2927 Transfer-Encoding 43 2928 transfer-extension 19 2929 UPALPHA 14 2930 Upgrade 43 2931 value 20 2932 Via 45 2933 weekday 19 2934 wkday 19 2936 H 2937 Headers 2938 Connection 38 2939 Content-Length 39 2940 Date 39 2941 Host 40 2942 TE 41 2943 Trailer 42 2944 Transfer-Encoding 43 2945 Upgrade 43 2946 Via 44 2947 Host header 40 2949 I 2950 inbound 9 2952 M 2953 Media Type 2954 application/http 54 2955 message/http 53 2956 message 6 2957 message/http Media Type 53 2959 O 2960 origin server 8 2961 outbound 9 2963 P 2964 proxy 8 2966 R 2967 representation 7 2968 request 6 2969 resource 7 2970 response 6 2972 S 2973 server 8 2975 T 2976 TE header 41 2977 Trailer header 42 2978 Transfer-Encoding header 43 2979 tunnel 8 2981 U 2982 Upgrade header 43 2983 upstream 9 2984 user agent 7 2986 V 2987 variant 7 2988 Via header 44 2990 Authors' Addresses 2992 Roy T. Fielding (editor) 2993 Day Software 2994 23 Corporate Plaza DR, Suite 280 2995 Newport Beach, CA 92660 2996 USA 2998 Phone: +1-949-706-5300 2999 Fax: +1-949-706-5305 3000 Email: fielding@gbiv.com 3001 URI: http://roy.gbiv.com/ 3003 Jim Gettys 3004 One Laptop per Child 3005 21 Oak Knoll Road 3006 Carlisle, MA 01741 3007 USA 3009 Email: jg@laptop.org 3010 URI: http://www.laptop.org/ 3012 Jeffrey C. Mogul 3013 Hewlett-Packard Company 3014 HP Labs, Large Scale Systems Group 3015 1501 Page Mill Road, MS 1177 3016 Palo Alto, CA 94304 3017 USA 3019 Email: JeffMogul@acm.org 3021 Henrik Frystyk Nielsen 3022 Microsoft Corporation 3023 1 Microsoft Way 3024 Redmond, WA 98052 3025 USA 3027 Email: henrikn@microsoft.com 3028 Larry Masinter 3029 Adobe Systems, Incorporated 3030 345 Park Ave 3031 San Jose, CA 95110 3032 USA 3034 Email: LMM@acm.org 3035 URI: http://larry.masinter.net/ 3037 Paul J. Leach 3038 Microsoft Corporation 3039 1 Microsoft Way 3040 Redmond, WA 98052 3042 Email: paulle@microsoft.com 3044 Tim Berners-Lee 3045 World Wide Web Consortium 3046 MIT Computer Science and Artificial Intelligence Laboratory 3047 The Stata Center, Building 32 3048 32 Vassar Street 3049 Cambridge, MA 02139 3050 USA 3052 Email: timbl@w3.org 3053 URI: http://www.w3.org/People/Berners-Lee/ 3055 Yves Lafon (editor) 3056 World Wide Web Consortium 3057 W3C / ERCIM 3058 2004, rte des Lucioles 3059 Sophia-Antipolis, AM 06902 3060 France 3062 Email: ylafon@w3.org 3063 URI: http://www.raubacapeu.net/people/yves/ 3064 Julian F. Reschke (editor) 3065 greenbytes GmbH 3066 Hafenweg 16 3067 Muenster, NW 48155 3068 Germany 3070 Phone: +49 251 2807760 3071 Fax: +49 251 2807761 3072 Email: julian.reschke@greenbytes.de 3073 URI: http://greenbytes.de/tech/webdav/ 3075 Full Copyright Statement 3077 Copyright (C) The IETF Trust (2008). 3079 This document is subject to the rights, licenses and restrictions 3080 contained in BCP 78, and except as set forth therein, the authors 3081 retain all their rights. 3083 This document and the information contained herein are provided on an 3084 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 3085 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 3086 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 3087 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 3088 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 3089 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 3091 Intellectual Property 3093 The IETF takes no position regarding the validity or scope of any 3094 Intellectual Property Rights or other rights that might be claimed to 3095 pertain to the implementation or use of the technology described in 3096 this document or the extent to which any license under such rights 3097 might or might not be available; nor does it represent that it has 3098 made any independent effort to identify any such rights. Information 3099 on the procedures with respect to rights in RFC documents can be 3100 found in BCP 78 and BCP 79. 3102 Copies of IPR disclosures made to the IETF Secretariat and any 3103 assurances of licenses to be made available, or the result of an 3104 attempt made to obtain a general license or permission for the use of 3105 such proprietary rights by implementers or users of this 3106 specification can be obtained from the IETF on-line IPR repository at 3107 http://www.ietf.org/ipr. 3109 The IETF invites any interested party to bring to its attention any 3110 copyrights, patents or patent applications, or other proprietary 3111 rights that may cover technology that may be required to implement 3112 this standard. Please address the information to the IETF at 3113 ietf-ipr@ietf.org. 3115 Acknowledgment 3117 Funding for the RFC Editor function is provided by the IETF 3118 Administrative Support Activity (IASA).