idnits 2.17.1 draft-ietf-httpbis-p1-messaging-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC2817, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC2817, updated by this document, for RFC5378 checks: 1998-11-18) -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 26, 2009) is 5297 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO-8859-1' == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p2-semantics-08 == Outdated reference: A later version (-20) exists of draft-ietf-httpbis-p3-payload-08 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p5-range-08 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p6-cache-08 ** Downref: Normative reference to an Informational RFC: RFC 1950 ** Downref: Normative reference to an Informational RFC: RFC 1951 ** Downref: Normative reference to an Informational RFC: RFC 1952 -- Possible downref: Non-RFC (?) normative reference: ref. 'USASCII' -- Obsolete informational reference (is this intentional?): RFC 1305 (Obsoleted by RFC 5905) -- Obsolete informational reference (is this intentional?): RFC 2068 (Obsoleted by RFC 2616) -- Obsolete informational reference (is this intentional?): RFC 2109 (Obsoleted by RFC 2965) -- Obsolete informational reference (is this intentional?): RFC 2145 (Obsoleted by RFC 7230) -- Obsolete informational reference (is this intentional?): RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) -- Obsolete informational reference (is this intentional?): RFC 2818 (Obsoleted by RFC 9110) -- Obsolete informational reference (is this intentional?): RFC 2965 (Obsoleted by RFC 6265) -- Obsolete informational reference (is this intentional?): RFC 4288 (Obsoleted by RFC 6838) -- Obsolete informational reference (is this intentional?): RFC 4395 (Obsoleted by RFC 7595) -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 4 errors (**), 0 flaws (~~), 5 warnings (==), 16 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 HTTPbis Working Group R. Fielding, Ed. 3 Internet-Draft Day Software 4 Obsoletes: 2616 (if approved) J. Gettys 5 Updates: 2817 (if approved) One Laptop per Child 6 Intended status: Standards Track J. Mogul 7 Expires: April 29, 2010 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 October 26, 2009 22 HTTP/1.1, part 1: URIs, Connections, and Message Parsing 23 draft-ietf-httpbis-p1-messaging-08 25 Status of this Memo 27 This Internet-Draft is submitted to IETF in full conformance with the 28 provisions of BCP 78 and BCP 79. This document may contain material 29 from IETF Documents or IETF Contributions published or made publicly 30 available before November 10, 2008. The person(s) controlling the 31 copyright in some of this material may not have granted the IETF 32 Trust the right to allow modifications of such material outside the 33 IETF Standards Process. Without obtaining an adequate license from 34 the person(s) controlling the copyright in such materials, this 35 document may not be modified outside the IETF Standards Process, and 36 derivative works of it may not be created outside the IETF Standards 37 Process, except to format it for publication as an RFC or to 38 translate it into languages other than English. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF), its areas, and its working groups. Note that 42 other groups may also distribute working documents as Internet- 43 Drafts. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 The list of current Internet-Drafts can be accessed at 50 http://www.ietf.org/ietf/1id-abstracts.txt. 52 The list of Internet-Draft Shadow Directories can be accessed at 53 http://www.ietf.org/shadow.html. 55 This Internet-Draft will expire on April 29, 2010. 57 Copyright Notice 59 Copyright (c) 2009 IETF Trust and the persons identified as the 60 document authors. All rights reserved. 62 This document is subject to BCP 78 and the IETF Trust's Legal 63 Provisions Relating to IETF Documents in effect on the date of 64 publication of this document (http://trustee.ietf.org/license-info). 65 Please review these documents carefully, as they describe your rights 66 and restrictions with respect to this document. 68 Abstract 70 The Hypertext Transfer Protocol (HTTP) is an application-level 71 protocol for distributed, collaborative, hypertext information 72 systems. HTTP has been in use by the World Wide Web global 73 information initiative since 1990. This document is Part 1 of the 74 seven-part specification that defines the protocol referred to as 75 "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 1 provides 76 an overview of HTTP and its associated terminology, defines the 77 "http" and "https" Uniform Resource Identifier (URI) schemes, defines 78 the generic message syntax and parsing requirements for HTTP message 79 frames, and describes general security concerns for implementations. 81 Editorial Note (To be removed by RFC Editor) 83 Discussion of this draft should take place on the HTTPBIS working 84 group mailing list (ietf-http-wg@w3.org). The current issues list is 85 at and related 86 documents (including fancy diffs) can be found at 87 . 89 The changes in this draft are summarized in Appendix D.9. 91 Table of Contents 93 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6 94 1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 7 95 1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 7 96 1.2.1. ABNF Extension: #rule . . . . . . . . . . . . . . . . 7 97 1.2.2. Basic Rules . . . . . . . . . . . . . . . . . . . . . 8 98 1.2.3. ABNF Rules defined in other Parts of the 99 Specification . . . . . . . . . . . . . . . . . . . . 9 100 2. HTTP architecture . . . . . . . . . . . . . . . . . . . . . . 10 101 2.1. Client/Server Operation . . . . . . . . . . . . . . . . . 10 102 2.2. Intermediaries . . . . . . . . . . . . . . . . . . . . . . 11 103 2.3. Caches . . . . . . . . . . . . . . . . . . . . . . . . . . 12 104 2.4. Transport Independence . . . . . . . . . . . . . . . . . . 13 105 2.5. HTTP Version . . . . . . . . . . . . . . . . . . . . . . . 14 106 2.6. Uniform Resource Identifiers . . . . . . . . . . . . . . . 15 107 2.6.1. http URI scheme . . . . . . . . . . . . . . . . . . . 16 108 2.6.2. https URI scheme . . . . . . . . . . . . . . . . . . . 17 109 2.6.3. http and https URI Normalization and Comparison . . . 17 110 3. HTTP Message . . . . . . . . . . . . . . . . . . . . . . . . . 18 111 3.1. Message Parsing Robustness . . . . . . . . . . . . . . . . 19 112 3.2. Header Fields . . . . . . . . . . . . . . . . . . . . . . 19 113 3.3. Message Body . . . . . . . . . . . . . . . . . . . . . . . 21 114 3.4. Message Length . . . . . . . . . . . . . . . . . . . . . . 22 115 3.5. General Header Fields . . . . . . . . . . . . . . . . . . 23 116 4. Request . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 117 4.1. Request-Line . . . . . . . . . . . . . . . . . . . . . . . 24 118 4.1.1. Method . . . . . . . . . . . . . . . . . . . . . . . . 24 119 4.1.2. request-target . . . . . . . . . . . . . . . . . . . . 24 120 4.2. The Resource Identified by a Request . . . . . . . . . . . 26 121 5. Response . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 122 5.1. Status-Line . . . . . . . . . . . . . . . . . . . . . . . 27 123 5.1.1. Status Code and Reason Phrase . . . . . . . . . . . . 28 124 6. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 28 125 6.1. Date/Time Formats: Full Date . . . . . . . . . . . . . . . 28 126 6.2. Transfer Codings . . . . . . . . . . . . . . . . . . . . . 31 127 6.2.1. Chunked Transfer Coding . . . . . . . . . . . . . . . 32 128 6.2.2. Compression Codings . . . . . . . . . . . . . . . . . 34 129 6.2.3. Transfer Coding Registry . . . . . . . . . . . . . . . 35 130 6.3. Product Tokens . . . . . . . . . . . . . . . . . . . . . . 35 131 6.4. Quality Values . . . . . . . . . . . . . . . . . . . . . . 36 132 7. Connections . . . . . . . . . . . . . . . . . . . . . . . . . 36 133 7.1. Persistent Connections . . . . . . . . . . . . . . . . . . 36 134 7.1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . 36 135 7.1.2. Overall Operation . . . . . . . . . . . . . . . . . . 37 136 7.1.3. Proxy Servers . . . . . . . . . . . . . . . . . . . . 38 137 7.1.4. Practical Considerations . . . . . . . . . . . . . . . 39 138 7.2. Message Transmission Requirements . . . . . . . . . . . . 40 139 7.2.1. Persistent Connections and Flow Control . . . . . . . 40 140 7.2.2. Monitoring Connections for Error Status Messages . . . 40 141 7.2.3. Use of the 100 (Continue) Status . . . . . . . . . . . 40 142 7.2.4. Client Behavior if Server Prematurely Closes 143 Connection . . . . . . . . . . . . . . . . . . . . . . 42 144 8. Miscellaneous notes that may disappear . . . . . . . . . . . . 43 145 8.1. Scheme aliases considered harmful . . . . . . . . . . . . 43 146 8.2. Use of HTTP for proxy communication . . . . . . . . . . . 43 147 8.3. Interception of HTTP for access control . . . . . . . . . 43 148 8.4. Use of HTTP by other protocols . . . . . . . . . . . . . . 44 149 8.5. Use of HTTP by media type specification . . . . . . . . . 44 150 9. Header Field Definitions . . . . . . . . . . . . . . . . . . . 44 151 9.1. Connection . . . . . . . . . . . . . . . . . . . . . . . . 44 152 9.2. Content-Length . . . . . . . . . . . . . . . . . . . . . . 45 153 9.3. Date . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 154 9.3.1. Clockless Origin Server Operation . . . . . . . . . . 47 155 9.4. Host . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 156 9.5. TE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 157 9.6. Trailer . . . . . . . . . . . . . . . . . . . . . . . . . 49 158 9.7. Transfer-Encoding . . . . . . . . . . . . . . . . . . . . 49 159 9.8. Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . 50 160 9.8.1. Upgrade Token Registry . . . . . . . . . . . . . . . . 51 161 9.9. Via . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 162 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 53 163 10.1. Message Header Registration . . . . . . . . . . . . . . . 53 164 10.2. URI Scheme Registration . . . . . . . . . . . . . . . . . 54 165 10.3. Internet Media Type Registrations . . . . . . . . . . . . 54 166 10.3.1. Internet Media Type message/http . . . . . . . . . . . 54 167 10.3.2. Internet Media Type application/http . . . . . . . . . 55 168 10.4. Transfer Coding Registry . . . . . . . . . . . . . . . . . 56 169 10.5. Upgrade Token Registration . . . . . . . . . . . . . . . . 57 170 11. Security Considerations . . . . . . . . . . . . . . . . . . . 57 171 11.1. Personal Information . . . . . . . . . . . . . . . . . . . 57 172 11.2. Abuse of Server Log Information . . . . . . . . . . . . . 58 173 11.3. Attacks Based On File and Path Names . . . . . . . . . . . 58 174 11.4. DNS Spoofing . . . . . . . . . . . . . . . . . . . . . . . 58 175 11.5. Proxies and Caching . . . . . . . . . . . . . . . . . . . 59 176 11.6. Denial of Service Attacks on Proxies . . . . . . . . . . . 60 177 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 60 178 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 61 179 13.1. Normative References . . . . . . . . . . . . . . . . . . . 61 180 13.2. Informative References . . . . . . . . . . . . . . . . . . 62 181 Appendix A. Tolerant Applications . . . . . . . . . . . . . . . . 64 182 Appendix B. Compatibility with Previous Versions . . . . . . . . 65 183 B.1. Changes from HTTP/1.0 . . . . . . . . . . . . . . . . . . 66 184 B.1.1. Changes to Simplify Multi-homed Web Servers and 185 Conserve IP Addresses . . . . . . . . . . . . . . . . 66 186 B.2. Compatibility with HTTP/1.0 Persistent Connections . . . . 67 187 B.3. Changes from RFC 2068 . . . . . . . . . . . . . . . . . . 67 188 B.4. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 68 189 Appendix C. Collected ABNF . . . . . . . . . . . . . . . . . . . 69 190 Appendix D. Change Log (to be removed by RFC Editor before 191 publication) . . . . . . . . . . . . . . . . . . . . 73 192 D.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 73 193 D.2. Since draft-ietf-httpbis-p1-messaging-00 . . . . . . . . . 73 194 D.3. Since draft-ietf-httpbis-p1-messaging-01 . . . . . . . . . 75 195 D.4. Since draft-ietf-httpbis-p1-messaging-02 . . . . . . . . . 76 196 D.5. Since draft-ietf-httpbis-p1-messaging-03 . . . . . . . . . 76 197 D.6. Since draft-ietf-httpbis-p1-messaging-04 . . . . . . . . . 77 198 D.7. Since draft-ietf-httpbis-p1-messaging-05 . . . . . . . . . 77 199 D.8. Since draft-ietf-httpbis-p1-messaging-06 . . . . . . . . . 78 200 D.9. Since draft-ietf-httpbis-p1-messaging-07 . . . . . . . . . 79 201 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 202 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 84 204 1. Introduction 206 The Hypertext Transfer Protocol (HTTP) is an application-level 207 request/response protocol that uses extensible semantics and MIME- 208 like message payloads for flexible interaction with network-based 209 hypertext information systems. HTTP relies upon the Uniform Resource 210 Identifier (URI) standard [RFC3986] to indicate request targets and 211 relationships between resources. Messages are passed in a format 212 similar to that used by Internet mail [RFC5322] and the Multipurpose 213 Internet Mail Extensions (MIME) [RFC2045] (see Appendix A of [Part3] 214 for the differences between HTTP and MIME messages). 216 HTTP is a generic interface protocol for information systems. It is 217 designed to hide the details of how a service is implemented by 218 presenting a uniform interface to clients that is independent of the 219 types of resources provided. Likewise, servers do not need to be 220 aware of each client's purpose: an HTTP request can be considered in 221 isolation rather than being associated with a specific type of client 222 or a predetermined sequence of application steps. The result is a 223 protocol that can be used effectively in many different contexts and 224 for which implementations can evolve independently over time. 226 HTTP is also designed for use as a generic protocol for translating 227 communication to and from other Internet information systems. HTTP 228 proxies and gateways provide access to alternative information 229 services by translating their diverse protocols into a hypertext 230 format that can be viewed and manipulated by clients in the same way 231 as HTTP services. 233 One consequence of HTTP flexibility is that the protocol cannot be 234 defined in terms of what occurs behind the interface. Instead, we 235 are limited to defining the syntax of communication, the intent of 236 received communication, and the expected behavior of recipients. If 237 the communication is considered in isolation, then successful actions 238 should be reflected in corresponding changes to the observable 239 interface provided by servers. However, since multiple clients may 240 act in parallel and perhaps at cross-purposes, we cannot require that 241 such changes be observable beyond the scope of a single response. 243 This document is Part 1 of the seven-part specification of HTTP, 244 defining the protocol referred to as "HTTP/1.1" and obsoleting 245 [RFC2616]. Part 1 describes the architectural elements that are used 246 or referred to in HTTP, defines the "http" and "https" URI schemes, 247 describes overall network operation and connection management, and 248 defines HTTP message framing and forwarding requirements. Our goal 249 is to define all of the mechanisms necessary for HTTP message 250 handling that are independent of message semantics, thereby defining 251 the complete set of requirements for message parsers and message- 252 forwarding intermediaries. 254 1.1. Requirements 256 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 257 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 258 document are to be interpreted as described in [RFC2119]. 260 An implementation is not compliant if it fails to satisfy one or more 261 of the MUST or REQUIRED level requirements for the protocols it 262 implements. An implementation that satisfies all the MUST or 263 REQUIRED level and all the SHOULD level requirements for its 264 protocols is said to be "unconditionally compliant"; one that 265 satisfies all the MUST level requirements but not all the SHOULD 266 level requirements for its protocols is said to be "conditionally 267 compliant." 269 1.2. Syntax Notation 271 This specification uses the Augmented Backus-Naur Form (ABNF) 272 notation of [RFC5234]. 274 The following core rules are included by reference, as defined in 275 [RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF 276 (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote), 277 HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any 8-bit 278 sequence of data), SP (space), VCHAR (any visible [USASCII] 279 character), and WSP (whitespace). 281 1.2.1. ABNF Extension: #rule 283 One extension to the ABNF rules of [RFC5234] is used to improve 284 readability. 286 A construct "#" is defined, similar to "*", for defining lists of 287 elements. The full form is "#element" indicating at least 288 and at most elements, each separated by a single comma (",") and 289 optional whitespace (OWS). 291 Thus, 293 1#element => element *( OWS "," OWS element ) 295 and: 297 #element => [ 1#element ] 299 and for n >= 1 and m > 1: 301 #element => element *( OWS "," OWS element ) 303 For compatibility with legacy list rules, recipients SHOULD accept 304 empty list elements. In other words, consumers would follow the list 305 productions: 307 #element => [ ( "," / element ) *( OWS "," [ OWS element ] ) ] 309 1#element => *( "," OWS ) element *( OWS "," [ OWS element ] ) 311 Appendix C shows the collected ABNF, with the list rules expanded as 312 explained above. 314 1.2.2. Basic Rules 316 HTTP/1.1 defines the sequence CR LF as the end-of-line marker for all 317 protocol elements except the entity-body (see Appendix A for tolerant 318 applications). The end-of-line marker within an entity-body is 319 defined by its associated media type, as described in Section 2.3 of 320 [Part3]. 322 This specification uses three rules to denote the use of linear 323 whitespace: OWS (optional whitespace), RWS (required whitespace), and 324 BWS ("bad" whitespace). 326 The OWS rule is used where zero or more linear whitespace characters 327 may appear. OWS SHOULD either not be produced or be produced as a 328 single SP character. Multiple OWS characters that occur within 329 field-content SHOULD be replaced with a single SP before interpreting 330 the field value or forwarding the message downstream. 332 RWS is used when at least one linear whitespace character is required 333 to separate field tokens. RWS SHOULD be produced as a single SP 334 character. Multiple RWS characters that occur within field-content 335 SHOULD be replaced with a single SP before interpreting the field 336 value or forwarding the message downstream. 338 BWS is used where the grammar allows optional whitespace for 339 historical reasons but senders SHOULD NOT produce it in messages. 340 HTTP/1.1 recipients MUST accept such bad optional whitespace and 341 remove it before interpreting the field value or forwarding the 342 message downstream. 344 OWS = *( [ obs-fold ] WSP ) 345 ; "optional" whitespace 346 RWS = 1*( [ obs-fold ] WSP ) 347 ; "required" whitespace 348 BWS = OWS 349 ; "bad" whitespace 350 obs-fold = CRLF 351 ; see Section 3.2 353 Many HTTP/1.1 header field values consist of words separated by 354 whitespace or special characters. These special characters MUST be 355 in a quoted string to be used within a parameter value (as defined in 356 Section 6.2). 358 tchar = "!" / "#" / "$" / "%" / "&" / "'" / "*" 359 / "+" / "-" / "." / "^" / "_" / "`" / "|" / "~" 360 / DIGIT / ALPHA 362 token = 1*tchar 364 A string of text is parsed as a single word if it is quoted using 365 double-quote marks. 367 quoted-string = DQUOTE *( qdtext / quoted-pair ) DQUOTE 368 qdtext = OWS / %x21 / %x23-5B / %x5D-7E / obs-text 369 ; OWS / / obs-text 370 obs-text = %x80-FF 372 The backslash character ("\") can be used as a single-character 373 quoting mechanism within quoted-string constructs: 375 quoted-pair = "\" ( WSP / VCHAR / obs-text ) 377 Producers SHOULD NOT escape characters that do not require escaping 378 (i.e., other than DQUOTE and the backslash character). 380 1.2.3. ABNF Rules defined in other Parts of the Specification 382 The ABNF rules below are defined in other parts: 384 request-header = 385 response-header = 387 entity-body = 388 entity-header = 389 Cache-Control = 390 Pragma = 391 Warning = 393 2. HTTP architecture 395 HTTP was created for the World Wide Web architecture and has evolved 396 over time to support the scalability needs of a worldwide hypertext 397 system. Much of that architecture is reflected in the terminology 398 and syntax productions used to define HTTP. 400 2.1. Client/Server Operation 402 HTTP is a request/response protocol that operates by exchanging 403 messages across a reliable transport or session-layer connection. An 404 HTTP client is a program that establishes a connection to a server 405 for the purpose of sending one or more HTTP requests. An HTTP server 406 is a program that accepts connections in order to service HTTP 407 requests by sending HTTP responses. 409 Note that the terms "client" and "server" refer only to the roles 410 that these programs perform for a particular connection. The same 411 program may act as a client on some connections and a server on 412 others. We use the term "user agent" to refer to the program that 413 initiates a request, such as a WWW browser, editor, or spider (web- 414 traversing robot), and the term "origin server" to refer to the 415 program that can originate authoritative responses to a request. 417 Most HTTP communication consists of a retrieval request (GET) for a 418 representation of some resource identified by a URI. In the simplest 419 case, this may be accomplished via a single connection (v) between 420 the user agent (UA) and the origin server (O). 422 request chain ------------------------> 423 UA -------------------v------------------- O 424 <----------------------- response chain 426 A client sends an HTTP request to the server in the form of a request 427 message (Section 4), beginning with a method, URI, and protocol 428 version, followed by MIME-like header fields containing request 429 modifiers, client information, and payload metadata, an empty line to 430 indicate the end of the header section, and finally the payload body 431 (if any). 433 A server responds to the client's request by sending an HTTP response 434 message (Section 5), beginning with a status line that includes the 435 protocol version, a success or error code, and textual reason phrase, 436 followed by MIME-like header fields containing server information, 437 resource metadata, and payload metadata, an empty line to indicate 438 the end of the header section, and finally the payload body (if any). 440 The following example illustrates a typical message exchange for a 441 GET request on the URI "http://www.example.com/hello.txt": 443 client request: 445 GET /hello.txt HTTP/1.1 446 User-Agent: curl/7.16.3 libcurl/7.16.3 OpenSSL/0.9.7l zlib/1.2.3 447 Host: www.example.com 448 Accept: */* 450 server response: 452 HTTP/1.1 200 OK 453 Date: Mon, 27 Jul 2009 12:28:53 GMT 454 Server: Apache 455 Last-Modified: Wed, 22 Jul 2009 19:15:56 GMT 456 ETag: "34aa387-d-1568eb00" 457 Accept-Ranges: bytes 458 Content-Length: 14 459 Vary: Accept-Encoding 460 Content-Type: text/plain 462 Hello World! 464 2.2. Intermediaries 466 A more complicated situation occurs when one or more intermediaries 467 are present in the request/response chain. There are three common 468 forms of intermediary: proxy, gateway, and tunnel. In some cases, a 469 single intermediary may act as an origin server, proxy, gateway, or 470 tunnel, switching behavior based on the nature of each request. 472 request chain --------------------------------------> 473 UA -----v----- A -----v----- B -----v----- C -----v----- O 474 <------------------------------------- response chain 476 The figure above shows three intermediaries (A, B, and C) between the 477 user agent and origin server. A request or response message that 478 travels the whole chain will pass through four separate connections. 479 Some HTTP communication options may apply only to the connection with 480 the nearest, non-tunnel neighbor, only to the end-points of the 481 chain, or to all connections along the chain. Although the diagram 482 is linear, each participant may be engaged in multiple, simultaneous 483 communications. For example, B may be receiving requests from many 484 clients other than A, and/or forwarding requests to servers other 485 than C, at the same time that it is handling A's request. 487 We use the terms "upstream" and "downstream" to describe various 488 requirements in relation to the directional flow of a message: all 489 messages flow from upstream to downstream. Likewise, we use the 490 terms "inbound" and "outbound" to refer to directions in relation to 491 the request path: "inbound" means toward the origin server and 492 "outbound" means toward the user agent. 494 A proxy is a message forwarding agent that is selected by the client, 495 usually via local configuration rules, to receive requests for some 496 type(s) of absolute URI and attempt to satisfy those requests via 497 translation through the HTTP interface. Some translations are 498 minimal, such as for proxy requests for "http" URIs, whereas other 499 requests may require translation to and from entirely different 500 application-layer protocols. Proxies are often used to group an 501 organization's HTTP requests through a common intermediary for the 502 sake of security, annotation services, or shared caching. 504 A gateway (a.k.a., reverse proxy) is a receiving agent that acts as a 505 layer above some other server(s) and translates the received requests 506 to the underlying server's protocol. Gateways are often used for 507 load balancing or partitioning HTTP services across multiple 508 machines. Unlike a proxy, a gateway receives requests as if it were 509 the origin server for the requested resource; the requesting client 510 will not be aware that it is communicating with a gateway. A gateway 511 communicates with the client as if the gateway is the origin server 512 and thus is subject to all of the requirements on origin servers for 513 that connection. A gateway communicates with inbound servers using 514 any protocol it desires, including private extensions to HTTP that 515 are outside the scope of this specification. 517 A tunnel acts as a blind relay between two connections without 518 changing the messages. Once active, a tunnel is not considered a 519 party to the HTTP communication, though the tunnel may have been 520 initiated by an HTTP request. A tunnel ceases to exist when both 521 ends of the relayed connection are closed. Tunnels are used to 522 extend a virtual connection through an intermediary, such as when 523 transport-layer security is used to establish private communication 524 through a shared firewall proxy. 526 2.3. Caches 528 Any party to HTTP communication that is not acting as a tunnel may 529 employ an internal cache for handling requests. A cache is a local 530 store of previous response messages and the subsystem that controls 531 its message storage, retrieval, and deletion. A cache stores 532 cacheable responses in order to reduce the response time and network 533 bandwidth consumption on future, equivalent requests. Any client or 534 server may include a cache, though a cache cannot be used by a server 535 while it is acting as a tunnel. 537 The effect of a cache is that the request/response chain is shortened 538 if one of the participants along the chain has a cached response 539 applicable to that request. The following illustrates the resulting 540 chain if B has a cached copy of an earlier response from O (via C) 541 for a request which has not been cached by UA or A. 543 request chain ----------> 544 UA -----v----- A -----v----- B - - - - - - C - - - - - - O 545 <--------- response chain 547 A response is cacheable if a cache is allowed to store a copy of the 548 response message for use in answering subsequent requests. Even when 549 a response is cacheable, there may be additional constraints placed 550 by the client or by the origin server on when that cached response 551 can be used for a particular request. HTTP requirements for cache 552 behavior and cacheable responses are defined in Section 2 of [Part6]. 554 There are a wide variety of architectures and configurations of 555 caches and proxies deployed across the World Wide Web and inside 556 large organizations. These systems include national hierarchies of 557 proxy caches to save transoceanic bandwidth, systems that broadcast 558 or multicast cache entries, organizations that distribute subsets of 559 cached data via optical media, and so on. 561 2.4. Transport Independence 563 HTTP systems are used in a wide variety of environments, from 564 corporate intranets with high-bandwidth links to long-distance 565 communication over low-power radio links and intermittent 566 connectivity. 568 HTTP communication usually takes place over TCP/IP connections. The 569 default port is TCP 80 570 (), but other ports can 571 be used. This does not preclude HTTP from being implemented on top 572 of any other protocol on the Internet, or on other networks. HTTP 573 only presumes a reliable transport; any protocol that provides such 574 guarantees can be used; the mapping of the HTTP/1.1 request and 575 response structures onto the transport data units of the protocol in 576 question is outside the scope of this specification. 578 In HTTP/1.0, most implementations used a new connection for each 579 request/response exchange. In HTTP/1.1, a connection may be used for 580 one or more request/response exchanges, although connections may be 581 closed for a variety of reasons (see Section 7.1). 583 2.5. HTTP Version 585 HTTP uses a "." numbering scheme to indicate versions 586 of the protocol. The protocol versioning policy is intended to allow 587 the sender to indicate the format of a message and its capacity for 588 understanding further HTTP communication, rather than the features 589 obtained via that communication. No change is made to the version 590 number for the addition of message components which do not affect 591 communication behavior or which only add to extensible field values. 592 The number is incremented when the changes made to the 593 protocol add features which do not change the general message parsing 594 algorithm, but which may add to the message semantics and imply 595 additional capabilities of the sender. The number is 596 incremented when the format of a message within the protocol is 597 changed. See [RFC2145] for a fuller explanation. 599 The version of an HTTP message is indicated by an HTTP-Version field 600 in the first line of the message. HTTP-Version is case-sensitive. 602 HTTP-Version = HTTP-Prot-Name "/" 1*DIGIT "." 1*DIGIT 603 HTTP-Prot-Name = %x48.54.54.50 ; "HTTP", case-sensitive 605 Note that the major and minor numbers MUST be treated as separate 606 integers and that each MAY be incremented higher than a single digit. 607 Thus, HTTP/2.4 is a lower version than HTTP/2.13, which in turn is 608 lower than HTTP/12.3. Leading zeros MUST be ignored by recipients 609 and MUST NOT be sent. 611 An application that sends a request or response message that includes 612 HTTP-Version of "HTTP/1.1" MUST be at least conditionally compliant 613 with this specification. Applications that are at least 614 conditionally compliant with this specification SHOULD use an HTTP- 615 Version of "HTTP/1.1" in their messages, and MUST do so for any 616 message that is not compatible with HTTP/1.0. For more details on 617 when to send specific HTTP-Version values, see [RFC2145]. 619 The HTTP version of an application is the highest HTTP version for 620 which the application is at least conditionally compliant. 622 Proxy and gateway applications need to be careful when forwarding 623 messages in protocol versions different from that of the application. 624 Since the protocol version indicates the protocol capability of the 625 sender, a proxy/gateway MUST NOT send a message with a version 626 indicator which is greater than its actual version. If a higher 627 version request is received, the proxy/gateway MUST either downgrade 628 the request version, or respond with an error, or switch to tunnel 629 behavior. 631 Due to interoperability problems with HTTP/1.0 proxies discovered 632 since the publication of [RFC2068], caching proxies MUST, gateways 633 MAY, and tunnels MUST NOT upgrade the request to the highest version 634 they support. The proxy/gateway's response to that request MUST be 635 in the same major version as the request. 637 Note: Converting between versions of HTTP may involve modification 638 of header fields required or forbidden by the versions involved. 640 2.6. Uniform Resource Identifiers 642 Uniform Resource Identifiers (URIs) [RFC3986] are used throughout 643 HTTP as the means for identifying resources. URI references are used 644 to target requests, indicate redirects, and define relationships. 645 HTTP does not limit what a resource may be; it merely defines an 646 interface that can be used to interact with a resource via HTTP. 647 More information on the scope of URIs and resources can be found in 648 [RFC3986]. 650 This specification adopts the definitions of "URI-reference", 651 "absolute-URI", "relative-part", "port", "host", "path-abempty", 652 "path-absolute", "query", and "authority" from [RFC3986]. In 653 addition, we define a partial-URI rule for protocol elements that 654 allow a relative URI without a fragment. 656 URI = 657 URI-reference = 658 absolute-URI = 659 relative-part = 660 authority = 661 path-abempty = 662 path-absolute = 663 port = 664 query = 665 uri-host = 667 partial-URI = relative-part [ "?" query ] 669 Each protocol element in HTTP that allows a URI reference will 670 indicate in its ABNF production whether the element allows only a URI 671 in absolute form (absolute-URI), any relative reference (relative- 672 ref), or some other subset of the URI-reference grammar. Unless 673 otherwise indicated, URI references are parsed relative to the 674 request target (the default base URI for both the request and its 675 corresponding response). 677 2.6.1. http URI scheme 679 The "http" URI scheme is hereby defined for the purpose of minting 680 identifiers according to their association with the hierarchical 681 namespace governed by a potential HTTP origin server listening for 682 TCP connections on a given port. The HTTP server is identified via 683 the generic syntax's authority component, which includes a host 684 identifier and optional TCP port, and the remainder of the URI is 685 considered to be identifying data corresponding to a resource for 686 which that server might provide an HTTP interface. 688 http-URI = "http:" "//" authority path-abempty [ "?" query ] 690 The host identifier within an authority component is defined in 691 [RFC3986], Section 3.2.2. If host is provided as an IP literal or 692 IPv4 address, then the HTTP server is any listener on the indicated 693 TCP port at that IP address. If host is a registered name, then that 694 name is considered an indirect identifier and the recipient might use 695 a name resolution service, such as DNS, to find the address of a 696 listener for that host. The host MUST NOT be empty; if an "http" URI 697 is received with an empty host, then it MUST be rejected as invalid. 698 If the port subcomponent is empty or not given, then TCP port 80 is 699 assumed (the default reserved port for WWW services). 701 Regardless of the form of host identifier, access to that host is not 702 implied by the mere presence of its name or address. The host may or 703 may not exist and, even when it does exist, may or may not be running 704 an HTTP server or listening to the indicated port. The "http" URI 705 scheme makes use of the delegated nature of Internet names and 706 addresses to establish a naming authority (whatever entity has the 707 ability to place an HTTP server at that Internet name or address) and 708 allows that authority to determine which names are valid and how they 709 might be used. 711 When an "http" URI is used within a context that calls for access to 712 the indicated resource, a client MAY attempt access by resolving the 713 host to an IP address, establishing a TCP connection to that address 714 on the indicated port, and sending an HTTP request message to the 715 server containing the URI's identifying data as described in 716 Section 4. If the server responds to that request with a non-interim 717 HTTP response message, as described in Section 5, then that response 718 is considered an authoritative answer to the client's request. 720 Although HTTP is independent of the transport protocol, the "http" 721 scheme is specific to TCP-based services because the name delegation 722 process depends on TCP for establishing authority. An HTTP service 723 based on some other underlying connection protocol would presumably 724 be identified using a different URI scheme, just as the "https" 725 scheme (below) is used for servers that require an SSL/TLS transport 726 layer on a connection. Other protocols may also be used to provide 727 access to "http" identified resources --- it is only the 728 authoritative interface used for mapping the namespace that is 729 specific to TCP. 731 2.6.2. https URI scheme 733 The "https" URI scheme is hereby defined for the purpose of minting 734 identifiers according to their association with the hierarchical 735 namespace governed by a potential HTTP origin server listening for 736 SSL/TLS-secured connections on a given TCP port. The host and port 737 are determined in the same way as for the "http" scheme, except that 738 a default TCP port of 443 is assumed if the port subcomponent is 739 empty or not given. 741 https-URI = "https:" "//" authority path-abempty [ "?" query ] 743 The primary difference between the "http" and "https" schemes is that 744 interaction with the latter is required to be secured for privacy 745 through the use of strong encryption. The URI cannot be sent in a 746 request until the connection is secure. Likewise, the default for 747 caching is that each response that would be considered "public" under 748 the "http" scheme is instead treated as "private" and thus not 749 eligible for shared caching. 751 The process for authoritative access to an "https" identified 752 resource is defined in [RFC2818]. 754 2.6.3. http and https URI Normalization and Comparison 756 Since the "http" and "https" schemes conform to the URI generic 757 syntax, such URIs are normalized and compared according to the 758 algorithm defined in [RFC3986], Section 6, using the defaults 759 described above for each scheme. 761 If the port is equal to the default port for a scheme, the normal 762 form is to elide the port subcomponent. Likewise, an empty path 763 component is equivalent to an absolute path of "/", so the normal 764 form is to provide a path of "/" instead. The scheme and host are 765 case-insensitive and normally provided in lowercase; all other 766 components are compared in a case-sensitive manner. Characters other 767 than those in the "reserved" set are equivalent to their percent- 768 encoded octets (see [RFC3986], Section 2.1): the normal form is to 769 not encode them. 771 For example, the following three URIs are equivalent: 773 http://example.com:80/~smith/home.html 774 http://EXAMPLE.com/%7Esmith/home.html 775 http://EXAMPLE.com:/%7esmith/home.html 777 [[anchor1: [[This paragraph does not belong here. --Roy]]]] If path- 778 abempty is the empty string (i.e., there is no slash "/" path 779 separator following the authority), then the "http" URI MUST be given 780 as "/" when used as a request-target (Section 4.1.2). If a proxy 781 receives a host name which is not a fully qualified domain name, it 782 MAY add its domain to the host name it received. If a proxy receives 783 a fully qualified domain name, the proxy MUST NOT change the host 784 name. 786 3. HTTP Message 788 All HTTP/1.1 messages consist of a start-line followed by a sequence 789 of characters in a format similar to the Internet Message Format 790 [RFC5322]: zero or more header fields (collectively referred to as 791 the "headers" or the "header section"), an empty line indicating the 792 end of the header section, and an optional message-body. 794 An HTTP message can either be a request from client to server or a 795 response from server to client. Syntactically, the two types of 796 message differ only in the start-line, which is either a Request-Line 797 (for requests) or a Status-Line (for responses), and in the algorithm 798 for determining the length of the message-body (Section 3.4). In 799 theory, a client could receive requests and a server could receive 800 responses, distinguishing them by their different start-line formats, 801 but in practice servers are implemented to only expect a request (a 802 response is interpreted as an unknown or invalid request method) and 803 clients are implemented to only expect a response. 805 HTTP-message = start-line 806 *( header-field CRLF ) 807 CRLF 808 [ message-body ] 809 start-line = Request-Line / Status-Line 811 Whitespace (WSP) MUST NOT be sent between the start-line and the 812 first header field. The presence of whitespace might be an attempt 813 to trick a noncompliant implementation of HTTP into ignoring that 814 field or processing the next line as a new request, either of which 815 may result in security issues when implementations within the request 816 chain interpret the same message differently. HTTP/1.1 servers MUST 817 reject such a message with a 400 (Bad Request) response. 819 3.1. Message Parsing Robustness 821 In the interest of robustness, servers SHOULD ignore at least one 822 empty line received where a Request-Line is expected. In other 823 words, if the server is reading the protocol stream at the beginning 824 of a message and receives a CRLF first, it should ignore the CRLF. 826 Some old HTTP/1.0 client implementations generate an extra CRLF after 827 a POST request as a lame workaround for some early server 828 applications that failed to read message-body content that was not 829 terminated by a line-ending. An HTTP/1.1 client MUST NOT preface or 830 follow a request with an extra CRLF. If terminating the request 831 message-body with a line-ending is desired, then the client MUST 832 include the terminating CRLF octets as part of the message-body 833 length. 835 The normal procedure for parsing an HTTP message is to read the 836 start-line into a structure, read each header field into a hash table 837 by field name until the empty line, and then use the parsed data to 838 determine if a message-body is expected. If a message-body has been 839 indicated, then it is read as a stream until an amount of OCTETs 840 equal to the message-length is read or the connection is closed. 841 Care must be taken to parse an HTTP message as a sequence of OCTETs 842 in an encoding that is a superset of US-ASCII. Attempting to parse 843 HTTP as a stream of Unicode characters in a character encoding like 844 UTF-16 may introduce security flaws due to the differing ways that 845 such parsers interpret invalid characters. 847 3.2. Header Fields 849 Each HTTP header field consists of a case-insensitive field name 850 followed by a colon (":"), optional whitespace, and the field value. 852 header-field = field-name ":" OWS [ field-value ] OWS 853 field-name = token 854 field-value = *( field-content / OWS ) 855 field-content = *( WSP / VCHAR / obs-text ) 857 No whitespace is allowed between the header field name and colon. 858 For security reasons, any request message received containing such 859 whitespace MUST be rejected with a response code of 400 (Bad 860 Request). A proxy MUST remove any such whitespace from a response 861 message before forwarding the message downstream. 863 A field value MAY be preceded by optional whitespace (OWS); a single 864 SP is preferred. The field value does not include any leading or 865 trailing white space: OWS occurring before the first non-whitespace 866 character of the field value or after the last non-whitespace 867 character of the field value is ignored and SHOULD be removed without 868 changing the meaning of the header field. 870 The order in which header fields with differing field names are 871 received is not significant. However, it is "good practice" to send 872 header fields that contain control data first, such as Host on 873 requests and Date on responses, so that implementations can decide 874 when not to handle a message as early as possible. A server MUST 875 wait until the entire header section is received before interpreting 876 a request message, since later header fields might include 877 conditionals, authentication credentials, or deliberately misleading 878 duplicate header fields that would impact request processing. 880 Multiple header fields with the same field name MUST NOT be sent in a 881 message unless the entire field value for that header field is 882 defined as a comma-separated list [i.e., #(values)]. Multiple header 883 fields with the same field name can be combined into one "field-name: 884 field-value" pair, without changing the semantics of the message, by 885 appending each subsequent field value to the combined field value in 886 order, separated by a comma. The order in which header fields with 887 the same field name are received is therefore significant to the 888 interpretation of the combined field value; a proxy MUST NOT change 889 the order of these field values when forwarding a message. 891 Note: the "Set-Cookie" header as implemented in practice (as 892 opposed to how it is specified in [RFC2109]) can occur multiple 893 times, but does not use the list syntax, and thus cannot be 894 combined into a single line. (See Appendix A.2.3 of [Kri2001] for 895 details.) Also note that the Set-Cookie2 header specified in 896 [RFC2965] does not share this problem. 898 Historically, HTTP header field values could be extended over 899 multiple lines by preceding each extra line with at least one space 900 or horizontal tab character (line folding). This specification 901 deprecates such line folding except within the message/http media 902 type (Section 10.3.1). HTTP/1.1 senders MUST NOT produce messages 903 that include line folding (i.e., that contain any field-content that 904 matches the obs-fold rule) unless the message is intended for 905 packaging within the message/http media type. HTTP/1.1 recipients 906 SHOULD accept line folding and replace any embedded obs-fold 907 whitespace with a single SP prior to interpreting the field value or 908 forwarding the message downstream. 910 Historically, HTTP has allowed field content with text in the ISO- 911 8859-1 [ISO-8859-1] character encoding and supported other character 912 sets only through use of [RFC2047] encoding. In practice, most HTTP 913 header field values use only a subset of the US-ASCII character 914 encoding [USASCII]. Newly defined header fields SHOULD limit their 915 field values to US-ASCII characters. Recipients SHOULD treat other 916 (obs-text) octets in field content as opaque data. 918 Comments can be included in some HTTP header fields by surrounding 919 the comment text with parentheses. Comments are only allowed in 920 fields containing "comment" as part of their field value definition. 922 comment = "(" *( ctext / quoted-cpair / comment ) ")" 923 ctext = OWS / %x21-27 / %x2A-5B / %x5D-7E / obs-text 924 ; OWS / / obs-text 926 The backslash character ("\") can be used as a single-character 927 quoting mechanism within comment constructs: 929 quoted-cpair = "\" ( WSP / VCHAR / obs-text ) 931 Producers SHOULD NOT escape characters that do not require escaping 932 (i.e., other than the backslash character "\" and the parentheses "(" 933 and ")"). 935 3.3. Message Body 937 The message-body (if any) of an HTTP message is used to carry the 938 entity-body associated with the request or response. The message- 939 body differs from the entity-body only when a transfer-coding has 940 been applied, as indicated by the Transfer-Encoding header field 941 (Section 9.7). 943 message-body = entity-body 944 / 946 Transfer-Encoding MUST be used to indicate any transfer-codings 947 applied by an application to ensure safe and proper transfer of the 948 message. Transfer-Encoding is a property of the message, not of the 949 entity, and thus MAY be added or removed by any application along the 950 request/response chain. (However, Section 6.2 places restrictions on 951 when certain transfer-codings may be used.) 953 The rules for when a message-body is allowed in a message differ for 954 requests and responses. 956 The presence of a message-body in a request is signaled by the 957 inclusion of a Content-Length or Transfer-Encoding header field in 958 the request's header fields. When a request message contains both a 959 message-body of non-zero length and a method that does not define any 960 semantics for that request message-body, then an origin server SHOULD 961 either ignore the message-body or respond with an appropriate error 962 message (e.g., 413). A proxy or gateway, when presented the same 963 request, SHOULD either forward the request inbound with the message- 964 body or ignore the message-body when determining a response. 966 For response messages, whether or not a message-body is included with 967 a message is dependent on both the request method and the response 968 status code (Section 5.1.1). All responses to the HEAD request 969 method MUST NOT include a message-body, even though the presence of 970 entity-header fields might lead one to believe they do. All 1xx 971 (informational), 204 (No Content), and 304 (Not Modified) responses 972 MUST NOT include a message-body. All other responses do include a 973 message-body, although it MAY be of zero length. 975 3.4. Message Length 977 The transfer-length of a message is the length of the message-body as 978 it appears in the message; that is, after any transfer-codings have 979 been applied. When a message-body is included with a message, the 980 transfer-length of that body is determined by one of the following 981 (in order of precedence): 983 1. Any response message which "MUST NOT" include a message-body 984 (such as the 1xx, 204, and 304 responses and any response to a 985 HEAD request) is always terminated by the first empty line after 986 the header fields, regardless of the entity-header fields present 987 in the message. 989 2. If a Transfer-Encoding header field (Section 9.7) is present and 990 the "chunked" transfer-coding (Section 6.2) is used, the 991 transfer-length is defined by the use of this transfer-coding. 992 If a Transfer-Encoding header field is present and the "chunked" 993 transfer-coding is not present, the transfer-length is defined by 994 the sender closing the connection. 996 3. If a Content-Length header field (Section 9.2) is present, its 997 value in OCTETs represents both the entity-length and the 998 transfer-length. The Content-Length header field MUST NOT be 999 sent if these two lengths are different (i.e., if a Transfer- 1000 Encoding header field is present). If a message is received with 1001 both a Transfer-Encoding header field and a Content-Length header 1002 field, the latter MUST be ignored. 1004 4. If the message uses the media type "multipart/byteranges", and 1005 the transfer-length is not otherwise specified, then this self- 1006 delimiting media type defines the transfer-length. This media 1007 type MUST NOT be used unless the sender knows that the recipient 1008 can parse it; the presence in a request of a Range header with 1009 multiple byte-range specifiers from a 1.1 client implies that the 1010 client can parse multipart/byteranges responses. 1012 A range header might be forwarded by a 1.0 proxy that does not 1013 understand multipart/byteranges; in this case the server MUST 1014 delimit the message using methods defined in items 1, 3 or 5 1015 of this section. 1017 5. By the server closing the connection. (Closing the connection 1018 cannot be used to indicate the end of a request body, since that 1019 would leave no possibility for the server to send back a 1020 response.) 1022 For compatibility with HTTP/1.0 applications, HTTP/1.1 requests 1023 containing a message-body MUST include a valid Content-Length header 1024 field unless the server is known to be HTTP/1.1 compliant. If a 1025 request contains a message-body and a Content-Length is not given, 1026 the server SHOULD respond with 400 (Bad Request) if it cannot 1027 determine the length of the message, or with 411 (Length Required) if 1028 it wishes to insist on receiving a valid Content-Length. 1030 All HTTP/1.1 applications that receive entities MUST accept the 1031 "chunked" transfer-coding (Section 6.2), thus allowing this mechanism 1032 to be used for messages when the message length cannot be determined 1033 in advance. 1035 Messages MUST NOT include both a Content-Length header field and a 1036 transfer-coding. If the message does include a transfer-coding, the 1037 Content-Length MUST be ignored. 1039 When a Content-Length is given in a message where a message-body is 1040 allowed, its field value MUST exactly match the number of OCTETs in 1041 the message-body. HTTP/1.1 user agents MUST notify the user when an 1042 invalid length is received and detected. 1044 3.5. General Header Fields 1046 There are a few header fields which have general applicability for 1047 both request and response messages, but which do not apply to the 1048 entity being transferred. These header fields apply only to the 1049 message being transmitted. 1051 general-header = Cache-Control ; [Part6], Section 3.2 1052 / Connection ; Section 9.1 1053 / Date ; Section 9.3 1054 / Pragma ; [Part6], Section 3.4 1055 / Trailer ; Section 9.6 1056 / Transfer-Encoding ; Section 9.7 1057 / Upgrade ; Section 9.8 1058 / Via ; Section 9.9 1059 / Warning ; [Part6], Section 3.6 1061 General-header field names can be extended reliably only in 1062 combination with a change in the protocol version. However, new or 1063 experimental header fields may be given the semantics of general 1064 header fields if all parties in the communication recognize them to 1065 be general-header fields. Unrecognized header fields are treated as 1066 entity-header fields. 1068 4. Request 1070 A request message from a client to a server includes, within the 1071 first line of that message, the method to be applied to the resource, 1072 the identifier of the resource, and the protocol version in use. 1074 Request = Request-Line ; Section 4.1 1075 *(( general-header ; Section 3.5 1076 / request-header ; [Part2], Section 3 1077 / entity-header ) CRLF ) ; [Part3], Section 3.1 1078 CRLF 1079 [ message-body ] ; Section 3.3 1081 4.1. Request-Line 1083 The Request-Line begins with a method token, followed by the request- 1084 target and the protocol version, and ending with CRLF. The elements 1085 are separated by SP characters. No CR or LF is allowed except in the 1086 final CRLF sequence. 1088 Request-Line = Method SP request-target SP HTTP-Version CRLF 1090 4.1.1. Method 1092 The Method token indicates the method to be performed on the resource 1093 identified by the request-target. The method is case-sensitive. 1095 Method = token 1097 4.1.2. request-target 1099 The request-target identifies the resource upon which to apply the 1100 request. 1102 request-target = "*" 1103 / absolute-URI 1104 / ( path-absolute [ "?" query ] ) 1105 / authority 1107 The four options for request-target are dependent on the nature of 1108 the request. The asterisk "*" means that the request does not apply 1109 to a particular resource, but to the server itself, and is only 1110 allowed when the method used does not necessarily apply to a 1111 resource. One example would be 1113 OPTIONS * HTTP/1.1 1115 The absolute-URI form is REQUIRED when the request is being made to a 1116 proxy. The proxy is requested to forward the request or service it 1117 from a valid cache, and return the response. Note that the proxy MAY 1118 forward the request on to another proxy or directly to the server 1119 specified by the absolute-URI. In order to avoid request loops, a 1120 proxy MUST be able to recognize all of its server names, including 1121 any aliases, local variations, and the numeric IP address. An 1122 example Request-Line would be: 1124 GET http://www.example.org/pub/WWW/TheProject.html HTTP/1.1 1126 To allow for transition to absolute-URIs in all requests in future 1127 versions of HTTP, all HTTP/1.1 servers MUST accept the absolute-URI 1128 form in requests, even though HTTP/1.1 clients will only generate 1129 them in requests to proxies. 1131 The authority form is only used by the CONNECT method (Section 7.9 of 1132 [Part2]). 1134 The most common form of request-target is that used to identify a 1135 resource on an origin server or gateway. In this case the absolute 1136 path of the URI MUST be transmitted (see Section 2.6.1, path- 1137 absolute) as the request-target, and the network location of the URI 1138 (authority) MUST be transmitted in a Host header field. For example, 1139 a client wishing to retrieve the resource above directly from the 1140 origin server would create a TCP connection to port 80 of the host 1141 "www.example.org" and send the lines: 1143 GET /pub/WWW/TheProject.html HTTP/1.1 1144 Host: www.example.org 1146 followed by the remainder of the Request. Note that the absolute 1147 path cannot be empty; if none is present in the original URI, it MUST 1148 be given as "/" (the server root). 1150 If a proxy receives a request without any path in the request-target 1151 and the method specified is capable of supporting the asterisk form 1152 of request-target, then the last proxy on the request chain MUST 1153 forward the request with "*" as the final request-target. 1155 For example, the request 1157 OPTIONS http://www.example.org:8001 HTTP/1.1 1159 would be forwarded by the proxy as 1161 OPTIONS * HTTP/1.1 1162 Host: www.example.org:8001 1164 after connecting to port 8001 of host "www.example.org". 1166 The request-target is transmitted in the format specified in 1167 Section 2.6.1. If the request-target is percent-encoded ([RFC3986], 1168 Section 2.1), the origin server MUST decode the request-target in 1169 order to properly interpret the request. Servers SHOULD respond to 1170 invalid request-targets with an appropriate status code. 1172 A transparent proxy MUST NOT rewrite the "path-absolute" part of the 1173 received request-target when forwarding it to the next inbound 1174 server, except as noted above to replace a null path-absolute with 1175 "/". 1177 Note: The "no rewrite" rule prevents the proxy from changing the 1178 meaning of the request when the origin server is improperly using 1179 a non-reserved URI character for a reserved purpose. Implementors 1180 should be aware that some pre-HTTP/1.1 proxies have been known to 1181 rewrite the request-target. 1183 HTTP does not place a pre-defined limit on the length of a request- 1184 target. A server MUST be prepared to receive URIs of unbounded 1185 length and respond with the 414 (URI Too Long) status if the received 1186 request-target would be longer than the server wishes to handle (see 1187 Section 8.4.15 of [Part2]). 1189 Various ad-hoc limitations on request-target length are found in 1190 practice. It is RECOMMENDED that all HTTP senders and recipients 1191 support request-target lengths of 8000 or more OCTETs. 1193 4.2. The Resource Identified by a Request 1195 The exact resource identified by an Internet request is determined by 1196 examining both the request-target and the Host header field. 1198 An origin server that does not allow resources to differ by the 1199 requested host MAY ignore the Host header field value when 1200 determining the resource identified by an HTTP/1.1 request. (But see 1201 Appendix B.1.1 for other requirements on Host support in HTTP/1.1.) 1202 An origin server that does differentiate resources based on the host 1203 requested (sometimes referred to as virtual hosts or vanity host 1204 names) MUST use the following rules for determining the requested 1205 resource on an HTTP/1.1 request: 1207 1. If request-target is an absolute-URI, the host is part of the 1208 request-target. Any Host header field value in the request MUST 1209 be ignored. 1211 2. If the request-target is not an absolute-URI, and the request 1212 includes a Host header field, the host is determined by the Host 1213 header field value. 1215 3. If the host as determined by rule 1 or 2 is not a valid host on 1216 the server, the response MUST be a 400 (Bad Request) error 1217 message. 1219 Recipients of an HTTP/1.0 request that lacks a Host header field MAY 1220 attempt to use heuristics (e.g., examination of the URI path for 1221 something unique to a particular host) in order to determine what 1222 exact resource is being requested. 1224 5. Response 1226 After receiving and interpreting a request message, a server responds 1227 with an HTTP response message. 1229 Response = Status-Line ; Section 5.1 1230 *(( general-header ; Section 3.5 1231 / response-header ; [Part2], Section 5 1232 / entity-header ) CRLF ) ; [Part3], Section 3.1 1233 CRLF 1234 [ message-body ] ; Section 3.3 1236 5.1. Status-Line 1238 The first line of a Response message is the Status-Line, consisting 1239 of the protocol version followed by a numeric status code and its 1240 associated textual phrase, with each element separated by SP 1241 characters. No CR or LF is allowed except in the final CRLF 1242 sequence. 1244 Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF 1246 5.1.1. Status Code and Reason Phrase 1248 The Status-Code element is a 3-digit integer result code of the 1249 attempt to understand and satisfy the request. These codes are fully 1250 defined in Section 8 of [Part2]. The Reason Phrase exists for the 1251 sole purpose of providing a textual description associated with the 1252 numeric status code, out of deference to earlier Internet application 1253 protocols that were more frequently used with interactive text 1254 clients. A client SHOULD ignore the content of the Reason Phrase. 1256 The first digit of the Status-Code defines the class of response. 1257 The last two digits do not have any categorization role. There are 5 1258 values for the first digit: 1260 o 1xx: Informational - Request received, continuing process 1262 o 2xx: Success - The action was successfully received, understood, 1263 and accepted 1265 o 3xx: Redirection - Further action must be taken in order to 1266 complete the request 1268 o 4xx: Client Error - The request contains bad syntax or cannot be 1269 fulfilled 1271 o 5xx: Server Error - The server failed to fulfill an apparently 1272 valid request 1274 Status-Code = 3DIGIT 1275 Reason-Phrase = *( WSP / VCHAR / obs-text ) 1277 6. Protocol Parameters 1279 6.1. Date/Time Formats: Full Date 1281 HTTP applications have historically allowed three different formats 1282 for the representation of date/time stamps: 1284 Sun, 06 Nov 1994 08:49:37 GMT ; RFC 1123 1285 Sunday, 06-Nov-94 08:49:37 GMT ; obsolete RFC 850 format 1286 Sun Nov 6 08:49:37 1994 ; ANSI C's asctime() format 1288 The first format is preferred as an Internet standard and represents 1289 a fixed-length subset of that defined by [RFC1123]. The other 1290 formats are described here only for compatibility with obsolete 1291 implementations. HTTP/1.1 clients and servers that parse the date 1292 value MUST accept all three formats (for compatibility with 1293 HTTP/1.0), though they MUST only generate the RFC 1123 format for 1294 representing HTTP-date values in header fields. See Appendix A for 1295 further information. 1297 All HTTP date/time stamps MUST be represented in Greenwich Mean Time 1298 (GMT), without exception. For the purposes of HTTP, GMT is exactly 1299 equal to UTC (Coordinated Universal Time). This is indicated in the 1300 first two formats by the inclusion of "GMT" as the three-letter 1301 abbreviation for time zone, and MUST be assumed when reading the 1302 asctime format. HTTP-date is case sensitive and MUST NOT include 1303 additional whitespace beyond that specifically included as SP in the 1304 grammar. 1306 HTTP-date = rfc1123-date / obs-date 1308 Preferred format: 1310 rfc1123-date = day-name "," SP date1 SP time-of-day SP GMT 1312 day-name = %x4D.6F.6E ; "Mon", case-sensitive 1313 / %x54.75.65 ; "Tue", case-sensitive 1314 / %x57.65.64 ; "Wed", case-sensitive 1315 / %x54.68.75 ; "Thu", case-sensitive 1316 / %x46.72.69 ; "Fri", case-sensitive 1317 / %x53.61.74 ; "Sat", case-sensitive 1318 / %x53.75.6E ; "Sun", case-sensitive 1320 date1 = day SP month SP year 1321 ; e.g., 02 Jun 1982 1323 day = 2DIGIT 1324 month = %x4A.61.6E ; "Jan", case-sensitive 1325 / %x46.65.62 ; "Feb", case-sensitive 1326 / %x4D.61.72 ; "Mar", case-sensitive 1327 / %x41.70.72 ; "Apr", case-sensitive 1328 / %x4D.61.79 ; "May", case-sensitive 1329 / %x4A.75.6E ; "Jun", case-sensitive 1330 / %x4A.75.6C ; "Jul", case-sensitive 1331 / %x41.75.67 ; "Aug", case-sensitive 1332 / %x53.65.70 ; "Sep", case-sensitive 1333 / %x4F.63.74 ; "Oct", case-sensitive 1334 / %x4E.6F.76 ; "Nov", case-sensitive 1335 / %x44.65.63 ; "Dec", case-sensitive 1336 year = 4DIGIT 1338 GMT = %x47.4D.54 ; "GMT", case-sensitive 1340 time-of-day = hour ":" minute ":" second 1341 ; 00:00:00 - 23:59:59 1343 hour = 2DIGIT 1344 minute = 2DIGIT 1345 second = 2DIGIT 1347 The semantics of day-name, day, month, year, and time-of-day are the 1348 same as those defined for the RFC 5322 constructs with the 1349 corresponding name ([RFC5322], Section 3.3). 1351 Obsolete formats: 1353 obs-date = rfc850-date / asctime-date 1354 rfc850-date = day-name-l "," SP date2 SP time-of-day SP GMT 1355 date2 = day "-" month "-" 2DIGIT 1356 ; day-month-year (e.g., 02-Jun-82) 1358 day-name-l = %x4D.6F.6E.64.61.79 ; "Monday", case-sensitive 1359 / %x54.75.65.73.64.61.79 ; "Tuesday", case-sensitive 1360 / %x57.65.64.6E.65.73.64.61.79 ; "Wednesday", case-sensitive 1361 / %x54.68.75.72.73.64.61.79 ; "Thursday", case-sensitive 1362 / %x46.72.69.64.61.79 ; "Friday", case-sensitive 1363 / %x53.61.74.75.72.64.61.79 ; "Saturday", case-sensitive 1364 / %x53.75.6E.64.61.79 ; "Sunday", case-sensitive 1366 asctime-date = day-name SP date3 SP time-of-day SP year 1367 date3 = month SP ( 2DIGIT / ( SP 1DIGIT )) 1368 ; month day (e.g., Jun 2) 1370 Note: Recipients of date values are encouraged to be robust in 1371 accepting date values that may have been sent by non-HTTP 1372 applications, as is sometimes the case when retrieving or posting 1373 messages via proxies/gateways to SMTP or NNTP. 1375 Note: HTTP requirements for the date/time stamp format apply only 1376 to their usage within the protocol stream. Clients and servers 1377 are not required to use these formats for user presentation, 1378 request logging, etc. 1380 6.2. Transfer Codings 1382 Transfer-coding values are used to indicate an encoding 1383 transformation that has been, can be, or may need to be applied to an 1384 entity-body in order to ensure "safe transport" through the network. 1385 This differs from a content coding in that the transfer-coding is a 1386 property of the message, not of the original entity. 1388 transfer-coding = "chunked" ; Section 6.2.1 1389 / "compress" ; Section 6.2.2.1 1390 / "deflate" ; Section 6.2.2.2 1391 / "gzip" ; Section 6.2.2.3 1392 / transfer-extension 1393 transfer-extension = token *( OWS ";" OWS transfer-parameter ) 1395 Parameters are in the form of attribute/value pairs. 1397 transfer-parameter = attribute BWS "=" BWS value 1398 attribute = token 1399 value = token / quoted-string 1401 All transfer-coding values are case-insensitive. HTTP/1.1 uses 1402 transfer-coding values in the TE header field (Section 9.5) and in 1403 the Transfer-Encoding header field (Section 9.7). 1405 Whenever a transfer-coding is applied to a message-body, the set of 1406 transfer-codings MUST include "chunked", unless the message indicates 1407 it is terminated by closing the connection. When the "chunked" 1408 transfer-coding is used, it MUST be the last transfer-coding applied 1409 to the message-body. The "chunked" transfer-coding MUST NOT be 1410 applied more than once to a message-body. These rules allow the 1411 recipient to determine the transfer-length of the message 1412 (Section 3.4). 1414 Transfer-codings are analogous to the Content-Transfer-Encoding 1415 values of MIME, which were designed to enable safe transport of 1416 binary data over a 7-bit transport service ([RFC2045], Section 6). 1417 However, safe transport has a different focus for an 8bit-clean 1418 transfer protocol. In HTTP, the only unsafe characteristic of 1419 message-bodies is the difficulty in determining the exact body length 1420 (Section 3.4), or the desire to encrypt data over a shared transport. 1422 A server which receives an entity-body with a transfer-coding it does 1423 not understand SHOULD return 501 (Not Implemented), and close the 1424 connection. A server MUST NOT send transfer-codings to an HTTP/1.0 1425 client. 1427 6.2.1. Chunked Transfer Coding 1429 The chunked encoding modifies the body of a message in order to 1430 transfer it as a series of chunks, each with its own size indicator, 1431 followed by an OPTIONAL trailer containing entity-header fields. 1432 This allows dynamically produced content to be transferred along with 1433 the information necessary for the recipient to verify that it has 1434 received the full message. 1436 Chunked-Body = *chunk 1437 last-chunk 1438 trailer-part 1439 CRLF 1441 chunk = chunk-size *WSP [ chunk-ext ] CRLF 1442 chunk-data CRLF 1443 chunk-size = 1*HEXDIG 1444 last-chunk = 1*("0") *WSP [ chunk-ext ] CRLF 1446 chunk-ext = *( ";" *WSP chunk-ext-name 1447 [ "=" chunk-ext-val ] *WSP ) 1448 chunk-ext-name = token 1449 chunk-ext-val = token / quoted-str-nf 1450 chunk-data = 1*OCTET ; a sequence of chunk-size octets 1451 trailer-part = *( entity-header CRLF ) 1453 quoted-str-nf = DQUOTE *( qdtext-nf / quoted-pair ) DQUOTE 1454 ; like quoted-string, but disallowing line folding 1455 qdtext-nf = WSP / %x21 / %x23-5B / %x5D-7E / obs-text 1456 ; WSP / / obs-text 1458 The chunk-size field is a string of hex digits indicating the size of 1459 the chunk-data in octets. The chunked encoding is ended by any chunk 1460 whose size is zero, followed by the trailer, which is terminated by 1461 an empty line. 1463 The trailer allows the sender to include additional HTTP header 1464 fields at the end of the message. The Trailer header field can be 1465 used to indicate which header fields are included in a trailer (see 1466 Section 9.6). 1468 A server using chunked transfer-coding in a response MUST NOT use the 1469 trailer for any header fields unless at least one of the following is 1470 true: 1472 1. the request included a TE header field that indicates "trailers" 1473 is acceptable in the transfer-coding of the response, as 1474 described in Section 9.5; or, 1476 2. the server is the origin server for the response, the trailer 1477 fields consist entirely of optional metadata, and the recipient 1478 could use the message (in a manner acceptable to the origin 1479 server) without receiving this metadata. In other words, the 1480 origin server is willing to accept the possibility that the 1481 trailer fields might be silently discarded along the path to the 1482 client. 1484 This requirement prevents an interoperability failure when the 1485 message is being received by an HTTP/1.1 (or later) proxy and 1486 forwarded to an HTTP/1.0 recipient. It avoids a situation where 1487 compliance with the protocol would have necessitated a possibly 1488 infinite buffer on the proxy. 1490 A process for decoding the "chunked" transfer-coding can be 1491 represented in pseudo-code as: 1493 length := 0 1494 read chunk-size, chunk-ext (if any) and CRLF 1495 while (chunk-size > 0) { 1496 read chunk-data and CRLF 1497 append chunk-data to entity-body 1498 length := length + chunk-size 1499 read chunk-size and CRLF 1500 } 1501 read entity-header 1502 while (entity-header not empty) { 1503 append entity-header to existing header fields 1504 read entity-header 1505 } 1506 Content-Length := length 1507 Remove "chunked" from Transfer-Encoding 1509 All HTTP/1.1 applications MUST be able to receive and decode the 1510 "chunked" transfer-coding, and MUST ignore chunk-ext extensions they 1511 do not understand. 1513 6.2.2. Compression Codings 1515 The codings defined below can be used to compress the payload of a 1516 message. 1518 Note: Use of program names for the identification of encoding 1519 formats is not desirable and is discouraged for future encodings. 1520 Their use here is representative of historical practice, not good 1521 design. 1523 Note: For compatibility with previous implementations of HTTP, 1524 applications SHOULD consider "x-gzip" and "x-compress" to be 1525 equivalent to "gzip" and "compress" respectively. 1527 6.2.2.1. Compress Coding 1529 The "compress" format is produced by the common UNIX file compression 1530 program "compress". This format is an adaptive Lempel-Ziv-Welch 1531 coding (LZW). 1533 6.2.2.2. Deflate Coding 1535 The "zlib" format is defined in [RFC1950] in combination with the 1536 "deflate" compression mechanism described in [RFC1951]. 1538 6.2.2.3. Gzip Coding 1540 The "gzip" format is produced by the file compression program "gzip" 1541 (GNU zip), as described in [RFC1952]. This format is a Lempel-Ziv 1542 coding (LZ77) with a 32 bit CRC. 1544 6.2.3. Transfer Coding Registry 1546 The HTTP Transfer Coding Registry defines the name space for the 1547 transfer coding names. 1549 Registrations MUST include the following fields: 1551 o Name 1553 o Description 1555 o Pointer to specification text 1557 Values to be added to this name space require expert review and a 1558 specification (see "Expert Review" and "Specification Required" in 1559 Section 4.1 of [RFC5226]), and MUST conform to the purpose of 1560 transfer coding defined in this section. 1562 The registry itself is maintained at 1563 . 1565 6.3. Product Tokens 1567 Product tokens are used to allow communicating applications to 1568 identify themselves by software name and version. Most fields using 1569 product tokens also allow sub-products which form a significant part 1570 of the application to be listed, separated by whitespace. By 1571 convention, the products are listed in order of their significance 1572 for identifying the application. 1574 product = token ["/" product-version] 1575 product-version = token 1577 Examples: 1579 User-Agent: CERN-LineMode/2.15 libwww/2.17b3 1580 Server: Apache/0.8.4 1582 Product tokens SHOULD be short and to the point. They MUST NOT be 1583 used for advertising or other non-essential information. Although 1584 any token character MAY appear in a product-version, this token 1585 SHOULD only be used for a version identifier (i.e., successive 1586 versions of the same product SHOULD only differ in the product- 1587 version portion of the product value). 1589 6.4. Quality Values 1591 Both transfer codings (TE request header, Section 9.5) and content 1592 negotiation (Section 4 of [Part3]) use short "floating point" numbers 1593 to indicate the relative importance ("weight") of various negotiable 1594 parameters. A weight is normalized to a real number in the range 0 1595 through 1, where 0 is the minimum and 1 the maximum value. If a 1596 parameter has a quality value of 0, then content with this parameter 1597 is `not acceptable' for the client. HTTP/1.1 applications MUST NOT 1598 generate more than three digits after the decimal point. User 1599 configuration of these values SHOULD also be limited in this fashion. 1601 qvalue = ( "0" [ "." 0*3DIGIT ] ) 1602 / ( "1" [ "." 0*3("0") ] ) 1604 Note: "Quality values" is a misnomer, since these values merely 1605 represent relative degradation in desired quality. 1607 7. Connections 1609 7.1. Persistent Connections 1611 7.1.1. Purpose 1613 Prior to persistent connections, a separate TCP connection was 1614 established to fetch each URL, increasing the load on HTTP servers 1615 and causing congestion on the Internet. The use of inline images and 1616 other associated data often require a client to make multiple 1617 requests of the same server in a short amount of time. Analysis of 1618 these performance problems and results from a prototype 1619 implementation are available [Pad1995] [Spe]. Implementation 1620 experience and measurements of actual HTTP/1.1 implementations show 1621 good results [Nie1997]. Alternatives have also been explored, for 1622 example, T/TCP [Tou1998]. 1624 Persistent HTTP connections have a number of advantages: 1626 o By opening and closing fewer TCP connections, CPU time is saved in 1627 routers and hosts (clients, servers, proxies, gateways, tunnels, 1628 or caches), and memory used for TCP protocol control blocks can be 1629 saved in hosts. 1631 o HTTP requests and responses can be pipelined on a connection. 1632 Pipelining allows a client to make multiple requests without 1633 waiting for each response, allowing a single TCP connection to be 1634 used much more efficiently, with much lower elapsed time. 1636 o Network congestion is reduced by reducing the number of packets 1637 caused by TCP opens, and by allowing TCP sufficient time to 1638 determine the congestion state of the network. 1640 o Latency on subsequent requests is reduced since there is no time 1641 spent in TCP's connection opening handshake. 1643 o HTTP can evolve more gracefully, since errors can be reported 1644 without the penalty of closing the TCP connection. Clients using 1645 future versions of HTTP might optimistically try a new feature, 1646 but if communicating with an older server, retry with old 1647 semantics after an error is reported. 1649 HTTP implementations SHOULD implement persistent connections. 1651 7.1.2. Overall Operation 1653 A significant difference between HTTP/1.1 and earlier versions of 1654 HTTP is that persistent connections are the default behavior of any 1655 HTTP connection. That is, unless otherwise indicated, the client 1656 SHOULD assume that the server will maintain a persistent connection, 1657 even after error responses from the server. 1659 Persistent connections provide a mechanism by which a client and a 1660 server can signal the close of a TCP connection. This signaling 1661 takes place using the Connection header field (Section 9.1). Once a 1662 close has been signaled, the client MUST NOT send any more requests 1663 on that connection. 1665 7.1.2.1. Negotiation 1667 An HTTP/1.1 server MAY assume that a HTTP/1.1 client intends to 1668 maintain a persistent connection unless a Connection header including 1669 the connection-token "close" was sent in the request. If the server 1670 chooses to close the connection immediately after sending the 1671 response, it SHOULD send a Connection header including the 1672 connection-token close. 1674 An HTTP/1.1 client MAY expect a connection to remain open, but would 1675 decide to keep it open based on whether the response from a server 1676 contains a Connection header with the connection-token close. In 1677 case the client does not want to maintain a connection for more than 1678 that request, it SHOULD send a Connection header including the 1679 connection-token close. 1681 If either the client or the server sends the close token in the 1682 Connection header, that request becomes the last one for the 1683 connection. 1685 Clients and servers SHOULD NOT assume that a persistent connection is 1686 maintained for HTTP versions less than 1.1 unless it is explicitly 1687 signaled. See Appendix B.2 for more information on backward 1688 compatibility with HTTP/1.0 clients. 1690 In order to remain persistent, all messages on the connection MUST 1691 have a self-defined message length (i.e., one not defined by closure 1692 of the connection), as described in Section 3.4. 1694 7.1.2.2. Pipelining 1696 A client that supports persistent connections MAY "pipeline" its 1697 requests (i.e., send multiple requests without waiting for each 1698 response). A server MUST send its responses to those requests in the 1699 same order that the requests were received. 1701 Clients which assume persistent connections and pipeline immediately 1702 after connection establishment SHOULD be prepared to retry their 1703 connection if the first pipelined attempt fails. If a client does 1704 such a retry, it MUST NOT pipeline before it knows the connection is 1705 persistent. Clients MUST also be prepared to resend their requests 1706 if the server closes the connection before sending all of the 1707 corresponding responses. 1709 Clients SHOULD NOT pipeline requests using non-idempotent methods or 1710 non-idempotent sequences of methods (see Section 7.1.2 of [Part2]). 1711 Otherwise, a premature termination of the transport connection could 1712 lead to indeterminate results. A client wishing to send a non- 1713 idempotent request SHOULD wait to send that request until it has 1714 received the response status for the previous request. 1716 7.1.3. Proxy Servers 1718 It is especially important that proxies correctly implement the 1719 properties of the Connection header field as specified in 1720 Section 9.1. 1722 The proxy server MUST signal persistent connections separately with 1723 its clients and the origin servers (or other proxy servers) that it 1724 connects to. Each persistent connection applies to only one 1725 transport link. 1727 A proxy server MUST NOT establish a HTTP/1.1 persistent connection 1728 with an HTTP/1.0 client (but see Section 19.7.1 of [RFC2068] for 1729 information and discussion of the problems with the Keep-Alive header 1730 implemented by many HTTP/1.0 clients). 1732 7.1.4. Practical Considerations 1734 Servers will usually have some time-out value beyond which they will 1735 no longer maintain an inactive connection. Proxy servers might make 1736 this a higher value since it is likely that the client will be making 1737 more connections through the same server. The use of persistent 1738 connections places no requirements on the length (or existence) of 1739 this time-out for either the client or the server. 1741 When a client or server wishes to time-out it SHOULD issue a graceful 1742 close on the transport connection. Clients and servers SHOULD both 1743 constantly watch for the other side of the transport close, and 1744 respond to it as appropriate. If a client or server does not detect 1745 the other side's close promptly it could cause unnecessary resource 1746 drain on the network. 1748 A client, server, or proxy MAY close the transport connection at any 1749 time. For example, a client might have started to send a new request 1750 at the same time that the server has decided to close the "idle" 1751 connection. From the server's point of view, the connection is being 1752 closed while it was idle, but from the client's point of view, a 1753 request is in progress. 1755 This means that clients, servers, and proxies MUST be able to recover 1756 from asynchronous close events. Client software SHOULD reopen the 1757 transport connection and retransmit the aborted sequence of requests 1758 without user interaction so long as the request sequence is 1759 idempotent (see Section 7.1.2 of [Part2]). Non-idempotent methods or 1760 sequences MUST NOT be automatically retried, although user agents MAY 1761 offer a human operator the choice of retrying the request(s). 1762 Confirmation by user-agent software with semantic understanding of 1763 the application MAY substitute for user confirmation. The automatic 1764 retry SHOULD NOT be repeated if the second sequence of requests 1765 fails. 1767 Servers SHOULD always respond to at least one request per connection, 1768 if at all possible. Servers SHOULD NOT close a connection in the 1769 middle of transmitting a response, unless a network or client failure 1770 is suspected. 1772 Clients (including proxies) SHOULD limit the number of simultaneous 1773 connections that they maintain to a given server (including proxies). 1775 Previous revisions of HTTP gave a specific number of connections as a 1776 ceiling, but this was found to be impractical for many applications. 1777 As a result, this specification does not mandate a particular maximum 1778 number of connections, but instead encourages clients to be 1779 conservative when opening multiple connections. 1781 In particular, while using multiple connections avoids the "head-of- 1782 line blocking" problem (whereby a request that takes significant 1783 server-side processing and/or has a large payload can block 1784 subsequent requests on the same connection), each connection used 1785 consumes server resources (sometimes significantly), and furthermore 1786 using multiple connections can cause undesirable side effects in 1787 congested networks. 1789 Note that servers might reject traffic that they deem abusive, 1790 including an excessive number of connections from a client. 1792 7.2. Message Transmission Requirements 1794 7.2.1. Persistent Connections and Flow Control 1796 HTTP/1.1 servers SHOULD maintain persistent connections and use TCP's 1797 flow control mechanisms to resolve temporary overloads, rather than 1798 terminating connections with the expectation that clients will retry. 1799 The latter technique can exacerbate network congestion. 1801 7.2.2. Monitoring Connections for Error Status Messages 1803 An HTTP/1.1 (or later) client sending a message-body SHOULD monitor 1804 the network connection for an error status while it is transmitting 1805 the request. If the client sees an error status, it SHOULD 1806 immediately cease transmitting the body. If the body is being sent 1807 using a "chunked" encoding (Section 6.2), a zero length chunk and 1808 empty trailer MAY be used to prematurely mark the end of the message. 1809 If the body was preceded by a Content-Length header, the client MUST 1810 close the connection. 1812 7.2.3. Use of the 100 (Continue) Status 1814 The purpose of the 100 (Continue) status (see Section 8.1.1 of 1815 [Part2]) is to allow a client that is sending a request message with 1816 a request body to determine if the origin server is willing to accept 1817 the request (based on the request headers) before the client sends 1818 the request body. In some cases, it might either be inappropriate or 1819 highly inefficient for the client to send the body if the server will 1820 reject the message without looking at the body. 1822 Requirements for HTTP/1.1 clients: 1824 o If a client will wait for a 100 (Continue) response before sending 1825 the request body, it MUST send an Expect request-header field 1826 (Section 9.2 of [Part2]) with the "100-continue" expectation. 1828 o A client MUST NOT send an Expect request-header field (Section 9.2 1829 of [Part2]) with the "100-continue" expectation if it does not 1830 intend to send a request body. 1832 Because of the presence of older implementations, the protocol allows 1833 ambiguous situations in which a client may send "Expect: 100- 1834 continue" without receiving either a 417 (Expectation Failed) status 1835 or a 100 (Continue) status. Therefore, when a client sends this 1836 header field to an origin server (possibly via a proxy) from which it 1837 has never seen a 100 (Continue) status, the client SHOULD NOT wait 1838 for an indefinite period before sending the request body. 1840 Requirements for HTTP/1.1 origin servers: 1842 o Upon receiving a request which includes an Expect request-header 1843 field with the "100-continue" expectation, an origin server MUST 1844 either respond with 100 (Continue) status and continue to read 1845 from the input stream, or respond with a final status code. The 1846 origin server MUST NOT wait for the request body before sending 1847 the 100 (Continue) response. If it responds with a final status 1848 code, it MAY close the transport connection or it MAY continue to 1849 read and discard the rest of the request. It MUST NOT perform the 1850 requested method if it returns a final status code. 1852 o An origin server SHOULD NOT send a 100 (Continue) response if the 1853 request message does not include an Expect request-header field 1854 with the "100-continue" expectation, and MUST NOT send a 100 1855 (Continue) response if such a request comes from an HTTP/1.0 (or 1856 earlier) client. There is an exception to this rule: for 1857 compatibility with [RFC2068], a server MAY send a 100 (Continue) 1858 status in response to an HTTP/1.1 PUT or POST request that does 1859 not include an Expect request-header field with the "100-continue" 1860 expectation. This exception, the purpose of which is to minimize 1861 any client processing delays associated with an undeclared wait 1862 for 100 (Continue) status, applies only to HTTP/1.1 requests, and 1863 not to requests with any other HTTP-version value. 1865 o An origin server MAY omit a 100 (Continue) response if it has 1866 already received some or all of the request body for the 1867 corresponding request. 1869 o An origin server that sends a 100 (Continue) response MUST 1870 ultimately send a final status code, once the request body is 1871 received and processed, unless it terminates the transport 1872 connection prematurely. 1874 o If an origin server receives a request that does not include an 1875 Expect request-header field with the "100-continue" expectation, 1876 the request includes a request body, and the server responds with 1877 a final status code before reading the entire request body from 1878 the transport connection, then the server SHOULD NOT close the 1879 transport connection until it has read the entire request, or 1880 until the client closes the connection. Otherwise, the client 1881 might not reliably receive the response message. However, this 1882 requirement is not be construed as preventing a server from 1883 defending itself against denial-of-service attacks, or from badly 1884 broken client implementations. 1886 Requirements for HTTP/1.1 proxies: 1888 o If a proxy receives a request that includes an Expect request- 1889 header field with the "100-continue" expectation, and the proxy 1890 either knows that the next-hop server complies with HTTP/1.1 or 1891 higher, or does not know the HTTP version of the next-hop server, 1892 it MUST forward the request, including the Expect header field. 1894 o If the proxy knows that the version of the next-hop server is 1895 HTTP/1.0 or lower, it MUST NOT forward the request, and it MUST 1896 respond with a 417 (Expectation Failed) status. 1898 o Proxies SHOULD maintain a cache recording the HTTP version numbers 1899 received from recently-referenced next-hop servers. 1901 o A proxy MUST NOT forward a 100 (Continue) response if the request 1902 message was received from an HTTP/1.0 (or earlier) client and did 1903 not include an Expect request-header field with the "100-continue" 1904 expectation. This requirement overrides the general rule for 1905 forwarding of 1xx responses (see Section 8.1 of [Part2]). 1907 7.2.4. Client Behavior if Server Prematurely Closes Connection 1909 If an HTTP/1.1 client sends a request which includes a request body, 1910 but which does not include an Expect request-header field with the 1911 "100-continue" expectation, and if the client is not directly 1912 connected to an HTTP/1.1 origin server, and if the client sees the 1913 connection close before receiving any status from the server, the 1914 client SHOULD retry the request. If the client does retry this 1915 request, it MAY use the following "binary exponential backoff" 1916 algorithm to be assured of obtaining a reliable response: 1918 1. Initiate a new connection to the server 1920 2. Transmit the request-headers 1922 3. Initialize a variable R to the estimated round-trip time to the 1923 server (e.g., based on the time it took to establish the 1924 connection), or to a constant value of 5 seconds if the round- 1925 trip time is not available. 1927 4. Compute T = R * (2**N), where N is the number of previous retries 1928 of this request. 1930 5. Wait either for an error response from the server, or for T 1931 seconds (whichever comes first) 1933 6. If no error response is received, after T seconds transmit the 1934 body of the request. 1936 7. If client sees that the connection is closed prematurely, repeat 1937 from step 1 until the request is accepted, an error response is 1938 received, or the user becomes impatient and terminates the retry 1939 process. 1941 If at any point an error status is received, the client 1943 o SHOULD NOT continue and 1945 o SHOULD close the connection if it has not completed sending the 1946 request message. 1948 8. Miscellaneous notes that may disappear 1950 8.1. Scheme aliases considered harmful 1952 [[anchor2: TBS: describe why aliases like webcal are harmful.]] 1954 8.2. Use of HTTP for proxy communication 1956 [[anchor3: TBD: Configured to use HTTP to proxy HTTP or other 1957 protocols.]] 1959 8.3. Interception of HTTP for access control 1961 [[anchor4: TBD: Interception of HTTP traffic for initiating access 1962 control.]] 1964 8.4. Use of HTTP by other protocols 1966 [[anchor5: TBD: Profiles of HTTP defined by other protocol. 1967 Extensions of HTTP like WebDAV.]] 1969 8.5. Use of HTTP by media type specification 1971 [[anchor6: TBD: Instructions on composing HTTP requests via hypertext 1972 formats.]] 1974 9. Header Field Definitions 1976 This section defines the syntax and semantics of HTTP/1.1 header 1977 fields related to message framing and transport protocols. 1979 For entity-header fields, both sender and recipient refer to either 1980 the client or the server, depending on who sends and who receives the 1981 entity. 1983 9.1. Connection 1985 The "Connection" general-header field allows the sender to specify 1986 options that are desired for that particular connection and MUST NOT 1987 be communicated by proxies over further connections. 1989 The Connection header's value has the following grammar: 1991 Connection = "Connection" ":" OWS Connection-v 1992 Connection-v = 1#connection-token 1993 connection-token = token 1995 HTTP/1.1 proxies MUST parse the Connection header field before a 1996 message is forwarded and, for each connection-token in this field, 1997 remove any header field(s) from the message with the same name as the 1998 connection-token. Connection options are signaled by the presence of 1999 a connection-token in the Connection header field, not by any 2000 corresponding additional header field(s), since the additional header 2001 field may not be sent if there are no parameters associated with that 2002 connection option. 2004 Message headers listed in the Connection header MUST NOT include end- 2005 to-end headers, such as Cache-Control. 2007 HTTP/1.1 defines the "close" connection option for the sender to 2008 signal that the connection will be closed after completion of the 2009 response. For example, 2010 Connection: close 2012 in either the request or the response header fields indicates that 2013 the connection SHOULD NOT be considered `persistent' (Section 7.1) 2014 after the current request/response is complete. 2016 An HTTP/1.1 client that does not support persistent connections MUST 2017 include the "close" connection option in every request message. 2019 An HTTP/1.1 server that does not support persistent connections MUST 2020 include the "close" connection option in every response message that 2021 does not have a 1xx (informational) status code. 2023 A system receiving an HTTP/1.0 (or lower-version) message that 2024 includes a Connection header MUST, for each connection-token in this 2025 field, remove and ignore any header field(s) from the message with 2026 the same name as the connection-token. This protects against 2027 mistaken forwarding of such header fields by pre-HTTP/1.1 proxies. 2028 See Appendix B.2. 2030 9.2. Content-Length 2032 The "Content-Length" entity-header field indicates the size of the 2033 entity-body, in number of OCTETs. In the case of responses to the 2034 HEAD method, it indicates the size of the entity-body that would have 2035 been sent had the request been a GET. 2037 Content-Length = "Content-Length" ":" OWS 1*Content-Length-v 2038 Content-Length-v = 1*DIGIT 2040 An example is 2042 Content-Length: 3495 2044 Applications SHOULD use this field to indicate the transfer-length of 2045 the message-body, unless this is prohibited by the rules in 2046 Section 3.4. 2048 Any Content-Length greater than or equal to zero is a valid value. 2049 Section 3.4 describes how to determine the length of a message-body 2050 if a Content-Length is not given. 2052 Note that the meaning of this field is significantly different from 2053 the corresponding definition in MIME, where it is an optional field 2054 used within the "message/external-body" content-type. In HTTP, it 2055 SHOULD be sent whenever the message's length can be determined prior 2056 to being transferred, unless this is prohibited by the rules in 2057 Section 3.4. 2059 9.3. Date 2061 The "Date" general-header field represents the date and time at which 2062 the message was originated, having the same semantics as orig-date in 2063 Section 3.6.1 of [RFC5322]. The field value is an HTTP-date, as 2064 described in Section 6.1; it MUST be sent in rfc1123-date format. 2066 Date = "Date" ":" OWS Date-v 2067 Date-v = HTTP-date 2069 An example is 2071 Date: Tue, 15 Nov 1994 08:12:31 GMT 2073 Origin servers MUST include a Date header field in all responses, 2074 except in these cases: 2076 1. If the response status code is 100 (Continue) or 101 (Switching 2077 Protocols), the response MAY include a Date header field, at the 2078 server's option. 2080 2. If the response status code conveys a server error, e.g. 500 2081 (Internal Server Error) or 503 (Service Unavailable), and it is 2082 inconvenient or impossible to generate a valid Date. 2084 3. If the server does not have a clock that can provide a reasonable 2085 approximation of the current time, its responses MUST NOT include 2086 a Date header field. In this case, the rules in Section 9.3.1 2087 MUST be followed. 2089 A received message that does not have a Date header field MUST be 2090 assigned one by the recipient if the message will be cached by that 2091 recipient or gatewayed via a protocol which requires a Date. An HTTP 2092 implementation without a clock MUST NOT cache responses without 2093 revalidating them on every use. An HTTP cache, especially a shared 2094 cache, SHOULD use a mechanism, such as NTP [RFC1305], to synchronize 2095 its clock with a reliable external standard. 2097 Clients SHOULD only send a Date header field in messages that include 2098 an entity-body, as in the case of the PUT and POST requests, and even 2099 then it is optional. A client without a clock MUST NOT send a Date 2100 header field in a request. 2102 The HTTP-date sent in a Date header SHOULD NOT represent a date and 2103 time subsequent to the generation of the message. It SHOULD 2104 represent the best available approximation of the date and time of 2105 message generation, unless the implementation has no means of 2106 generating a reasonably accurate date and time. In theory, the date 2107 ought to represent the moment just before the entity is generated. 2108 In practice, the date can be generated at any time during the message 2109 origination without affecting its semantic value. 2111 9.3.1. Clockless Origin Server Operation 2113 Some origin server implementations might not have a clock available. 2114 An origin server without a clock MUST NOT assign Expires or Last- 2115 Modified values to a response, unless these values were associated 2116 with the resource by a system or user with a reliable clock. It MAY 2117 assign an Expires value that is known, at or before server 2118 configuration time, to be in the past (this allows "pre-expiration" 2119 of responses without storing separate Expires values for each 2120 resource). 2122 9.4. Host 2124 The "Host" request-header field specifies the Internet host and port 2125 number of the resource being requested, allowing the origin server or 2126 gateway to differentiate between internally-ambiguous URLs, such as 2127 the root "/" URL of a server for multiple host names on a single IP 2128 address. 2130 The Host field value MUST represent the naming authority of the 2131 origin server or gateway given by the original URL obtained from the 2132 user or referring resource (generally an http URI, as described in 2133 Section 2.6.1). 2135 Host = "Host" ":" OWS Host-v 2136 Host-v = uri-host [ ":" port ] ; Section 2.6.1 2138 A "host" without any trailing port information implies the default 2139 port for the service requested (e.g., "80" for an HTTP URL). For 2140 example, a request on the origin server for 2141 would properly include: 2143 GET /pub/WWW/ HTTP/1.1 2144 Host: www.example.org 2146 A client MUST include a Host header field in all HTTP/1.1 request 2147 messages. If the requested URI does not include an Internet host 2148 name for the service being requested, then the Host header field MUST 2149 be given with an empty value. An HTTP/1.1 proxy MUST ensure that any 2150 request message it forwards does contain an appropriate Host header 2151 field that identifies the service being requested by the proxy. All 2152 Internet-based HTTP/1.1 servers MUST respond with a 400 (Bad Request) 2153 status code to any HTTP/1.1 request message which lacks a Host header 2154 field. 2156 See Sections 4.2 and B.1.1 for other requirements relating to Host. 2158 9.5. TE 2160 The "TE" request-header field indicates what extension transfer- 2161 codings it is willing to accept in the response, and whether or not 2162 it is willing to accept trailer fields in a chunked transfer-coding. 2164 Its value may consist of the keyword "trailers" and/or a comma- 2165 separated list of extension transfer-coding names with optional 2166 accept parameters (as described in Section 6.2). 2168 TE = "TE" ":" OWS TE-v 2169 TE-v = #t-codings 2170 t-codings = "trailers" / ( transfer-extension [ te-params ] ) 2171 te-params = OWS ";" OWS "q=" qvalue *( te-ext ) 2172 te-ext = OWS ";" OWS token [ "=" ( token / quoted-string ) ] 2174 The presence of the keyword "trailers" indicates that the client is 2175 willing to accept trailer fields in a chunked transfer-coding, as 2176 defined in Section 6.2.1. This keyword is reserved for use with 2177 transfer-coding values even though it does not itself represent a 2178 transfer-coding. 2180 Examples of its use are: 2182 TE: deflate 2183 TE: 2184 TE: trailers, deflate;q=0.5 2186 The TE header field only applies to the immediate connection. 2187 Therefore, the keyword MUST be supplied within a Connection header 2188 field (Section 9.1) whenever TE is present in an HTTP/1.1 message. 2190 A server tests whether a transfer-coding is acceptable, according to 2191 a TE field, using these rules: 2193 1. The "chunked" transfer-coding is always acceptable. If the 2194 keyword "trailers" is listed, the client indicates that it is 2195 willing to accept trailer fields in the chunked response on 2196 behalf of itself and any downstream clients. The implication is 2197 that, if given, the client is stating that either all downstream 2198 clients are willing to accept trailer fields in the forwarded 2199 response, or that it will attempt to buffer the response on 2200 behalf of downstream recipients. 2202 Note: HTTP/1.1 does not define any means to limit the size of a 2203 chunked response such that a client can be assured of buffering 2204 the entire response. 2206 2. If the transfer-coding being tested is one of the transfer- 2207 codings listed in the TE field, then it is acceptable unless it 2208 is accompanied by a qvalue of 0. (As defined in Section 6.4, a 2209 qvalue of 0 means "not acceptable.") 2211 3. If multiple transfer-codings are acceptable, then the acceptable 2212 transfer-coding with the highest non-zero qvalue is preferred. 2213 The "chunked" transfer-coding always has a qvalue of 1. 2215 If the TE field-value is empty or if no TE field is present, the only 2216 transfer-coding is "chunked". A message with no transfer-coding is 2217 always acceptable. 2219 9.6. Trailer 2221 The "Trailer" general-header field indicates that the given set of 2222 header fields is present in the trailer of a message encoded with 2223 chunked transfer-coding. 2225 Trailer = "Trailer" ":" OWS Trailer-v 2226 Trailer-v = 1#field-name 2228 An HTTP/1.1 message SHOULD include a Trailer header field in a 2229 message using chunked transfer-coding with a non-empty trailer. 2230 Doing so allows the recipient to know which header fields to expect 2231 in the trailer. 2233 If no Trailer header field is present, the trailer SHOULD NOT include 2234 any header fields. See Section 6.2.1 for restrictions on the use of 2235 trailer fields in a "chunked" transfer-coding. 2237 Message header fields listed in the Trailer header field MUST NOT 2238 include the following header fields: 2240 o Transfer-Encoding 2242 o Content-Length 2244 o Trailer 2246 9.7. Transfer-Encoding 2248 The "Transfer-Encoding" general-header field indicates what transfer- 2249 codings (if any) have been applied to the message body. It differs 2250 from Content-Encoding (Section 2.2 of [Part3]) in that transfer- 2251 codings are a property of the message (and therefore are removed by 2252 intermediaries), whereas content-codings are not. 2254 Transfer-Encoding = "Transfer-Encoding" ":" OWS 2255 Transfer-Encoding-v 2256 Transfer-Encoding-v = 1#transfer-coding 2258 Transfer-codings are defined in Section 6.2. An example is: 2260 Transfer-Encoding: chunked 2262 If multiple encodings have been applied to an entity, the transfer- 2263 codings MUST be listed in the order in which they were applied. 2264 Additional information about the encoding parameters MAY be provided 2265 by other entity-header fields not defined by this specification. 2267 Many older HTTP/1.0 applications do not understand the Transfer- 2268 Encoding header. 2270 9.8. Upgrade 2272 The "Upgrade" general-header field allows the client to specify what 2273 additional communication protocols it would like to use, if the 2274 server chooses to switch protocols. Additionally, the server MUST 2275 use the Upgrade header field within a 101 (Switching Protocols) 2276 response to indicate which protocol(s) are being switched to. 2278 Upgrade = "Upgrade" ":" OWS Upgrade-v 2279 Upgrade-v = 1#product 2281 For example, 2283 Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11 2285 The Upgrade header field is intended to provide a simple mechanism 2286 for transition from HTTP/1.1 to some other, incompatible protocol. 2287 It does so by allowing the client to advertise its desire to use 2288 another protocol, such as a later version of HTTP with a higher major 2289 version number, even though the current request has been made using 2290 HTTP/1.1. This eases the difficult transition between incompatible 2291 protocols by allowing the client to initiate a request in the more 2292 commonly supported protocol while indicating to the server that it 2293 would like to use a "better" protocol if available (where "better" is 2294 determined by the server, possibly according to the nature of the 2295 method and/or resource being requested). 2297 The Upgrade header field only applies to switching application-layer 2298 protocols upon the existing transport-layer connection. Upgrade 2299 cannot be used to insist on a protocol change; its acceptance and use 2300 by the server is optional. The capabilities and nature of the 2301 application-layer communication after the protocol change is entirely 2302 dependent upon the new protocol chosen, although the first action 2303 after changing the protocol MUST be a response to the initial HTTP 2304 request containing the Upgrade header field. 2306 The Upgrade header field only applies to the immediate connection. 2307 Therefore, the upgrade keyword MUST be supplied within a Connection 2308 header field (Section 9.1) whenever Upgrade is present in an HTTP/1.1 2309 message. 2311 The Upgrade header field cannot be used to indicate a switch to a 2312 protocol on a different connection. For that purpose, it is more 2313 appropriate to use a 301, 302, 303, or 305 redirection response. 2315 This specification only defines the protocol name "HTTP" for use by 2316 the family of Hypertext Transfer Protocols, as defined by the HTTP 2317 version rules of Section 2.5 and future updates to this 2318 specification. Additional tokens can be registered with IANA using 2319 the registration procedure defined below. 2321 9.8.1. Upgrade Token Registry 2323 The HTTP Upgrade Token Registry defines the name space for product 2324 tokens used to identify protocols in the Upgrade header field. Each 2325 registered token should be associated with one or a set of 2326 specifications, and with contact information. 2328 Registrations should be allowed on a First Come First Served basis as 2329 described in Section 4.1 of [RFC5226]. These specifications need not 2330 be IETF documents or be subject to IESG review, but should obey the 2331 following rules: 2333 1. A token, once registered, stays registered forever. 2335 2. The registration MUST name a responsible party for the 2336 registration. 2338 3. The registration MUST name a point of contact. 2340 4. The registration MAY name the documentation required for the 2341 token. 2343 5. The responsible party MAY change the registration at any time. 2344 The IANA will keep a record of all such changes, and make them 2345 available upon request. 2347 6. The responsible party for the first registration of a "product" 2348 token MUST approve later registrations of a "version" token 2349 together with that "product" token before they can be registered. 2351 7. If absolutely required, the IESG MAY reassign the responsibility 2352 for a token. This will normally only be used in the case when a 2353 responsible party cannot be contacted. 2355 It is not required that specifications for upgrade tokens be made 2356 publicly available, but the contact information for the registration 2357 should be. 2359 9.9. Via 2361 The "Via" general-header field MUST be used by gateways and proxies 2362 to indicate the intermediate protocols and recipients between the 2363 user agent and the server on requests, and between the origin server 2364 and the client on responses. It is analogous to the "Received" field 2365 defined in Section 3.6.7 of [RFC5322] and is intended to be used for 2366 tracking message forwards, avoiding request loops, and identifying 2367 the protocol capabilities of all senders along the request/response 2368 chain. 2370 Via = "Via" ":" OWS Via-v 2371 Via-v = 1#( received-protocol RWS received-by 2372 [ RWS comment ] ) 2373 received-protocol = [ protocol-name "/" ] protocol-version 2374 protocol-name = token 2375 protocol-version = token 2376 received-by = ( uri-host [ ":" port ] ) / pseudonym 2377 pseudonym = token 2379 The received-protocol indicates the protocol version of the message 2380 received by the server or client along each segment of the request/ 2381 response chain. The received-protocol version is appended to the Via 2382 field value when the message is forwarded so that information about 2383 the protocol capabilities of upstream applications remains visible to 2384 all recipients. 2386 The protocol-name is optional if and only if it would be "HTTP". The 2387 received-by field is normally the host and optional port number of a 2388 recipient server or client that subsequently forwarded the message. 2389 However, if the real host is considered to be sensitive information, 2390 it MAY be replaced by a pseudonym. If the port is not given, it MAY 2391 be assumed to be the default port of the received-protocol. 2393 Multiple Via field values represents each proxy or gateway that has 2394 forwarded the message. Each recipient MUST append its information 2395 such that the end result is ordered according to the sequence of 2396 forwarding applications. 2398 Comments MAY be used in the Via header field to identify the software 2399 of the recipient proxy or gateway, analogous to the User-Agent and 2400 Server header fields. However, all comments in the Via field are 2401 optional and MAY be removed by any recipient prior to forwarding the 2402 message. 2404 For example, a request message could be sent from an HTTP/1.0 user 2405 agent to an internal proxy code-named "fred", which uses HTTP/1.1 to 2406 forward the request to a public proxy at p.example.net, which 2407 completes the request by forwarding it to the origin server at 2408 www.example.com. The request received by www.example.com would then 2409 have the following Via header field: 2411 Via: 1.0 fred, 1.1 p.example.net (Apache/1.1) 2413 Proxies and gateways used as a portal through a network firewall 2414 SHOULD NOT, by default, forward the names and ports of hosts within 2415 the firewall region. This information SHOULD only be propagated if 2416 explicitly enabled. If not enabled, the received-by host of any host 2417 behind the firewall SHOULD be replaced by an appropriate pseudonym 2418 for that host. 2420 For organizations that have strong privacy requirements for hiding 2421 internal structures, a proxy MAY combine an ordered subsequence of 2422 Via header field entries with identical received-protocol values into 2423 a single such entry. For example, 2425 Via: 1.0 ricky, 1.1 ethel, 1.1 fred, 1.0 lucy 2427 could be collapsed to 2429 Via: 1.0 ricky, 1.1 mertz, 1.0 lucy 2431 Applications SHOULD NOT combine multiple entries unless they are all 2432 under the same organizational control and the hosts have already been 2433 replaced by pseudonyms. Applications MUST NOT combine entries which 2434 have different received-protocol values. 2436 10. IANA Considerations 2438 10.1. Message Header Registration 2440 The Message Header Registry located at should be 2442 updated with the permanent registrations below (see [RFC3864]): 2444 +-------------------+----------+----------+-------------+ 2445 | Header Field Name | Protocol | Status | Reference | 2446 +-------------------+----------+----------+-------------+ 2447 | Connection | http | standard | Section 9.1 | 2448 | Content-Length | http | standard | Section 9.2 | 2449 | Date | http | standard | Section 9.3 | 2450 | Host | http | standard | Section 9.4 | 2451 | TE | http | standard | Section 9.5 | 2452 | Trailer | http | standard | Section 9.6 | 2453 | Transfer-Encoding | http | standard | Section 9.7 | 2454 | Upgrade | http | standard | Section 9.8 | 2455 | Via | http | standard | Section 9.9 | 2456 +-------------------+----------+----------+-------------+ 2458 The change controller is: "IETF (iesg@ietf.org) - Internet 2459 Engineering Task Force". 2461 10.2. URI Scheme Registration 2463 The entries for the "http" and "https" URI Schemes in the registry 2464 located at should 2465 be updated to point to Sections 2.6.1 and 2.6.2 of this document (see 2466 [RFC4395]). 2468 10.3. Internet Media Type Registrations 2470 This document serves as the specification for the Internet media 2471 types "message/http" and "application/http". The following is to be 2472 registered with IANA (see [RFC4288]). 2474 10.3.1. Internet Media Type message/http 2476 The message/http type can be used to enclose a single HTTP request or 2477 response message, provided that it obeys the MIME restrictions for 2478 all "message" types regarding line length and encodings. 2480 Type name: message 2482 Subtype name: http 2484 Required parameters: none 2486 Optional parameters: version, msgtype 2487 version: The HTTP-Version number of the enclosed message (e.g., 2488 "1.1"). If not present, the version can be determined from the 2489 first line of the body. 2491 msgtype: The message type -- "request" or "response". If not 2492 present, the type can be determined from the first line of the 2493 body. 2495 Encoding considerations: only "7bit", "8bit", or "binary" are 2496 permitted 2498 Security considerations: none 2500 Interoperability considerations: none 2502 Published specification: This specification (see Section 10.3.1). 2504 Applications that use this media type: 2506 Additional information: 2508 Magic number(s): none 2510 File extension(s): none 2512 Macintosh file type code(s): none 2514 Person and email address to contact for further information: See 2515 Authors Section. 2517 Intended usage: COMMON 2519 Restrictions on usage: none 2521 Author/Change controller: IESG 2523 10.3.2. Internet Media Type application/http 2525 The application/http type can be used to enclose a pipeline of one or 2526 more HTTP request or response messages (not intermixed). 2528 Type name: application 2530 Subtype name: http 2531 Required parameters: none 2533 Optional parameters: version, msgtype 2535 version: The HTTP-Version number of the enclosed messages (e.g., 2536 "1.1"). If not present, the version can be determined from the 2537 first line of the body. 2539 msgtype: The message type -- "request" or "response". If not 2540 present, the type can be determined from the first line of the 2541 body. 2543 Encoding considerations: HTTP messages enclosed by this type are in 2544 "binary" format; use of an appropriate Content-Transfer-Encoding 2545 is required when transmitted via E-mail. 2547 Security considerations: none 2549 Interoperability considerations: none 2551 Published specification: This specification (see Section 10.3.2). 2553 Applications that use this media type: 2555 Additional information: 2557 Magic number(s): none 2559 File extension(s): none 2561 Macintosh file type code(s): none 2563 Person and email address to contact for further information: See 2564 Authors Section. 2566 Intended usage: COMMON 2568 Restrictions on usage: none 2570 Author/Change controller: IESG 2572 10.4. Transfer Coding Registry 2574 The registration procedure for HTTP Transfer Codings is now defined 2575 by Section 6.2.3 of this document. 2577 The HTTP Transfer Codings Registry located at 2578 should be updated 2579 with the registrations below: 2581 +----------+--------------------------------------+-----------------+ 2582 | Name | Description | Reference | 2583 +----------+--------------------------------------+-----------------+ 2584 | chunked | Transfer in a series of chunks | Section 6.2.1 | 2585 | compress | UNIX "compress" program method | Section 6.2.2.1 | 2586 | deflate | "zlib" format [RFC1950] with | Section 6.2.2.2 | 2587 | | "deflate" compression | | 2588 | gzip | Same as GNU zip [RFC1952] | Section 6.2.2.3 | 2589 +----------+--------------------------------------+-----------------+ 2591 10.5. Upgrade Token Registration 2593 The registration procedure for HTTP Upgrade Tokens -- previously 2594 defined in Section 7.2 of [RFC2817] -- is now defined by 2595 Section 9.8.1 of this document. 2597 The HTTP Status Code Registry located at 2598 should be 2599 updated with the registration below: 2601 +-------+---------------------------+-------------------------------+ 2602 | Value | Description | Reference | 2603 +-------+---------------------------+-------------------------------+ 2604 | HTTP | Hypertext Transfer | Section 2.5 of this | 2605 | | Protocol | specification | 2606 +-------+---------------------------+-------------------------------+ 2608 11. Security Considerations 2610 This section is meant to inform application developers, information 2611 providers, and users of the security limitations in HTTP/1.1 as 2612 described by this document. The discussion does not include 2613 definitive solutions to the problems revealed, though it does make 2614 some suggestions for reducing security risks. 2616 11.1. Personal Information 2618 HTTP clients are often privy to large amounts of personal information 2619 (e.g. the user's name, location, mail address, passwords, encryption 2620 keys, etc.), and SHOULD be very careful to prevent unintentional 2621 leakage of this information. We very strongly recommend that a 2622 convenient interface be provided for the user to control 2623 dissemination of such information, and that designers and 2624 implementors be particularly careful in this area. History shows 2625 that errors in this area often create serious security and/or privacy 2626 problems and generate highly adverse publicity for the implementor's 2627 company. 2629 11.2. Abuse of Server Log Information 2631 A server is in the position to save personal data about a user's 2632 requests which might identify their reading patterns or subjects of 2633 interest. This information is clearly confidential in nature and its 2634 handling can be constrained by law in certain countries. People 2635 using HTTP to provide data are responsible for ensuring that such 2636 material is not distributed without the permission of any individuals 2637 that are identifiable by the published results. 2639 11.3. Attacks Based On File and Path Names 2641 Implementations of HTTP origin servers SHOULD be careful to restrict 2642 the documents returned by HTTP requests to be only those that were 2643 intended by the server administrators. If an HTTP server translates 2644 HTTP URIs directly into file system calls, the server MUST take 2645 special care not to serve files that were not intended to be 2646 delivered to HTTP clients. For example, UNIX, Microsoft Windows, and 2647 other operating systems use ".." as a path component to indicate a 2648 directory level above the current one. On such a system, an HTTP 2649 server MUST disallow any such construct in the request-target if it 2650 would otherwise allow access to a resource outside those intended to 2651 be accessible via the HTTP server. Similarly, files intended for 2652 reference only internally to the server (such as access control 2653 files, configuration files, and script code) MUST be protected from 2654 inappropriate retrieval, since they might contain sensitive 2655 information. Experience has shown that minor bugs in such HTTP 2656 server implementations have turned into security risks. 2658 11.4. DNS Spoofing 2660 Clients using HTTP rely heavily on the Domain Name Service, and are 2661 thus generally prone to security attacks based on the deliberate mis- 2662 association of IP addresses and DNS names. Clients need to be 2663 cautious in assuming the continuing validity of an IP number/DNS name 2664 association. 2666 In particular, HTTP clients SHOULD rely on their name resolver for 2667 confirmation of an IP number/DNS name association, rather than 2668 caching the result of previous host name lookups. Many platforms 2669 already can cache host name lookups locally when appropriate, and 2670 they SHOULD be configured to do so. It is proper for these lookups 2671 to be cached, however, only when the TTL (Time To Live) information 2672 reported by the name server makes it likely that the cached 2673 information will remain useful. 2675 If HTTP clients cache the results of host name lookups in order to 2676 achieve a performance improvement, they MUST observe the TTL 2677 information reported by DNS. 2679 If HTTP clients do not observe this rule, they could be spoofed when 2680 a previously-accessed server's IP address changes. As network 2681 renumbering is expected to become increasingly common [RFC1900], the 2682 possibility of this form of attack will grow. Observing this 2683 requirement thus reduces this potential security vulnerability. 2685 This requirement also improves the load-balancing behavior of clients 2686 for replicated servers using the same DNS name and reduces the 2687 likelihood of a user's experiencing failure in accessing sites which 2688 use that strategy. 2690 11.5. Proxies and Caching 2692 By their very nature, HTTP proxies are men-in-the-middle, and 2693 represent an opportunity for man-in-the-middle attacks. Compromise 2694 of the systems on which the proxies run can result in serious 2695 security and privacy problems. Proxies have access to security- 2696 related information, personal information about individual users and 2697 organizations, and proprietary information belonging to users and 2698 content providers. A compromised proxy, or a proxy implemented or 2699 configured without regard to security and privacy considerations, 2700 might be used in the commission of a wide range of potential attacks. 2702 Proxy operators should protect the systems on which proxies run as 2703 they would protect any system that contains or transports sensitive 2704 information. In particular, log information gathered at proxies 2705 often contains highly sensitive personal information, and/or 2706 information about organizations. Log information should be carefully 2707 guarded, and appropriate guidelines for use developed and followed. 2708 (Section 11.2). 2710 Proxy implementors should consider the privacy and security 2711 implications of their design and coding decisions, and of the 2712 configuration options they provide to proxy operators (especially the 2713 default configuration). 2715 Users of a proxy need to be aware that they are no trustworthier than 2716 the people who run the proxy; HTTP itself cannot solve this problem. 2718 The judicious use of cryptography, when appropriate, may suffice to 2719 protect against a broad range of security and privacy attacks. Such 2720 cryptography is beyond the scope of the HTTP/1.1 specification. 2722 11.6. Denial of Service Attacks on Proxies 2724 They exist. They are hard to defend against. Research continues. 2725 Beware. 2727 12. Acknowledgments 2729 HTTP has evolved considerably over the years. It has benefited from 2730 a large and active developer community--the many people who have 2731 participated on the www-talk mailing list--and it is that community 2732 which has been most responsible for the success of HTTP and of the 2733 World-Wide Web in general. Marc Andreessen, Robert Cailliau, Daniel 2734 W. Connolly, Bob Denny, John Franks, Jean-Francois Groff, Phillip M. 2735 Hallam-Baker, Hakon W. Lie, Ari Luotonen, Rob McCool, Lou Montulli, 2736 Dave Raggett, Tony Sanders, and Marc VanHeyningen deserve special 2737 recognition for their efforts in defining early aspects of the 2738 protocol. 2740 This document has benefited greatly from the comments of all those 2741 participating in the HTTP-WG. In addition to those already 2742 mentioned, the following individuals have contributed to this 2743 specification: 2745 Gary Adams, Harald Tveit Alvestrand, Keith Ball, Brian Behlendorf, 2746 Paul Burchard, Maurizio Codogno, Mike Cowlishaw, Roman Czyborra, 2747 Michael A. Dolan, Daniel DuBois, David J. Fiander, Alan Freier, Marc 2748 Hedlund, Greg Herlihy, Koen Holtman, Alex Hopmann, Bob Jernigan, Shel 2749 Kaphan, Rohit Khare, John Klensin, Martijn Koster, Alexei Kosut, 2750 David M. Kristol, Daniel LaLiberte, Ben Laurie, Paul J. Leach, Albert 2751 Lunde, John C. Mallery, Jean-Philippe Martin-Flatin, Mitra, David 2752 Morris, Gavin Nicol, Ross Patterson, Bill Perry, Jeffrey Perry, Scott 2753 Powers, Owen Rees, Luigi Rizzo, David Robinson, Marc Salomon, Rich 2754 Salz, Allan M. Schiffman, Jim Seidman, Chuck Shotton, Eric W. Sink, 2755 Simon E. Spero, Richard N. Taylor, Robert S. Thau, Bill (BearHeart) 2756 Weinman, Francois Yergeau, Mary Ellen Zurko, Josh Cohen. 2758 Thanks to the "cave men" of Palo Alto. You know who you are. 2760 Jim Gettys (the editor of [RFC2616]) wishes particularly to thank Roy 2761 Fielding, the editor of [RFC2068], along with John Klensin, Jeff 2762 Mogul, Paul Leach, Dave Kristol, Koen Holtman, John Franks, Josh 2763 Cohen, Alex Hopmann, Scott Lawrence, and Larry Masinter for their 2764 help. And thanks go particularly to Jeff Mogul and Scott Lawrence 2765 for performing the "MUST/MAY/SHOULD" audit. 2767 The Apache Group, Anselm Baird-Smith, author of Jigsaw, and Henrik 2768 Frystyk implemented RFC 2068 early, and we wish to thank them for the 2769 discovery of many of the problems that this document attempts to 2770 rectify. 2772 This specification makes heavy use of the augmented BNF and generic 2773 constructs defined by David H. Crocker for [RFC5234]. Similarly, it 2774 reuses many of the definitions provided by Nathaniel Borenstein and 2775 Ned Freed for MIME [RFC2045]. We hope that their inclusion in this 2776 specification will help reduce past confusion over the relationship 2777 between HTTP and Internet mail message formats. 2779 13. References 2781 13.1. Normative References 2783 [ISO-8859-1] 2784 International Organization for Standardization, 2785 "Information technology -- 8-bit single-byte coded graphic 2786 character sets -- Part 1: Latin alphabet No. 1", ISO/ 2787 IEC 8859-1:1998, 1998. 2789 [Part2] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., 2790 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., 2791 and J. Reschke, Ed., "HTTP/1.1, part 2: Message 2792 Semantics", draft-ietf-httpbis-p2-semantics-08 (work in 2793 progress), October 2009. 2795 [Part3] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., 2796 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., 2797 and J. Reschke, Ed., "HTTP/1.1, part 3: Message Payload 2798 and Content Negotiation", draft-ietf-httpbis-p3-payload-08 2799 (work in progress), October 2009. 2801 [Part5] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., 2802 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., 2803 and J. Reschke, Ed., "HTTP/1.1, part 5: Range Requests and 2804 Partial Responses", draft-ietf-httpbis-p5-range-08 (work 2805 in progress), October 2009. 2807 [Part6] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., 2808 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., 2809 Nottingham, M., Ed., and J. Reschke, Ed., "HTTP/1.1, part 2810 6: Caching", draft-ietf-httpbis-p6-cache-08 (work in 2811 progress), October 2009. 2813 [RFC1950] Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data Format 2814 Specification version 3.3", RFC 1950, May 1996. 2816 RFC 1950 is an Informational RFC, thus it may be less 2817 stable than this specification. On the other hand, this 2818 downward reference was present since the publication of 2819 RFC 2068 in 1997 ([RFC2068]), therefore it is unlikely to 2820 cause problems in practice. See also [BCP97]. 2822 [RFC1951] Deutsch, P., "DEFLATE Compressed Data Format Specification 2823 version 1.3", RFC 1951, May 1996. 2825 RFC 1951 is an Informational RFC, thus it may be less 2826 stable than this specification. On the other hand, this 2827 downward reference was present since the publication of 2828 RFC 2068 in 1997 ([RFC2068]), therefore it is unlikely to 2829 cause problems in practice. See also [BCP97]. 2831 [RFC1952] Deutsch, P., Gailly, J-L., Adler, M., Deutsch, L., and G. 2832 Randers-Pehrson, "GZIP file format specification version 2833 4.3", RFC 1952, May 1996. 2835 RFC 1952 is an Informational RFC, thus it may be less 2836 stable than this specification. On the other hand, this 2837 downward reference was present since the publication of 2838 RFC 2068 in 1997 ([RFC2068]), therefore it is unlikely to 2839 cause problems in practice. See also [BCP97]. 2841 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2842 Requirement Levels", BCP 14, RFC 2119, March 1997. 2844 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 2845 Resource Identifier (URI): Generic Syntax", RFC 3986, 2846 STD 66, January 2005. 2848 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 2849 Specifications: ABNF", STD 68, RFC 5234, January 2008. 2851 [USASCII] American National Standards Institute, "Coded Character 2852 Set -- 7-bit American Standard Code for Information 2853 Interchange", ANSI X3.4, 1986. 2855 13.2. Informative References 2857 [BCP97] Klensin, J. and S. Hartman, "Handling Normative References 2858 to Standards-Track Documents", BCP 97, RFC 4897, 2859 June 2007. 2861 [Kri2001] Kristol, D., "HTTP Cookies: Standards, Privacy, and 2862 Politics", ACM Transactions on Internet Technology Vol. 1, 2863 #2, November 2001, . 2865 [Nie1997] Nielsen, H., Gettys, J., Prud'hommeaux, E., Lie, H., and 2866 C. Lilley, "Network Performance Effects of HTTP/1.1, CSS1, 2867 and PNG", ACM Proceedings of the ACM SIGCOMM '97 2868 conference on Applications, technologies, architectures, 2869 and protocols for computer communication SIGCOMM '97, 2870 September 1997, 2871 . 2873 [Pad1995] Padmanabhan, V. and J. Mogul, "Improving HTTP Latency", 2874 Computer Networks and ISDN Systems v. 28, pp. 25-35, 2875 December 1995, 2876 . 2878 [RFC1123] Braden, R., "Requirements for Internet Hosts - Application 2879 and Support", STD 3, RFC 1123, October 1989. 2881 [RFC1305] Mills, D., "Network Time Protocol (Version 3) 2882 Specification, Implementation", RFC 1305, March 1992. 2884 [RFC1900] Carpenter, B. and Y. Rekhter, "Renumbering Needs Work", 2885 RFC 1900, February 1996. 2887 [RFC1945] Berners-Lee, T., Fielding, R., and H. Nielsen, "Hypertext 2888 Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996. 2890 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 2891 Extensions (MIME) Part One: Format of Internet Message 2892 Bodies", RFC 2045, November 1996. 2894 [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) 2895 Part Three: Message Header Extensions for Non-ASCII Text", 2896 RFC 2047, November 1996. 2898 [RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and T. 2899 Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", 2900 RFC 2068, January 1997. 2902 [RFC2109] Kristol, D. and L. Montulli, "HTTP State Management 2903 Mechanism", RFC 2109, February 1997. 2905 [RFC2145] Mogul, J., Fielding, R., Gettys, J., and H. Nielsen, "Use 2906 and Interpretation of HTTP Version Numbers", RFC 2145, 2907 May 1997. 2909 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 2910 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 2911 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 2913 [RFC2817] Khare, R. and S. Lawrence, "Upgrading to TLS Within 2914 HTTP/1.1", RFC 2817, May 2000. 2916 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 2918 [RFC2965] Kristol, D. and L. Montulli, "HTTP State Management 2919 Mechanism", RFC 2965, October 2000. 2921 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration 2922 Procedures for Message Header Fields", BCP 90, RFC 3864, 2923 September 2004. 2925 [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and 2926 Registration Procedures", BCP 13, RFC 4288, December 2005. 2928 [RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and 2929 Registration Procedures for New URI Schemes", BCP 115, 2930 RFC 4395, February 2006. 2932 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 2933 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 2934 May 2008. 2936 [RFC5322] Resnick, P., "Internet Message Format", RFC 5322, 2937 October 2008. 2939 [Spe] Spero, S., "Analysis of HTTP Performance Problems", 2940 . 2942 [Tou1998] Touch, J., Heidemann, J., and K. Obraczka, "Analysis of 2943 HTTP Performance", ISI Research Report ISI/RR-98-463, 2944 Aug 1998, . 2946 (original report dated Aug. 1996) 2948 Appendix A. Tolerant Applications 2950 Although this document specifies the requirements for the generation 2951 of HTTP/1.1 messages, not all applications will be correct in their 2952 implementation. We therefore recommend that operational applications 2953 be tolerant of deviations whenever those deviations can be 2954 interpreted unambiguously. 2956 Clients SHOULD be tolerant in parsing the Status-Line and servers 2957 tolerant when parsing the Request-Line. In particular, they SHOULD 2958 accept any amount of WSP characters between fields, even though only 2959 a single SP is required. 2961 The line terminator for header fields is the sequence CRLF. However, 2962 we recommend that applications, when parsing such headers, recognize 2963 a single LF as a line terminator and ignore the leading CR. 2965 The character set of an entity-body SHOULD be labeled as the lowest 2966 common denominator of the character codes used within that body, with 2967 the exception that not labeling the entity is preferred over labeling 2968 the entity with the labels US-ASCII or ISO-8859-1. See [Part3]. 2970 Additional rules for requirements on parsing and encoding of dates 2971 and other potential problems with date encodings include: 2973 o HTTP/1.1 clients and caches SHOULD assume that an RFC-850 date 2974 which appears to be more than 50 years in the future is in fact in 2975 the past (this helps solve the "year 2000" problem). 2977 o An HTTP/1.1 implementation MAY internally represent a parsed 2978 Expires date as earlier than the proper value, but MUST NOT 2979 internally represent a parsed Expires date as later than the 2980 proper value. 2982 o All expiration-related calculations MUST be done in GMT. The 2983 local time zone MUST NOT influence the calculation or comparison 2984 of an age or expiration time. 2986 o If an HTTP header incorrectly carries a date value with a time 2987 zone other than GMT, it MUST be converted into GMT using the most 2988 conservative possible conversion. 2990 Appendix B. Compatibility with Previous Versions 2992 HTTP has been in use by the World-Wide Web global information 2993 initiative since 1990. The first version of HTTP, later referred to 2994 as HTTP/0.9, was a simple protocol for hypertext data transfer across 2995 the Internet with only a single method and no metadata. HTTP/1.0, as 2996 defined by [RFC1945], added a range of request methods and MIME-like 2997 messaging that could include metadata about the data transferred and 2998 modifiers on the request/response semantics. However, HTTP/1.0 did 2999 not sufficiently take into consideration the effects of hierarchical 3000 proxies, caching, the need for persistent connections, or name-based 3001 virtual hosts. The proliferation of incompletely-implemented 3002 applications calling themselves "HTTP/1.0" further necessitated a 3003 protocol version change in order for two communicating applications 3004 to determine each other's true capabilities. 3006 HTTP/1.1 remains compatible with HTTP/1.0 by including more stringent 3007 requirements that enable reliable implementations, adding only those 3008 new features that will either be safely ignored by an HTTP/1.0 3009 recipient or only sent when communicating with a party advertising 3010 compliance with HTTP/1.1. 3012 It is beyond the scope of a protocol specification to mandate 3013 compliance with previous versions. HTTP/1.1 was deliberately 3014 designed, however, to make supporting previous versions easy. It is 3015 worth noting that, at the time of composing this specification, we 3016 would expect general-purpose HTTP/1.1 servers to: 3018 o understand any valid request in the format of HTTP/1.0 and 1.1; 3020 o respond appropriately with a message in the same major version 3021 used by the client. 3023 And we would expect HTTP/1.1 clients to: 3025 o understand any valid response in the format of HTTP/1.0 or 1.1. 3027 For most implementations of HTTP/1.0, each connection is established 3028 by the client prior to the request and closed by the server after 3029 sending the response. Some implementations implement the Keep-Alive 3030 version of persistent connections described in Section 19.7.1 of 3031 [RFC2068]. 3033 B.1. Changes from HTTP/1.0 3035 This section summarizes major differences between versions HTTP/1.0 3036 and HTTP/1.1. 3038 B.1.1. Changes to Simplify Multi-homed Web Servers and Conserve IP 3039 Addresses 3041 The requirements that clients and servers support the Host request- 3042 header, report an error if the Host request-header (Section 9.4) is 3043 missing from an HTTP/1.1 request, and accept absolute URIs 3044 (Section 4.1.2) are among the most important changes defined by this 3045 specification. 3047 Older HTTP/1.0 clients assumed a one-to-one relationship of IP 3048 addresses and servers; there was no other established mechanism for 3049 distinguishing the intended server of a request than the IP address 3050 to which that request was directed. The changes outlined above will 3051 allow the Internet, once older HTTP clients are no longer common, to 3052 support multiple Web sites from a single IP address, greatly 3053 simplifying large operational Web servers, where allocation of many 3054 IP addresses to a single host has created serious problems. The 3055 Internet will also be able to recover the IP addresses that have been 3056 allocated for the sole purpose of allowing special-purpose domain 3057 names to be used in root-level HTTP URLs. Given the rate of growth 3058 of the Web, and the number of servers already deployed, it is 3059 extremely important that all implementations of HTTP (including 3060 updates to existing HTTP/1.0 applications) correctly implement these 3061 requirements: 3063 o Both clients and servers MUST support the Host request-header. 3065 o A client that sends an HTTP/1.1 request MUST send a Host header. 3067 o Servers MUST report a 400 (Bad Request) error if an HTTP/1.1 3068 request does not include a Host request-header. 3070 o Servers MUST accept absolute URIs. 3072 B.2. Compatibility with HTTP/1.0 Persistent Connections 3074 Some clients and servers might wish to be compatible with some 3075 previous implementations of persistent connections in HTTP/1.0 3076 clients and servers. Persistent connections in HTTP/1.0 are 3077 explicitly negotiated as they are not the default behavior. HTTP/1.0 3078 experimental implementations of persistent connections are faulty, 3079 and the new facilities in HTTP/1.1 are designed to rectify these 3080 problems. The problem was that some existing 1.0 clients may be 3081 sending Keep-Alive to a proxy server that doesn't understand 3082 Connection, which would then erroneously forward it to the next 3083 inbound server, which would establish the Keep-Alive connection and 3084 result in a hung HTTP/1.0 proxy waiting for the close on the 3085 response. The result is that HTTP/1.0 clients must be prevented from 3086 using Keep-Alive when talking to proxies. 3088 However, talking to proxies is the most important use of persistent 3089 connections, so that prohibition is clearly unacceptable. Therefore, 3090 we need some other mechanism for indicating a persistent connection 3091 is desired, which is safe to use even when talking to an old proxy 3092 that ignores Connection. Persistent connections are the default for 3093 HTTP/1.1 messages; we introduce a new keyword (Connection: close) for 3094 declaring non-persistence. See Section 9.1. 3096 The original HTTP/1.0 form of persistent connections (the Connection: 3097 Keep-Alive and Keep-Alive header) is documented in Section 19.7.1 of 3098 [RFC2068]. 3100 B.3. Changes from RFC 2068 3102 This specification has been carefully audited to correct and 3103 disambiguate key word usage; RFC 2068 had many problems in respect to 3104 the conventions laid out in [RFC2119]. 3106 Transfer-coding and message lengths all interact in ways that 3107 required fixing exactly when chunked encoding is used (to allow for 3108 transfer encoding that may not be self delimiting); it was important 3109 to straighten out exactly how message lengths are computed. 3110 (Sections 6.2, 3.4, 9.2, see also [Part3], [Part5] and [Part6]) 3112 The use and interpretation of HTTP version numbers has been clarified 3113 by [RFC2145]. Require proxies to upgrade requests to highest 3114 protocol version they support to deal with problems discovered in 3115 HTTP/1.0 implementations (Section 2.5) 3117 Quality Values of zero should indicate that "I don't want something" 3118 to allow clients to refuse a representation. (Section 6.4) 3120 Transfer-coding had significant problems, particularly with 3121 interactions with chunked encoding. The solution is that transfer- 3122 codings become as full fledged as content-codings. This involves 3123 adding an IANA registry for transfer-codings (separate from content 3124 codings), a new header field (TE) and enabling trailer headers in the 3125 future. Transfer encoding is a major performance benefit, so it was 3126 worth fixing [Nie1997]. TE also solves another, obscure, downward 3127 interoperability problem that could have occurred due to interactions 3128 between authentication trailers, chunked encoding and HTTP/1.0 3129 clients.(Section 6.2, 6.2.1, and 9.5) 3131 B.4. Changes from RFC 2616 3133 Empty list elements in list productions have been deprecated. 3134 (Section 1.2.1) 3136 Rules about implicit linear whitespace between certain grammar 3137 productions have been removed; now it's only allowed when 3138 specifically pointed out in the ABNF. The NUL character is no longer 3139 allowed in comment and quoted-string text. The quoted-pair rule no 3140 longer allows escaping control characters other than HTAB. Non-ASCII 3141 content in header fields and reason phrase has been obsoleted and 3142 made opaque (the TEXT rule was removed) (Section 1.2.2) 3144 Clarify that HTTP-Version is case sensitive. (Section 2.5) 3146 Remove reference to non-existant identity transfer-coding value 3147 tokens. (Sections 6.2 and 3.4) 3149 Require that invalid whitespace around field-names be rejected. 3150 (Section 3.2) 3151 Update use of abs_path production from RFC1808 to the path-absolute + 3152 query components of RFC3986. (Section 4.1.2) 3154 Clarification that the chunk length does not include the count of the 3155 octets in the chunk header and trailer. Furthermore disallowed line 3156 folding in chunk extensions. (Section 6.2.1) 3158 Remove hard limit of two connections per server. (Section 7.1.4) 3160 Clarify exactly when close connection options must be sent. 3161 (Section 9.1) 3163 Appendix C. Collected ABNF 3165 BWS = OWS 3167 Cache-Control = 3168 Chunked-Body = *chunk last-chunk trailer-part CRLF 3169 Connection = "Connection:" OWS Connection-v 3170 Connection-v = *( "," OWS ) connection-token *( OWS "," [ OWS 3171 connection-token ] ) 3172 Content-Length = "Content-Length:" OWS 1*Content-Length-v 3173 Content-Length-v = 1*DIGIT 3175 Date = "Date:" OWS Date-v 3176 Date-v = HTTP-date 3178 GMT = %x47.4D.54 ; GMT 3180 HTTP-Prot-Name = %x48.54.54.50 ; HTTP 3181 HTTP-Version = HTTP-Prot-Name "/" 1*DIGIT "." 1*DIGIT 3182 HTTP-date = rfc1123-date / obs-date 3183 HTTP-message = start-line *( header-field CRLF ) CRLF [ message-body 3184 ] 3185 Host = "Host:" OWS Host-v 3186 Host-v = uri-host [ ":" port ] 3188 Method = token 3190 OWS = *( [ obs-fold ] WSP ) 3192 Pragma = 3194 RWS = 1*( [ obs-fold ] WSP ) 3195 Reason-Phrase = *( WSP / VCHAR / obs-text ) 3196 Request = Request-Line *( ( general-header / request-header / 3197 entity-header ) CRLF ) CRLF [ message-body ] 3199 Request-Line = Method SP request-target SP HTTP-Version CRLF 3200 Response = Status-Line *( ( general-header / response-header / 3201 entity-header ) CRLF ) CRLF [ message-body ] 3203 Status-Code = 3DIGIT 3204 Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF 3206 TE = "TE:" OWS TE-v 3207 TE-v = [ ( "," / t-codings ) *( OWS "," [ OWS t-codings ] ) ] 3208 Trailer = "Trailer:" OWS Trailer-v 3209 Trailer-v = *( "," OWS ) field-name *( OWS "," [ OWS field-name ] ) 3210 Transfer-Encoding = "Transfer-Encoding:" OWS Transfer-Encoding-v 3211 Transfer-Encoding-v = *( "," OWS ) transfer-coding *( OWS "," [ OWS 3212 transfer-coding ] ) 3214 URI = 3215 URI-reference = 3216 Upgrade = "Upgrade:" OWS Upgrade-v 3217 Upgrade-v = *( "," OWS ) product *( OWS "," [ OWS product ] ) 3219 Via = "Via:" OWS Via-v 3220 Via-v = *( "," OWS ) received-protocol RWS received-by [ RWS comment 3221 ] *( OWS "," [ OWS received-protocol RWS received-by [ RWS comment ] 3222 ] ) 3224 Warning = 3226 absolute-URI = 3227 asctime-date = day-name SP date3 SP time-of-day SP year 3228 attribute = token 3229 authority = 3231 chunk = chunk-size *WSP [ chunk-ext ] CRLF chunk-data CRLF 3232 chunk-data = 1*OCTET 3233 chunk-ext = *( ";" *WSP chunk-ext-name [ "=" chunk-ext-val ] *WSP ) 3234 chunk-ext-name = token 3235 chunk-ext-val = token / quoted-str-nf 3236 chunk-size = 1*HEXDIG 3237 comment = "(" *( ctext / quoted-cpair / comment ) ")" 3238 connection-token = token 3239 ctext = OWS / %x21-27 ; '!'-''' 3240 / %x2A-5B ; '*'-'[' 3241 / %x5D-7E ; ']'-'~' 3242 / obs-text 3244 date1 = day SP month SP year 3245 date2 = day "-" month "-" 2DIGIT 3246 date3 = month SP ( 2DIGIT / ( SP DIGIT ) ) 3247 day = 2DIGIT 3248 day-name = %x4D.6F.6E ; Mon 3249 / %x54.75.65 ; Tue 3250 / %x57.65.64 ; Wed 3251 / %x54.68.75 ; Thu 3252 / %x46.72.69 ; Fri 3253 / %x53.61.74 ; Sat 3254 / %x53.75.6E ; Sun 3255 day-name-l = %x4D.6F.6E.64.61.79 ; Monday 3256 / %x54.75.65.73.64.61.79 ; Tuesday 3257 / %x57.65.64.6E.65.73.64.61.79 ; Wednesday 3258 / %x54.68.75.72.73.64.61.79 ; Thursday 3259 / %x46.72.69.64.61.79 ; Friday 3260 / %x53.61.74.75.72.64.61.79 ; Saturday 3261 / %x53.75.6E.64.61.79 ; Sunday 3263 entity-body = 3264 entity-header = 3266 field-content = *( WSP / VCHAR / obs-text ) 3267 field-name = token 3268 field-value = *( field-content / OWS ) 3270 general-header = Cache-Control / Connection / Date / Pragma / Trailer 3271 / Transfer-Encoding / Upgrade / Via / Warning 3273 header-field = field-name ":" OWS [ field-value ] OWS 3274 hour = 2DIGIT 3275 http-URI = "http://" authority path-abempty [ "?" query ] 3276 https-URI = "https://" authority path-abempty [ "?" query ] 3278 last-chunk = 1*"0" *WSP [ chunk-ext ] CRLF 3280 message-body = entity-body / 3281 3282 minute = 2DIGIT 3283 month = %x4A.61.6E ; Jan 3284 / %x46.65.62 ; Feb 3285 / %x4D.61.72 ; Mar 3286 / %x41.70.72 ; Apr 3287 / %x4D.61.79 ; May 3288 / %x4A.75.6E ; Jun 3289 / %x4A.75.6C ; Jul 3290 / %x41.75.67 ; Aug 3291 / %x53.65.70 ; Sep 3292 / %x4F.63.74 ; Oct 3293 / %x4E.6F.76 ; Nov 3294 / %x44.65.63 ; Dec 3296 obs-date = rfc850-date / asctime-date 3297 obs-fold = CRLF 3298 obs-text = %x80-FF 3300 partial-URI = relative-part [ "?" query ] 3301 path-abempty = 3302 path-absolute = 3303 port = 3304 product = token [ "/" product-version ] 3305 product-version = token 3306 protocol-name = token 3307 protocol-version = token 3308 pseudonym = token 3310 qdtext = OWS / "!" / %x23-5B ; '#'-'[' 3311 / %x5D-7E ; ']'-'~' 3312 / obs-text 3313 qdtext-nf = WSP / "!" / %x23-5B ; '#'-'[' 3314 / %x5D-7E ; ']'-'~' 3315 / obs-text 3316 query = 3317 quoted-cpair = "\" ( WSP / VCHAR / obs-text ) 3318 quoted-pair = "\" ( WSP / VCHAR / obs-text ) 3319 quoted-str-nf = DQUOTE *( qdtext-nf / quoted-pair ) DQUOTE 3320 quoted-string = DQUOTE *( qdtext / quoted-pair ) DQUOTE 3321 qvalue = ( "0" [ "." *3DIGIT ] ) / ( "1" [ "." *3"0" ] ) 3323 received-by = ( uri-host [ ":" port ] ) / pseudonym 3324 received-protocol = [ protocol-name "/" ] protocol-version 3325 relative-part = 3326 request-header = 3327 request-target = "*" / absolute-URI / ( path-absolute [ "?" query ] ) 3328 / authority 3329 response-header = 3330 rfc1123-date = day-name "," SP date1 SP time-of-day SP GMT 3331 rfc850-date = day-name-l "," SP date2 SP time-of-day SP GMT 3333 second = 2DIGIT 3334 start-line = Request-Line / Status-Line 3336 t-codings = "trailers" / ( transfer-extension [ te-params ] ) 3337 tchar = "!" / "#" / "$" / "%" / "&" / "'" / "*" / "+" / "-" / "." / 3338 "^" / "_" / "`" / "|" / "~" / DIGIT / ALPHA 3339 te-ext = OWS ";" OWS token [ "=" ( token / quoted-string ) ] 3340 te-params = OWS ";" OWS "q=" qvalue *te-ext 3341 time-of-day = hour ":" minute ":" second 3342 token = 1*tchar 3343 trailer-part = *( entity-header CRLF ) 3344 transfer-coding = "chunked" / "compress" / "deflate" / "gzip" / 3345 transfer-extension 3346 transfer-extension = token *( OWS ";" OWS transfer-parameter ) 3347 transfer-parameter = attribute BWS "=" BWS value 3349 uri-host = 3351 value = token / quoted-string 3353 year = 4DIGIT 3355 ABNF diagnostics: 3357 ; Chunked-Body defined but not used 3358 ; Content-Length defined but not used 3359 ; HTTP-message defined but not used 3360 ; Host defined but not used 3361 ; Request defined but not used 3362 ; Response defined but not used 3363 ; TE defined but not used 3364 ; URI defined but not used 3365 ; URI-reference defined but not used 3366 ; http-URI defined but not used 3367 ; https-URI defined but not used 3368 ; partial-URI defined but not used 3370 Appendix D. Change Log (to be removed by RFC Editor before publication) 3372 D.1. Since RFC2616 3374 Extracted relevant partitions from [RFC2616]. 3376 D.2. Since draft-ietf-httpbis-p1-messaging-00 3378 Closed issues: 3380 o : "HTTP Version 3381 should be case sensitive" 3382 () 3384 o : "'unsafe' 3385 characters" () 3387 o : "Chunk Size 3388 Definition" () 3390 o : "Message Length" 3391 () 3393 o : "Media Type 3394 Registrations" () 3396 o : "URI includes 3397 query" () 3399 o : "No close on 3400 1xx responses" () 3402 o : "Remove 3403 'identity' token references" 3404 () 3406 o : "Import query 3407 BNF" 3409 o : "qdtext BNF" 3411 o : "Normative and 3412 Informative references" 3414 o : "RFC2606 3415 Compliance" 3417 o : "RFC977 3418 reference" 3420 o : "RFC1700 3421 references" 3423 o : "inconsistency 3424 in date format explanation" 3426 o : "Date reference 3427 typo" 3429 o : "Informative 3430 references" 3432 o : "ISO-8859-1 3433 Reference" 3435 o : "Normative up- 3436 to-date references" 3438 Other changes: 3440 o Update media type registrations to use RFC4288 template. 3442 o Use names of RFC4234 core rules DQUOTE and WSP, fix broken ABNF 3443 for chunk-data (work in progress on 3444 ) 3446 D.3. Since draft-ietf-httpbis-p1-messaging-01 3448 Closed issues: 3450 o : "Bodies on GET 3451 (and other) requests" 3453 o : "Updating to 3454 RFC4288" 3456 o : "Status Code 3457 and Reason Phrase" 3459 o : "rel_path not 3460 used" 3462 Ongoing work on ABNF conversion 3463 (): 3465 o Get rid of duplicate BNF rule names ("host" -> "uri-host", 3466 "trailer" -> "trailer-part"). 3468 o Avoid underscore character in rule names ("http_URL" -> "http- 3469 URL", "abs_path" -> "path-absolute"). 3471 o Add rules for terms imported from URI spec ("absoluteURI", 3472 "authority", "path-absolute", "port", "query", "relativeURI", 3473 "host) -- these will have to be updated when switching over to 3474 RFC3986. 3476 o Synchronize core rules with RFC5234. 3478 o Get rid of prose rules that span multiple lines. 3480 o Get rid of unused rules LOALPHA and UPALPHA. 3482 o Move "Product Tokens" section (back) into Part 1, as "token" is 3483 used in the definition of the Upgrade header. 3485 o Add explicit references to BNF syntax and rules imported from 3486 other parts of the specification. 3488 o Rewrite prose rule "token" in terms of "tchar", rewrite prose rule 3489 "TEXT". 3491 D.4. Since draft-ietf-httpbis-p1-messaging-02 3493 Closed issues: 3495 o : "HTTP-date vs. 3496 rfc1123-date" 3498 o : "WS in quoted- 3499 pair" 3501 Ongoing work on IANA Message Header Registration 3502 (): 3504 o Reference RFC 3984, and update header registrations for headers 3505 defined in this document. 3507 Ongoing work on ABNF conversion 3508 (): 3510 o Replace string literals when the string really is case-sensitive 3511 (HTTP-Version). 3513 D.5. Since draft-ietf-httpbis-p1-messaging-03 3515 Closed issues: 3517 o : "Connection 3518 closing" 3520 o : "Move 3521 registrations and registry information to IANA Considerations" 3523 o : "need new URL 3524 for PAD1995 reference" 3526 o : "IANA 3527 Considerations: update HTTP URI scheme registration" 3529 o : "Cite HTTPS 3530 URI scheme definition" 3532 o : "List-type 3533 headers vs Set-Cookie" 3535 Ongoing work on ABNF conversion 3536 (): 3538 o Replace string literals when the string really is case-sensitive 3539 (HTTP-Date). 3541 o Replace HEX by HEXDIG for future consistence with RFC 5234's core 3542 rules. 3544 D.6. Since draft-ietf-httpbis-p1-messaging-04 3546 Closed issues: 3548 o : "Out-of-date 3549 reference for URIs" 3551 o : "RFC 2822 is 3552 updated by RFC 5322" 3554 Ongoing work on ABNF conversion 3555 (): 3557 o Use "/" instead of "|" for alternatives. 3559 o Get rid of RFC822 dependency; use RFC5234 plus extensions instead. 3561 o Only reference RFC 5234's core rules. 3563 o Introduce new ABNF rules for "bad" whitespace ("BWS"), optional 3564 whitespace ("OWS") and required whitespace ("RWS"). 3566 o Rewrite ABNFs to spell out whitespace rules, factor out header 3567 value format definitions. 3569 D.7. Since draft-ietf-httpbis-p1-messaging-05 3571 Closed issues: 3573 o : "Header LWS" 3575 o : "Sort 1.3 3576 Terminology" 3578 o : "RFC2047 3579 encoded words" 3581 o : "Character 3582 Encodings in TEXT" 3584 o : "Line Folding" 3586 o : "OPTIONS * and 3587 proxies" 3589 o : "Reason-Phrase 3590 BNF" 3592 o : "Use of TEXT" 3594 o : "Join 3595 "Differences Between HTTP Entities and RFC 2045 Entities"?" 3597 o : "RFC822 3598 reference left in discussion of date formats" 3600 Final work on ABNF conversion 3601 (): 3603 o Rewrite definition of list rules, deprecate empty list elements. 3605 o Add appendix containing collected and expanded ABNF. 3607 Other changes: 3609 o Rewrite introduction; add mostly new Architecture Section. 3611 o Move definition of quality values from Part 3 into Part 1; make TE 3612 request header grammar independent of accept-params (defined in 3613 Part 3). 3615 D.8. Since draft-ietf-httpbis-p1-messaging-06 3617 Closed issues: 3619 o : "base for 3620 numeric protocol elements" 3622 o : "comment ABNF" 3624 Partly resolved issues: 3626 o : "205 Bodies" 3627 (took out language that implied that there may be methods for 3628 which a request body MUST NOT be included) 3630 o : "editorial 3631 improvements around HTTP-date" 3633 D.9. Since draft-ietf-httpbis-p1-messaging-07 3635 Closed issues: 3637 o : "Repeating 3638 single-value headers" 3640 o : "increase 3641 connection limit" 3643 o : "IP addresses 3644 in URLs" 3646 o : "take over 3647 HTTP Upgrade Token Registry" 3649 o : "CR and LF in 3650 chunk extension values" 3652 o : "HTTP/0.9 3653 support" 3655 o : "pick IANA 3656 policy (RFC5226) for Transfer Coding / Content Coding" 3658 o : "move 3659 definitions of gzip/deflate/compress to part 1" 3661 o : "disallow 3662 control characters in quoted-pair" 3664 Partly resolved issues: 3666 o : "update IANA 3667 requirements wrt Transfer-Coding values" (add the IANA 3668 Considerations subsection) 3670 Index 3672 A 3673 application/http Media Type 55 3675 C 3676 cache 12 3677 cacheable 13 3678 chunked (Coding Format) 32 3679 client 10 3680 Coding Format 3681 chunked 32 3682 compress 34 3683 deflate 35 3684 gzip 35 3685 compress (Coding Format) 34 3686 connection 10 3687 Connection header 44 3688 Content-Length header 45 3690 D 3691 Date header 46 3692 deflate (Coding Format) 35 3693 downstream 12 3695 G 3696 gateway 12 3697 Grammar 3698 absolute-URI 15 3699 ALPHA 7 3700 asctime-date 31 3701 attribute 31 3702 authority 15 3703 BWS 9 3704 chunk 33 3705 chunk-data 33 3706 chunk-ext 33 3707 chunk-ext-name 33 3708 chunk-ext-val 33 3709 chunk-size 33 3710 Chunked-Body 33 3711 comment 21 3712 Connection 44 3713 connection-token 44 3714 Connection-v 44 3715 Content-Length 45 3716 Content-Length-v 45 3717 CR 7 3718 CRLF 7 3719 ctext 21 3720 CTL 7 3721 Date 46 3722 Date-v 46 3723 date1 30 3724 date2 31 3725 date3 31 3726 day 30 3727 day-name 30 3728 day-name-l 30 3729 DIGIT 7 3730 DQUOTE 7 3731 extension-code 28 3732 extension-method 24 3733 field-content 19 3734 field-name 19 3735 field-value 19 3736 general-header 23 3737 GMT 30 3738 header-field 19 3739 HEXDIG 7 3740 Host 47 3741 Host-v 47 3742 hour 30 3743 HTTP-date 29 3744 HTTP-message 18 3745 HTTP-Prot-Name 14 3746 http-URI 16 3747 HTTP-Version 14 3748 https-URI 17 3749 last-chunk 33 3750 LF 7 3751 message-body 21 3752 Method 24 3753 minute 30 3754 month 30 3755 obs-date 30 3756 obs-text 9 3757 OCTET 7 3758 OWS 9 3759 path-absolute 15 3760 port 15 3761 product 35 3762 product-version 35 3763 protocol-name 52 3764 protocol-version 52 3765 pseudonym 52 3766 qdtext 9 3767 qdtext-nf 33 3768 query 15 3769 quoted-cpair 21 3770 quoted-pair 9 3771 quoted-str-nf 33 3772 quoted-string 9 3773 qvalue 36 3774 Reason-Phrase 28 3775 received-by 52 3776 received-protocol 52 3777 Request 24 3778 Request-Line 24 3779 request-target 24 3780 Response 27 3781 rfc850-date 31 3782 rfc1123-date 30 3783 RWS 9 3784 second 30 3785 SP 7 3786 Status-Code 28 3787 Status-Line 27 3788 t-codings 48 3789 tchar 9 3790 TE 48 3791 te-ext 48 3792 te-params 48 3793 TE-v 48 3794 time-of-day 30 3795 token 9 3796 Trailer 49 3797 trailer-part 33 3798 Trailer-v 49 3799 transfer-coding 31 3800 Transfer-Encoding 50 3801 Transfer-Encoding-v 50 3802 transfer-extension 31 3803 transfer-parameter 31 3804 Upgrade 50 3805 Upgrade-v 50 3806 uri-host 15 3807 URI-reference 15 3808 value 31 3809 VCHAR 7 3810 Via 52 3811 Via-v 52 3812 WSP 7 3813 year 30 3814 gzip (Coding Format) 35 3816 H 3817 header field 18 3818 header section 18 3819 Headers 3820 Connection 44 3821 Content-Length 45 3822 Date 46 3823 Host 47 3824 TE 48 3825 Trailer 49 3826 Transfer-Encoding 49 3827 Upgrade 50 3828 Via 52 3829 headers 18 3830 Host header 47 3831 http URI scheme 16 3832 https URI scheme 17 3834 I 3835 inbound 12 3837 M 3838 Media Type 3839 application/http 55 3840 message/http 54 3841 message 10 3842 message/http Media Type 54 3844 O 3845 origin server 10 3846 outbound 12 3848 P 3849 proxy 12 3851 R 3852 request 10 3853 resource 15 3854 response 10 3855 reverse proxy 12 3857 S 3858 server 10 3860 T 3861 TE header 48 3862 Trailer header 49 3863 Transfer-Encoding header 49 3864 tunnel 12 3866 U 3867 Upgrade header 50 3868 upstream 12 3869 URI scheme 3870 http 16 3871 https 17 3872 user agent 10 3874 V 3875 Via header 52 3877 Authors' Addresses 3879 Roy T. Fielding (editor) 3880 Day Software 3881 23 Corporate Plaza DR, Suite 280 3882 Newport Beach, CA 92660 3883 USA 3885 Phone: +1-949-706-5300 3886 Fax: +1-949-706-5305 3887 Email: fielding@gbiv.com 3888 URI: http://roy.gbiv.com/ 3890 Jim Gettys 3891 One Laptop per Child 3892 21 Oak Knoll Road 3893 Carlisle, MA 01741 3894 USA 3896 Email: jg@laptop.org 3897 URI: http://www.laptop.org/ 3899 Jeffrey C. Mogul 3900 Hewlett-Packard Company 3901 HP Labs, Large Scale Systems Group 3902 1501 Page Mill Road, MS 1177 3903 Palo Alto, CA 94304 3904 USA 3906 Email: JeffMogul@acm.org 3907 Henrik Frystyk Nielsen 3908 Microsoft Corporation 3909 1 Microsoft Way 3910 Redmond, WA 98052 3911 USA 3913 Email: henrikn@microsoft.com 3915 Larry Masinter 3916 Adobe Systems, Incorporated 3917 345 Park Ave 3918 San Jose, CA 95110 3919 USA 3921 Email: LMM@acm.org 3922 URI: http://larry.masinter.net/ 3924 Paul J. Leach 3925 Microsoft Corporation 3926 1 Microsoft Way 3927 Redmond, WA 98052 3929 Email: paulle@microsoft.com 3931 Tim Berners-Lee 3932 World Wide Web Consortium 3933 MIT Computer Science and Artificial Intelligence Laboratory 3934 The Stata Center, Building 32 3935 32 Vassar Street 3936 Cambridge, MA 02139 3937 USA 3939 Email: timbl@w3.org 3940 URI: http://www.w3.org/People/Berners-Lee/ 3941 Yves Lafon (editor) 3942 World Wide Web Consortium 3943 W3C / ERCIM 3944 2004, rte des Lucioles 3945 Sophia-Antipolis, AM 06902 3946 France 3948 Email: ylafon@w3.org 3949 URI: http://www.raubacapeu.net/people/yves/ 3951 Julian F. Reschke (editor) 3952 greenbytes GmbH 3953 Hafenweg 16 3954 Muenster, NW 48155 3955 Germany 3957 Phone: +49 251 2807760 3958 Fax: +49 251 2807761 3959 Email: julian.reschke@greenbytes.de 3960 URI: http://greenbytes.de/tech/webdav/