idnits 2.17.1 draft-ietf-httpbis-p1-messaging-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (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 : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. -- 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 (March 8, 2010) is 5156 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-09 == Outdated reference: A later version (-20) exists of draft-ietf-httpbis-p3-payload-09 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p5-range-09 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p6-cache-09 ** 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 (~~), 6 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: September 9, 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 March 8, 2010 22 HTTP/1.1, part 1: URIs, Connections, and Message Parsing 23 draft-ietf-httpbis-p1-messaging-09 25 Abstract 27 The Hypertext Transfer Protocol (HTTP) is an application-level 28 protocol for distributed, collaborative, hypertext information 29 systems. HTTP has been in use by the World Wide Web global 30 information initiative since 1990. This document is Part 1 of the 31 seven-part specification that defines the protocol referred to as 32 "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 1 provides 33 an overview of HTTP and its associated terminology, defines the 34 "http" and "https" Uniform Resource Identifier (URI) schemes, defines 35 the generic message syntax and parsing requirements for HTTP message 36 frames, and describes general security concerns for implementations. 38 Editorial Note (To be removed by RFC Editor) 40 Discussion of this draft should take place on the HTTPBIS working 41 group mailing list (ietf-http-wg@w3.org). The current issues list is 42 at and related 43 documents (including fancy diffs) can be found at 44 . 46 The changes in this draft are summarized in Appendix D.10. 48 Status of this Memo 49 This Internet-Draft is submitted to IETF in full conformance with the 50 provisions of BCP 78 and BCP 79. 52 Internet-Drafts are working documents of the Internet Engineering 53 Task Force (IETF), its areas, and its working groups. Note that 54 other groups may also distribute working documents as Internet- 55 Drafts. 57 Internet-Drafts are draft documents valid for a maximum of six months 58 and may be updated, replaced, or obsoleted by other documents at any 59 time. It is inappropriate to use Internet-Drafts as reference 60 material or to cite them other than as "work in progress." 62 The list of current Internet-Drafts can be accessed at 63 http://www.ietf.org/ietf/1id-abstracts.txt. 65 The list of Internet-Draft Shadow Directories can be accessed at 66 http://www.ietf.org/shadow.html. 68 This Internet-Draft will expire on September 9, 2010. 70 Copyright Notice 72 Copyright (c) 2010 IETF Trust and the persons identified as the 73 document authors. All rights reserved. 75 This document is subject to BCP 78 and the IETF Trust's Legal 76 Provisions Relating to IETF Documents 77 (http://trustee.ietf.org/license-info) in effect on the date of 78 publication of this document. Please review these documents 79 carefully, as they describe your rights and restrictions with respect 80 to this document. Code Components extracted from this document must 81 include Simplified BSD License text as described in Section 4.e of 82 the Trust Legal Provisions and are provided without warranty as 83 described in the BSD License. 85 This document may contain material from IETF Documents or IETF 86 Contributions published or made publicly available before November 87 10, 2008. The person(s) controlling the copyright in some of this 88 material may not have granted the IETF Trust the right to allow 89 modifications of such material outside the IETF Standards Process. 90 Without obtaining an adequate license from the person(s) controlling 91 the copyright in such materials, this document may not be modified 92 outside the IETF Standards Process, and derivative works of it may 93 not be created outside the IETF Standards Process, except to format 94 it for publication as an RFC or to translate it into languages other 95 than English. 97 Table of Contents 99 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6 100 1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 7 101 1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 7 102 1.2.1. ABNF Extension: #rule . . . . . . . . . . . . . . . . 7 103 1.2.2. Basic Rules . . . . . . . . . . . . . . . . . . . . . 8 104 1.2.3. ABNF Rules defined in other Parts of the 105 Specification . . . . . . . . . . . . . . . . . . . . 10 106 2. HTTP architecture . . . . . . . . . . . . . . . . . . . . . . 10 107 2.1. Client/Server Operation . . . . . . . . . . . . . . . . . 10 108 2.2. Intermediaries . . . . . . . . . . . . . . . . . . . . . . 12 109 2.3. Caches . . . . . . . . . . . . . . . . . . . . . . . . . . 13 110 2.4. Transport Independence . . . . . . . . . . . . . . . . . . 14 111 2.5. HTTP Version . . . . . . . . . . . . . . . . . . . . . . . 14 112 2.6. Uniform Resource Identifiers . . . . . . . . . . . . . . . 16 113 2.6.1. http URI scheme . . . . . . . . . . . . . . . . . . . 16 114 2.6.2. https URI scheme . . . . . . . . . . . . . . . . . . . 17 115 2.6.3. http and https URI Normalization and Comparison . . . 18 116 3. HTTP Message . . . . . . . . . . . . . . . . . . . . . . . . . 19 117 3.1. Message Parsing Robustness . . . . . . . . . . . . . . . . 19 118 3.2. Header Fields . . . . . . . . . . . . . . . . . . . . . . 20 119 3.3. Message Body . . . . . . . . . . . . . . . . . . . . . . . 22 120 3.4. Message Length . . . . . . . . . . . . . . . . . . . . . . 23 121 3.5. General Header Fields . . . . . . . . . . . . . . . . . . 24 122 4. Request . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 123 4.1. Request-Line . . . . . . . . . . . . . . . . . . . . . . . 25 124 4.1.1. Method . . . . . . . . . . . . . . . . . . . . . . . . 25 125 4.1.2. request-target . . . . . . . . . . . . . . . . . . . . 25 126 4.2. The Resource Identified by a Request . . . . . . . . . . . 27 127 5. Response . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 128 5.1. Status-Line . . . . . . . . . . . . . . . . . . . . . . . 28 129 5.1.1. Status Code and Reason Phrase . . . . . . . . . . . . 28 130 6. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 29 131 6.1. Date/Time Formats: Full Date . . . . . . . . . . . . . . . 29 132 6.2. Transfer Codings . . . . . . . . . . . . . . . . . . . . . 31 133 6.2.1. Chunked Transfer Coding . . . . . . . . . . . . . . . 32 134 6.2.2. Compression Codings . . . . . . . . . . . . . . . . . 34 135 6.2.3. Transfer Coding Registry . . . . . . . . . . . . . . . 35 136 6.3. Product Tokens . . . . . . . . . . . . . . . . . . . . . . 35 137 6.4. Quality Values . . . . . . . . . . . . . . . . . . . . . . 36 138 7. Connections . . . . . . . . . . . . . . . . . . . . . . . . . 36 139 7.1. Persistent Connections . . . . . . . . . . . . . . . . . . 36 140 7.1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . 36 141 7.1.2. Overall Operation . . . . . . . . . . . . . . . . . . 37 142 7.1.3. Proxy Servers . . . . . . . . . . . . . . . . . . . . 38 143 7.1.4. Practical Considerations . . . . . . . . . . . . . . . 41 144 7.2. Message Transmission Requirements . . . . . . . . . . . . 42 145 7.2.1. Persistent Connections and Flow Control . . . . . . . 42 146 7.2.2. Monitoring Connections for Error Status Messages . . . 42 147 7.2.3. Use of the 100 (Continue) Status . . . . . . . . . . . 42 148 7.2.4. Client Behavior if Server Prematurely Closes 149 Connection . . . . . . . . . . . . . . . . . . . . . . 44 150 8. Miscellaneous notes that may disappear . . . . . . . . . . . . 45 151 8.1. Scheme aliases considered harmful . . . . . . . . . . . . 45 152 8.2. Use of HTTP for proxy communication . . . . . . . . . . . 45 153 8.3. Interception of HTTP for access control . . . . . . . . . 46 154 8.4. Use of HTTP by other protocols . . . . . . . . . . . . . . 46 155 8.5. Use of HTTP by media type specification . . . . . . . . . 46 156 9. Header Field Definitions . . . . . . . . . . . . . . . . . . . 46 157 9.1. Connection . . . . . . . . . . . . . . . . . . . . . . . . 46 158 9.2. Content-Length . . . . . . . . . . . . . . . . . . . . . . 47 159 9.3. Date . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 160 9.3.1. Clockless Origin Server Operation . . . . . . . . . . 49 161 9.4. Host . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 162 9.5. TE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 163 9.6. Trailer . . . . . . . . . . . . . . . . . . . . . . . . . 51 164 9.7. Transfer-Encoding . . . . . . . . . . . . . . . . . . . . 52 165 9.8. Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . 52 166 9.8.1. Upgrade Token Registry . . . . . . . . . . . . . . . . 53 167 9.9. Via . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 168 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 56 169 10.1. Message Header Registration . . . . . . . . . . . . . . . 56 170 10.2. URI Scheme Registration . . . . . . . . . . . . . . . . . 56 171 10.3. Internet Media Type Registrations . . . . . . . . . . . . 56 172 10.3.1. Internet Media Type message/http . . . . . . . . . . . 56 173 10.3.2. Internet Media Type application/http . . . . . . . . . 58 174 10.4. Transfer Coding Registry . . . . . . . . . . . . . . . . . 59 175 10.5. Upgrade Token Registration . . . . . . . . . . . . . . . . 59 176 11. Security Considerations . . . . . . . . . . . . . . . . . . . 59 177 11.1. Personal Information . . . . . . . . . . . . . . . . . . . 60 178 11.2. Abuse of Server Log Information . . . . . . . . . . . . . 60 179 11.3. Attacks Based On File and Path Names . . . . . . . . . . . 60 180 11.4. DNS Spoofing . . . . . . . . . . . . . . . . . . . . . . . 60 181 11.5. Proxies and Caching . . . . . . . . . . . . . . . . . . . 61 182 11.6. Denial of Service Attacks on Proxies . . . . . . . . . . . 62 183 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 62 184 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 63 185 13.1. Normative References . . . . . . . . . . . . . . . . . . . 63 186 13.2. Informative References . . . . . . . . . . . . . . . . . . 65 187 Appendix A. Tolerant Applications . . . . . . . . . . . . . . . . 67 188 Appendix B. Compatibility with Previous Versions . . . . . . . . 67 189 B.1. Changes from HTTP/1.0 . . . . . . . . . . . . . . . . . . 68 190 B.1.1. Changes to Simplify Multi-homed Web Servers and 191 Conserve IP Addresses . . . . . . . . . . . . . . . . 68 192 B.2. Compatibility with HTTP/1.0 Persistent Connections . . . . 69 193 B.3. Changes from RFC 2068 . . . . . . . . . . . . . . . . . . 70 194 B.4. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 70 195 Appendix C. Collected ABNF . . . . . . . . . . . . . . . . . . . 71 196 Appendix D. Change Log (to be removed by RFC Editor before 197 publication) . . . . . . . . . . . . . . . . . . . . 76 198 D.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 76 199 D.2. Since draft-ietf-httpbis-p1-messaging-00 . . . . . . . . . 76 200 D.3. Since draft-ietf-httpbis-p1-messaging-01 . . . . . . . . . 77 201 D.4. Since draft-ietf-httpbis-p1-messaging-02 . . . . . . . . . 78 202 D.5. Since draft-ietf-httpbis-p1-messaging-03 . . . . . . . . . 79 203 D.6. Since draft-ietf-httpbis-p1-messaging-04 . . . . . . . . . 79 204 D.7. Since draft-ietf-httpbis-p1-messaging-05 . . . . . . . . . 80 205 D.8. Since draft-ietf-httpbis-p1-messaging-06 . . . . . . . . . 81 206 D.9. Since draft-ietf-httpbis-p1-messaging-07 . . . . . . . . . 81 207 D.10. Since draft-ietf-httpbis-p1-messaging-08 . . . . . . . . . 82 208 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 209 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 86 211 1. Introduction 213 The Hypertext Transfer Protocol (HTTP) is an application-level 214 request/response protocol that uses extensible semantics and MIME- 215 like message payloads for flexible interaction with network-based 216 hypertext information systems. HTTP relies upon the Uniform Resource 217 Identifier (URI) standard [RFC3986] to indicate request targets and 218 relationships between resources. Messages are passed in a format 219 similar to that used by Internet mail [RFC5322] and the Multipurpose 220 Internet Mail Extensions (MIME) [RFC2045] (see Appendix A of [Part3] 221 for the differences between HTTP and MIME messages). 223 HTTP is a generic interface protocol for information systems. It is 224 designed to hide the details of how a service is implemented by 225 presenting a uniform interface to clients that is independent of the 226 types of resources provided. Likewise, servers do not need to be 227 aware of each client's purpose: an HTTP request can be considered in 228 isolation rather than being associated with a specific type of client 229 or a predetermined sequence of application steps. The result is a 230 protocol that can be used effectively in many different contexts and 231 for which implementations can evolve independently over time. 233 HTTP is also designed for use as a generic protocol for translating 234 communication to and from other Internet information systems. HTTP 235 proxies and gateways provide access to alternative information 236 services by translating their diverse protocols into a hypertext 237 format that can be viewed and manipulated by clients in the same way 238 as HTTP services. 240 One consequence of HTTP flexibility is that the protocol cannot be 241 defined in terms of what occurs behind the interface. Instead, we 242 are limited to defining the syntax of communication, the intent of 243 received communication, and the expected behavior of recipients. If 244 the communication is considered in isolation, then successful actions 245 should be reflected in corresponding changes to the observable 246 interface provided by servers. However, since multiple clients may 247 act in parallel and perhaps at cross-purposes, we cannot require that 248 such changes be observable beyond the scope of a single response. 250 This document is Part 1 of the seven-part specification of HTTP, 251 defining the protocol referred to as "HTTP/1.1" and obsoleting 252 [RFC2616]. Part 1 describes the architectural elements that are used 253 or referred to in HTTP, defines the "http" and "https" URI schemes, 254 describes overall network operation and connection management, and 255 defines HTTP message framing and forwarding requirements. Our goal 256 is to define all of the mechanisms necessary for HTTP message 257 handling that are independent of message semantics, thereby defining 258 the complete set of requirements for message parsers and message- 259 forwarding intermediaries. 261 1.1. Requirements 263 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 264 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 265 document are to be interpreted as described in [RFC2119]. 267 An implementation is not compliant if it fails to satisfy one or more 268 of the MUST or REQUIRED level requirements for the protocols it 269 implements. An implementation that satisfies all the MUST or 270 REQUIRED level and all the SHOULD level requirements for its 271 protocols is said to be "unconditionally compliant"; one that 272 satisfies all the MUST level requirements but not all the SHOULD 273 level requirements for its protocols is said to be "conditionally 274 compliant." 276 1.2. Syntax Notation 278 This specification uses the Augmented Backus-Naur Form (ABNF) 279 notation of [RFC5234]. 281 The following core rules are included by reference, as defined in 282 [RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF 283 (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote), 284 HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any 8-bit 285 sequence of data), SP (space), VCHAR (any visible [USASCII] 286 character), and WSP (whitespace). 288 As a syntactical convention, ABNF rule names prefixed with "obs-" 289 denote "obsolete" grammar rules that appear for historical reasons. 291 1.2.1. ABNF Extension: #rule 293 The #rule extension to the ABNF rules of [RFC5234] is used to improve 294 readability. 296 A construct "#" is defined, similar to "*", for defining comma- 297 delimited lists of elements. The full form is "#element" 298 indicating at least and at most elements, each separated by a 299 single comma (",") and optional whitespace (OWS, Section 1.2.2). 301 Thus, 303 1#element => element *( OWS "," OWS element ) 305 and: 307 #element => [ 1#element ] 309 and for n >= 1 and m > 1: 311 #element => element *( OWS "," OWS element ) 313 For compatibility with legacy list rules, recipients SHOULD accept 314 empty list elements. In other words, consumers would follow the list 315 productions: 317 #element => [ ( "," / element ) *( OWS "," [ OWS element ] ) ] 319 1#element => *( "," OWS ) element *( OWS "," [ OWS element ] ) 321 Note that empty elements do not contribute to the count of elements 322 present, though. 324 For example, given these ABNF productions: 326 example-list = 1#example-list-elmt 327 example-list-elmt = token ; see Section 1.2.2 329 Then these are valid values for example-list (not including the 330 double quotes, which are present for delimitation only): 332 "foo,bar" 333 " foo ,bar," 334 " foo , ,bar,charlie " 335 "foo ,bar, charlie " 337 But these values would be invalid, as at least one non-empty element 338 is required: 340 "" 341 "," 342 ", ," 344 Appendix C shows the collected ABNF, with the list rules expanded as 345 explained above. 347 1.2.2. Basic Rules 349 HTTP/1.1 defines the sequence CR LF as the end-of-line marker for all 350 protocol elements except the entity-body (see Appendix A for tolerant 351 applications). The end-of-line marker within an entity-body is 352 defined by its associated media type, as described in Section 2.3 of 354 [Part3]. 356 This specification uses three rules to denote the use of linear 357 whitespace: OWS (optional whitespace), RWS (required whitespace), and 358 BWS ("bad" whitespace). 360 The OWS rule is used where zero or more linear whitespace characters 361 may appear. OWS SHOULD either not be produced or be produced as a 362 single SP character. Multiple OWS characters that occur within 363 field-content SHOULD be replaced with a single SP before interpreting 364 the field value or forwarding the message downstream. 366 RWS is used when at least one linear whitespace character is required 367 to separate field tokens. RWS SHOULD be produced as a single SP 368 character. Multiple RWS characters that occur within field-content 369 SHOULD be replaced with a single SP before interpreting the field 370 value or forwarding the message downstream. 372 BWS is used where the grammar allows optional whitespace for 373 historical reasons but senders SHOULD NOT produce it in messages. 374 HTTP/1.1 recipients MUST accept such bad optional whitespace and 375 remove it before interpreting the field value or forwarding the 376 message downstream. 378 OWS = *( [ obs-fold ] WSP ) 379 ; "optional" whitespace 380 RWS = 1*( [ obs-fold ] WSP ) 381 ; "required" whitespace 382 BWS = OWS 383 ; "bad" whitespace 384 obs-fold = CRLF 385 ; see Section 3.2 387 Many HTTP/1.1 header field values consist of words (token or quoted- 388 string) separated by whitespace or special characters. These special 389 characters MUST be in a quoted string to be used within a parameter 390 value (as defined in Section 6.2). 392 token = 1*tchar 394 tchar = "!" / "#" / "$" / "%" / "&" / "'" / "*" 395 / "+" / "-" / "." / "^" / "_" / "`" / "|" / "~" 396 / DIGIT / ALPHA 397 ; any VCHAR, except special 399 special = "(" / ")" / "<" / ">" / "@" / "," 400 / ";" / ":" / "\" / DQUOTE / "/" / "[" 401 / "]" / "?" / "=" / "{" / "}" 403 A string of text is parsed as a single word if it is quoted using 404 double-quote marks. 406 quoted-string = DQUOTE *( qdtext / quoted-pair ) DQUOTE 407 qdtext = OWS / %x21 / %x23-5B / %x5D-7E / obs-text 408 ; OWS / / obs-text 409 obs-text = %x80-FF 411 The backslash character ("\") can be used as a single-character 412 quoting mechanism within quoted-string constructs: 414 quoted-pair = "\" ( WSP / VCHAR / obs-text ) 416 Producers SHOULD NOT escape characters that do not require escaping 417 (i.e., other than DQUOTE and the backslash character). 419 1.2.3. ABNF Rules defined in other Parts of the Specification 421 The ABNF rules below are defined in other parts: 423 request-header = 424 response-header = 426 entity-body = 427 entity-header = 429 Cache-Control = 430 Pragma = 431 Warning = 433 2. HTTP architecture 435 HTTP was created for the World Wide Web architecture and has evolved 436 over time to support the scalability needs of a worldwide hypertext 437 system. Much of that architecture is reflected in the terminology 438 and syntax productions used to define HTTP. 440 2.1. Client/Server Operation 442 HTTP is a request/response protocol that operates by exchanging 443 messages across a reliable transport or session-layer connection. An 444 HTTP client is a program that establishes a connection to a server 445 for the purpose of sending one or more HTTP requests. An HTTP server 446 is a program that accepts connections in order to service HTTP 447 requests by sending HTTP responses. 449 Note that the terms "client" and "server" refer only to the roles 450 that these programs perform for a particular connection. The same 451 program may act as a client on some connections and a server on 452 others. We use the term "user agent" to refer to the program that 453 initiates a request, such as a WWW browser, editor, or spider (web- 454 traversing robot), and the term "origin server" to refer to the 455 program that can originate authoritative responses to a request. 457 Most HTTP communication consists of a retrieval request (GET) for a 458 representation of some resource identified by a URI. In the simplest 459 case, this may be accomplished via a single connection (v) between 460 the user agent (UA) and the origin server (O). 462 request chain ------------------------> 463 UA -------------------v------------------- O 464 <----------------------- response chain 466 A client sends an HTTP request to the server in the form of a request 467 message (Section 4), beginning with a method, URI, and protocol 468 version, followed by MIME-like header fields containing request 469 modifiers, client information, and payload metadata, an empty line to 470 indicate the end of the header section, and finally the payload body 471 (if any). 473 A server responds to the client's request by sending an HTTP response 474 message (Section 5), beginning with a status line that includes the 475 protocol version, a success or error code, and textual reason phrase, 476 followed by MIME-like header fields containing server information, 477 resource metadata, and payload metadata, an empty line to indicate 478 the end of the header section, and finally the payload body (if any). 480 The following example illustrates a typical message exchange for a 481 GET request on the URI "http://www.example.com/hello.txt": 483 client request: 485 GET /hello.txt HTTP/1.1 486 User-Agent: curl/7.16.3 libcurl/7.16.3 OpenSSL/0.9.7l zlib/1.2.3 487 Host: www.example.com 488 Accept: */* 490 server response: 492 HTTP/1.1 200 OK 493 Date: Mon, 27 Jul 2009 12:28:53 GMT 494 Server: Apache 495 Last-Modified: Wed, 22 Jul 2009 19:15:56 GMT 496 ETag: "34aa387-d-1568eb00" 497 Accept-Ranges: bytes 498 Content-Length: 14 499 Vary: Accept-Encoding 500 Content-Type: text/plain 502 Hello World! 504 2.2. Intermediaries 506 A more complicated situation occurs when one or more intermediaries 507 are present in the request/response chain. There are three common 508 forms of intermediary: proxy, gateway, and tunnel. In some cases, a 509 single intermediary may act as an origin server, proxy, gateway, or 510 tunnel, switching behavior based on the nature of each request. 512 request chain --------------------------------------> 513 UA -----v----- A -----v----- B -----v----- C -----v----- O 514 <------------------------------------- response chain 516 The figure above shows three intermediaries (A, B, and C) between the 517 user agent and origin server. A request or response message that 518 travels the whole chain will pass through four separate connections. 519 Some HTTP communication options may apply only to the connection with 520 the nearest, non-tunnel neighbor, only to the end-points of the 521 chain, or to all connections along the chain. Although the diagram 522 is linear, each participant may be engaged in multiple, simultaneous 523 communications. For example, B may be receiving requests from many 524 clients other than A, and/or forwarding requests to servers other 525 than C, at the same time that it is handling A's request. 527 We use the terms "upstream" and "downstream" to describe various 528 requirements in relation to the directional flow of a message: all 529 messages flow from upstream to downstream. Likewise, we use the 530 terms "inbound" and "outbound" to refer to directions in relation to 531 the request path: "inbound" means toward the origin server and 532 "outbound" means toward the user agent. 534 A proxy is a message forwarding agent that is selected by the client, 535 usually via local configuration rules, to receive requests for some 536 type(s) of absolute URI and attempt to satisfy those requests via 537 translation through the HTTP interface. Some translations are 538 minimal, such as for proxy requests for "http" URIs, whereas other 539 requests may require translation to and from entirely different 540 application-layer protocols. Proxies are often used to group an 541 organization's HTTP requests through a common intermediary for the 542 sake of security, annotation services, or shared caching. 544 A gateway (a.k.a., reverse proxy) is a receiving agent that acts as a 545 layer above some other server(s) and translates the received requests 546 to the underlying server's protocol. Gateways are often used for 547 load balancing or partitioning HTTP services across multiple 548 machines. Unlike a proxy, a gateway receives requests as if it were 549 the origin server for the requested resource; the requesting client 550 will not be aware that it is communicating with a gateway. A gateway 551 communicates with the client as if the gateway is the origin server 552 and thus is subject to all of the requirements on origin servers for 553 that connection. A gateway communicates with inbound servers using 554 any protocol it desires, including private extensions to HTTP that 555 are outside the scope of this specification. 557 A tunnel acts as a blind relay between two connections without 558 changing the messages. Once active, a tunnel is not considered a 559 party to the HTTP communication, though the tunnel may have been 560 initiated by an HTTP request. A tunnel ceases to exist when both 561 ends of the relayed connection are closed. Tunnels are used to 562 extend a virtual connection through an intermediary, such as when 563 transport-layer security is used to establish private communication 564 through a shared firewall proxy. 566 2.3. Caches 568 Any party to HTTP communication that is not acting as a tunnel may 569 employ an internal cache for handling requests. A cache is a local 570 store of previous response messages and the subsystem that controls 571 its message storage, retrieval, and deletion. A cache stores 572 cacheable responses in order to reduce the response time and network 573 bandwidth consumption on future, equivalent requests. Any client or 574 server may include a cache, though a cache cannot be used by a server 575 while it is acting as a tunnel. 577 The effect of a cache is that the request/response chain is shortened 578 if one of the participants along the chain has a cached response 579 applicable to that request. The following illustrates the resulting 580 chain if B has a cached copy of an earlier response from O (via C) 581 for a request which has not been cached by UA or A. 583 request chain ----------> 584 UA -----v----- A -----v----- B - - - - - - C - - - - - - O 585 <--------- response chain 587 A response is cacheable if a cache is allowed to store a copy of the 588 response message for use in answering subsequent requests. Even when 589 a response is cacheable, there may be additional constraints placed 590 by the client or by the origin server on when that cached response 591 can be used for a particular request. HTTP requirements for cache 592 behavior and cacheable responses are defined in Section 2 of [Part6]. 594 There are a wide variety of architectures and configurations of 595 caches and proxies deployed across the World Wide Web and inside 596 large organizations. These systems include national hierarchies of 597 proxy caches to save transoceanic bandwidth, systems that broadcast 598 or multicast cache entries, organizations that distribute subsets of 599 cached data via optical media, and so on. 601 2.4. Transport Independence 603 HTTP systems are used in a wide variety of environments, from 604 corporate intranets with high-bandwidth links to long-distance 605 communication over low-power radio links and intermittent 606 connectivity. 608 HTTP communication usually takes place over TCP/IP connections. The 609 default port is TCP 80 610 (), but other ports can 611 be used. This does not preclude HTTP from being implemented on top 612 of any other protocol on the Internet, or on other networks. HTTP 613 only presumes a reliable transport; any protocol that provides such 614 guarantees can be used; the mapping of the HTTP/1.1 request and 615 response structures onto the transport data units of the protocol in 616 question is outside the scope of this specification. 618 In HTTP/1.0, most implementations used a new connection for each 619 request/response exchange. In HTTP/1.1, a connection may be used for 620 one or more request/response exchanges, although connections may be 621 closed for a variety of reasons (see Section 7.1). 623 2.5. HTTP Version 625 HTTP uses a "." numbering scheme to indicate versions 626 of the protocol. The protocol versioning policy is intended to allow 627 the sender to indicate the format of a message and its capacity for 628 understanding further HTTP communication, rather than the features 629 obtained via that communication. No change is made to the version 630 number for the addition of message components which do not affect 631 communication behavior or which only add to extensible field values. 632 The number is incremented when the changes made to the 633 protocol add features which do not change the general message parsing 634 algorithm, but which may add to the message semantics and imply 635 additional capabilities of the sender. The number is 636 incremented when the format of a message within the protocol is 637 changed. See [RFC2145] for a fuller explanation. 639 The version of an HTTP message is indicated by an HTTP-Version field 640 in the first line of the message. HTTP-Version is case-sensitive. 642 HTTP-Version = HTTP-Prot-Name "/" 1*DIGIT "." 1*DIGIT 643 HTTP-Prot-Name = %x48.54.54.50 ; "HTTP", case-sensitive 645 Note that the major and minor numbers MUST be treated as separate 646 integers and that each MAY be incremented higher than a single digit. 647 Thus, HTTP/2.4 is a lower version than HTTP/2.13, which in turn is 648 lower than HTTP/12.3. Leading zeros MUST be ignored by recipients 649 and MUST NOT be sent. 651 An application that sends a request or response message that includes 652 HTTP-Version of "HTTP/1.1" MUST be at least conditionally compliant 653 with this specification. Applications that are at least 654 conditionally compliant with this specification SHOULD use an HTTP- 655 Version of "HTTP/1.1" in their messages, and MUST do so for any 656 message that is not compatible with HTTP/1.0. For more details on 657 when to send specific HTTP-Version values, see [RFC2145]. 659 The HTTP version of an application is the highest HTTP version for 660 which the application is at least conditionally compliant. 662 Proxy and gateway applications need to be careful when forwarding 663 messages in protocol versions different from that of the application. 664 Since the protocol version indicates the protocol capability of the 665 sender, a proxy/gateway MUST NOT send a message with a version 666 indicator which is greater than its actual version. If a higher 667 version request is received, the proxy/gateway MUST either downgrade 668 the request version, or respond with an error, or switch to tunnel 669 behavior. 671 Due to interoperability problems with HTTP/1.0 proxies discovered 672 since the publication of [RFC2068], caching proxies MUST, gateways 673 MAY, and tunnels MUST NOT upgrade the request to the highest version 674 they support. The proxy/gateway's response to that request MUST be 675 in the same major version as the request. 677 Note: Converting between versions of HTTP may involve modification 678 of header fields required or forbidden by the versions involved. 680 2.6. Uniform Resource Identifiers 682 Uniform Resource Identifiers (URIs) [RFC3986] are used throughout 683 HTTP as the means for identifying resources. URI references are used 684 to target requests, indicate redirects, and define relationships. 685 HTTP does not limit what a resource may be; it merely defines an 686 interface that can be used to interact with a resource via HTTP. 687 More information on the scope of URIs and resources can be found in 688 [RFC3986]. 690 This specification adopts the definitions of "URI-reference", 691 "absolute-URI", "relative-part", "port", "host", "path-abempty", 692 "path-absolute", "query", and "authority" from [RFC3986]. In 693 addition, we define a partial-URI rule for protocol elements that 694 allow a relative URI without a fragment. 696 URI = 697 URI-reference = 698 absolute-URI = 699 relative-part = 700 authority = 701 path-abempty = 702 path-absolute = 703 port = 704 query = 705 uri-host = 707 partial-URI = relative-part [ "?" query ] 709 Each protocol element in HTTP that allows a URI reference will 710 indicate in its ABNF production whether the element allows only a URI 711 in absolute form (absolute-URI), any relative reference (relative- 712 ref), or some other subset of the URI-reference grammar. Unless 713 otherwise indicated, URI references are parsed relative to the 714 request target (the default base URI for both the request and its 715 corresponding response). 717 2.6.1. http URI scheme 719 The "http" URI scheme is hereby defined for the purpose of minting 720 identifiers according to their association with the hierarchical 721 namespace governed by a potential HTTP origin server listening for 722 TCP connections on a given port. The HTTP server is identified via 723 the generic syntax's authority component, which includes a host 724 identifier and optional TCP port, and the remainder of the URI is 725 considered to be identifying data corresponding to a resource for 726 which that server might provide an HTTP interface. 728 http-URI = "http:" "//" authority path-abempty [ "?" query ] 730 The host identifier within an authority component is defined in 731 [RFC3986], Section 3.2.2. If host is provided as an IP literal or 732 IPv4 address, then the HTTP server is any listener on the indicated 733 TCP port at that IP address. If host is a registered name, then that 734 name is considered an indirect identifier and the recipient might use 735 a name resolution service, such as DNS, to find the address of a 736 listener for that host. The host MUST NOT be empty; if an "http" URI 737 is received with an empty host, then it MUST be rejected as invalid. 738 If the port subcomponent is empty or not given, then TCP port 80 is 739 assumed (the default reserved port for WWW services). 741 Regardless of the form of host identifier, access to that host is not 742 implied by the mere presence of its name or address. The host may or 743 may not exist and, even when it does exist, may or may not be running 744 an HTTP server or listening to the indicated port. The "http" URI 745 scheme makes use of the delegated nature of Internet names and 746 addresses to establish a naming authority (whatever entity has the 747 ability to place an HTTP server at that Internet name or address) and 748 allows that authority to determine which names are valid and how they 749 might be used. 751 When an "http" URI is used within a context that calls for access to 752 the indicated resource, a client MAY attempt access by resolving the 753 host to an IP address, establishing a TCP connection to that address 754 on the indicated port, and sending an HTTP request message to the 755 server containing the URI's identifying data as described in 756 Section 4. If the server responds to that request with a non-interim 757 HTTP response message, as described in Section 5, then that response 758 is considered an authoritative answer to the client's request. 760 Although HTTP is independent of the transport protocol, the "http" 761 scheme is specific to TCP-based services because the name delegation 762 process depends on TCP for establishing authority. An HTTP service 763 based on some other underlying connection protocol would presumably 764 be identified using a different URI scheme, just as the "https" 765 scheme (below) is used for servers that require an SSL/TLS transport 766 layer on a connection. Other protocols may also be used to provide 767 access to "http" identified resources --- it is only the 768 authoritative interface used for mapping the namespace that is 769 specific to TCP. 771 2.6.2. https URI scheme 773 The "https" URI scheme is hereby defined for the purpose of minting 774 identifiers according to their association with the hierarchical 775 namespace governed by a potential HTTP origin server listening for 776 SSL/TLS-secured connections on a given TCP port. The host and port 777 are determined in the same way as for the "http" scheme, except that 778 a default TCP port of 443 is assumed if the port subcomponent is 779 empty or not given. 781 https-URI = "https:" "//" authority path-abempty [ "?" query ] 783 The primary difference between the "http" and "https" schemes is that 784 interaction with the latter is required to be secured for privacy 785 through the use of strong encryption. The URI cannot be sent in a 786 request until the connection is secure. Likewise, the default for 787 caching is that each response that would be considered "public" under 788 the "http" scheme is instead treated as "private" and thus not 789 eligible for shared caching. 791 The process for authoritative access to an "https" identified 792 resource is defined in [RFC2818]. 794 2.6.3. http and https URI Normalization and Comparison 796 Since the "http" and "https" schemes conform to the URI generic 797 syntax, such URIs are normalized and compared according to the 798 algorithm defined in [RFC3986], Section 6, using the defaults 799 described above for each scheme. 801 If the port is equal to the default port for a scheme, the normal 802 form is to elide the port subcomponent. Likewise, an empty path 803 component is equivalent to an absolute path of "/", so the normal 804 form is to provide a path of "/" instead. The scheme and host are 805 case-insensitive and normally provided in lowercase; all other 806 components are compared in a case-sensitive manner. Characters other 807 than those in the "reserved" set are equivalent to their percent- 808 encoded octets (see [RFC3986], Section 2.1): the normal form is to 809 not encode them. 811 For example, the following three URIs are equivalent: 813 http://example.com:80/~smith/home.html 814 http://EXAMPLE.com/%7Esmith/home.html 815 http://EXAMPLE.com:/%7esmith/home.html 817 [[TODO-not-here: This paragraph does not belong here. --roy]] If 818 path-abempty is the empty string (i.e., there is no slash "/" path 819 separator following the authority), then the "http" URI MUST be given 820 as "/" when used as a request-target (Section 4.1.2). If a proxy 821 receives a host name which is not a fully qualified domain name, it 822 MAY add its domain to the host name it received. If a proxy receives 823 a fully qualified domain name, the proxy MUST NOT change the host 824 name. 826 3. HTTP Message 828 All HTTP/1.1 messages consist of a start-line followed by a sequence 829 of characters in a format similar to the Internet Message Format 830 [RFC5322]: zero or more header fields (collectively referred to as 831 the "headers" or the "header section"), an empty line indicating the 832 end of the header section, and an optional message-body. 834 An HTTP message can either be a request from client to server or a 835 response from server to client. Syntactically, the two types of 836 message differ only in the start-line, which is either a Request-Line 837 (for requests) or a Status-Line (for responses), and in the algorithm 838 for determining the length of the message-body (Section 3.4). In 839 theory, a client could receive requests and a server could receive 840 responses, distinguishing them by their different start-line formats, 841 but in practice servers are implemented to only expect a request (a 842 response is interpreted as an unknown or invalid request method) and 843 clients are implemented to only expect a response. 845 HTTP-message = start-line 846 *( header-field CRLF ) 847 CRLF 848 [ message-body ] 849 start-line = Request-Line / Status-Line 851 Whitespace (WSP) MUST NOT be sent between the start-line and the 852 first header field. The presence of whitespace might be an attempt 853 to trick a noncompliant implementation of HTTP into ignoring that 854 field or processing the next line as a new request, either of which 855 may result in security issues when implementations within the request 856 chain interpret the same message differently. HTTP/1.1 servers MUST 857 reject such a message with a 400 (Bad Request) response. 859 3.1. Message Parsing Robustness 861 In the interest of robustness, servers SHOULD ignore at least one 862 empty line received where a Request-Line is expected. In other 863 words, if the server is reading the protocol stream at the beginning 864 of a message and receives a CRLF first, it should ignore the CRLF. 866 Some old HTTP/1.0 client implementations generate an extra CRLF after 867 a POST request as a lame workaround for some early server 868 applications that failed to read message-body content that was not 869 terminated by a line-ending. An HTTP/1.1 client MUST NOT preface or 870 follow a request with an extra CRLF. If terminating the request 871 message-body with a line-ending is desired, then the client MUST 872 include the terminating CRLF octets as part of the message-body 873 length. 875 The normal procedure for parsing an HTTP message is to read the 876 start-line into a structure, read each header field into a hash table 877 by field name until the empty line, and then use the parsed data to 878 determine if a message-body is expected. If a message-body has been 879 indicated, then it is read as a stream until an amount of OCTETs 880 equal to the message-length is read or the connection is closed. 881 Care must be taken to parse an HTTP message as a sequence of OCTETs 882 in an encoding that is a superset of US-ASCII. Attempting to parse 883 HTTP as a stream of Unicode characters in a character encoding like 884 UTF-16 may introduce security flaws due to the differing ways that 885 such parsers interpret invalid characters. 887 3.2. Header Fields 889 Each HTTP header field consists of a case-insensitive field name 890 followed by a colon (":"), optional whitespace, and the field value. 892 header-field = field-name ":" OWS [ field-value ] OWS 893 field-name = token 894 field-value = *( field-content / OWS ) 895 field-content = *( WSP / VCHAR / obs-text ) 897 No whitespace is allowed between the header field name and colon. 898 For security reasons, any request message received containing such 899 whitespace MUST be rejected with a response code of 400 (Bad 900 Request). A proxy MUST remove any such whitespace from a response 901 message before forwarding the message downstream. 903 A field value MAY be preceded by optional whitespace (OWS); a single 904 SP is preferred. The field value does not include any leading or 905 trailing white space: OWS occurring before the first non-whitespace 906 character of the field value or after the last non-whitespace 907 character of the field value is ignored and SHOULD be removed before 908 further processing (as this does not change the meaning of the header 909 field). 911 The order in which header fields with differing field names are 912 received is not significant. However, it is "good practice" to send 913 header fields that contain control data first, such as Host on 914 requests and Date on responses, so that implementations can decide 915 when not to handle a message as early as possible. A server MUST 916 wait until the entire header section is received before interpreting 917 a request message, since later header fields might include 918 conditionals, authentication credentials, or deliberately misleading 919 duplicate header fields that would impact request processing. 921 Multiple header fields with the same field name MUST NOT be sent in a 922 message unless the entire field value for that header field is 923 defined as a comma-separated list [i.e., #(values)]. Multiple header 924 fields with the same field name can be combined into one "field-name: 925 field-value" pair, without changing the semantics of the message, by 926 appending each subsequent field value to the combined field value in 927 order, separated by a comma. The order in which header fields with 928 the same field name are received is therefore significant to the 929 interpretation of the combined field value; a proxy MUST NOT change 930 the order of these field values when forwarding a message. 932 Note: The "Set-Cookie" header as implemented in practice (as 933 opposed to how it is specified in [RFC2109]) can occur multiple 934 times, but does not use the list syntax, and thus cannot be 935 combined into a single line. (See Appendix A.2.3 of [Kri2001] for 936 details.) Also note that the Set-Cookie2 header specified in 937 [RFC2965] does not share this problem. 939 Historically, HTTP header field values could be extended over 940 multiple lines by preceding each extra line with at least one space 941 or horizontal tab character (line folding). This specification 942 deprecates such line folding except within the message/http media 943 type (Section 10.3.1). HTTP/1.1 senders MUST NOT produce messages 944 that include line folding (i.e., that contain any field-content that 945 matches the obs-fold rule) unless the message is intended for 946 packaging within the message/http media type. HTTP/1.1 recipients 947 SHOULD accept line folding and replace any embedded obs-fold 948 whitespace with a single SP prior to interpreting the field value or 949 forwarding the message downstream. 951 Historically, HTTP has allowed field content with text in the ISO- 952 8859-1 [ISO-8859-1] character encoding and supported other character 953 sets only through use of [RFC2047] encoding. In practice, most HTTP 954 header field values use only a subset of the US-ASCII character 955 encoding [USASCII]. Newly defined header fields SHOULD limit their 956 field values to US-ASCII characters. Recipients SHOULD treat other 957 (obs-text) octets in field content as opaque data. 959 Comments can be included in some HTTP header fields by surrounding 960 the comment text with parentheses. Comments are only allowed in 961 fields containing "comment" as part of their field value definition. 963 comment = "(" *( ctext / quoted-cpair / comment ) ")" 964 ctext = OWS / %x21-27 / %x2A-5B / %x5D-7E / obs-text 965 ; OWS / / obs-text 967 The backslash character ("\") can be used as a single-character 968 quoting mechanism within comment constructs: 970 quoted-cpair = "\" ( WSP / VCHAR / obs-text ) 972 Producers SHOULD NOT escape characters that do not require escaping 973 (i.e., other than the backslash character "\" and the parentheses "(" 974 and ")"). 976 3.3. Message Body 978 The message-body (if any) of an HTTP message is used to carry the 979 entity-body associated with the request or response. The message- 980 body differs from the entity-body only when a transfer-coding has 981 been applied, as indicated by the Transfer-Encoding header field 982 (Section 9.7). 984 message-body = entity-body 985 / 987 Transfer-Encoding MUST be used to indicate any transfer-codings 988 applied by an application to ensure safe and proper transfer of the 989 message. Transfer-Encoding is a property of the message, not of the 990 entity, and thus MAY be added or removed by any application along the 991 request/response chain. (However, Section 6.2 places restrictions on 992 when certain transfer-codings may be used.) 994 The rules for when a message-body is allowed in a message differ for 995 requests and responses. 997 The presence of a message-body in a request is signaled by the 998 inclusion of a Content-Length or Transfer-Encoding header field in 999 the request's header fields. When a request message contains both a 1000 message-body of non-zero length and a method that does not define any 1001 semantics for that request message-body, then an origin server SHOULD 1002 either ignore the message-body or respond with an appropriate error 1003 message (e.g., 413). A proxy or gateway, when presented the same 1004 request, SHOULD either forward the request inbound with the message- 1005 body or ignore the message-body when determining a response. 1007 For response messages, whether or not a message-body is included with 1008 a message is dependent on both the request method and the response 1009 status code (Section 5.1.1). All responses to the HEAD request 1010 method MUST NOT include a message-body, even though the presence of 1011 entity-header fields might lead one to believe they do. All 1xx 1012 (Informational), 204 (No Content), and 304 (Not Modified) responses 1013 MUST NOT include a message-body. All other responses do include a 1014 message-body, although it MAY be of zero length. 1016 3.4. Message Length 1018 The transfer-length of a message is the length of the message-body as 1019 it appears in the message; that is, after any transfer-codings have 1020 been applied. When a message-body is included with a message, the 1021 transfer-length of that body is determined by one of the following 1022 (in order of precedence): 1024 1. Any response message which "MUST NOT" include a message-body 1025 (such as the 1xx, 204, and 304 responses and any response to a 1026 HEAD request) is always terminated by the first empty line after 1027 the header fields, regardless of the entity-header fields present 1028 in the message. 1030 2. If a Transfer-Encoding header field (Section 9.7) is present and 1031 the "chunked" transfer-coding (Section 6.2) is used, the 1032 transfer-length is defined by the use of this transfer-coding. 1033 If a Transfer-Encoding header field is present and the "chunked" 1034 transfer-coding is not present, the transfer-length is defined by 1035 the sender closing the connection. 1037 3. If a Content-Length header field (Section 9.2) is present, its 1038 value in OCTETs represents both the entity-length and the 1039 transfer-length. The Content-Length header field MUST NOT be 1040 sent if these two lengths are different (i.e., if a Transfer- 1041 Encoding header field is present). If a message is received with 1042 both a Transfer-Encoding header field and a Content-Length header 1043 field, the latter MUST be ignored. 1045 4. If the message uses the media type "multipart/byteranges", and 1046 the transfer-length is not otherwise specified, then this self- 1047 delimiting media type defines the transfer-length. This media 1048 type MUST NOT be used unless the sender knows that the recipient 1049 can parse it; the presence in a request of a Range header with 1050 multiple byte-range specifiers from a HTTP/1.1 client implies 1051 that the client can parse multipart/byteranges responses. 1053 A range header might be forwarded by a HTTP/1.0 proxy that 1054 does not understand multipart/byteranges; in this case the 1055 server MUST delimit the message using methods defined in items 1056 1, 3 or 5 of this section. 1058 5. By the server closing the connection. (Closing the connection 1059 cannot be used to indicate the end of a request body, since that 1060 would leave no possibility for the server to send back a 1061 response.) 1063 For compatibility with HTTP/1.0 applications, HTTP/1.1 requests 1064 containing a message-body MUST include a valid Content-Length header 1065 field unless the server is known to be HTTP/1.1 compliant. If a 1066 request contains a message-body and a Content-Length is not given, 1067 the server SHOULD respond with 400 (Bad Request) if it cannot 1068 determine the length of the message, or with 411 (Length Required) if 1069 it wishes to insist on receiving a valid Content-Length. 1071 All HTTP/1.1 applications that receive entities MUST accept the 1072 "chunked" transfer-coding (Section 6.2), thus allowing this mechanism 1073 to be used for messages when the message length cannot be determined 1074 in advance. 1076 Messages MUST NOT include both a Content-Length header field and a 1077 transfer-coding. If the message does include a transfer-coding, the 1078 Content-Length MUST be ignored. 1080 When a Content-Length is given in a message where a message-body is 1081 allowed, its field value MUST exactly match the number of OCTETs in 1082 the message-body. HTTP/1.1 user agents MUST notify the user when an 1083 invalid length is received and detected. 1085 3.5. General Header Fields 1087 There are a few header fields which have general applicability for 1088 both request and response messages, but which do not apply to the 1089 entity being transferred. These header fields apply only to the 1090 message being transmitted. 1092 general-header = Cache-Control ; [Part6], Section 3.2 1093 / Connection ; Section 9.1 1094 / Date ; Section 9.3 1095 / Pragma ; [Part6], Section 3.4 1096 / Trailer ; Section 9.6 1097 / Transfer-Encoding ; Section 9.7 1098 / Upgrade ; Section 9.8 1099 / Via ; Section 9.9 1100 / Warning ; [Part6], Section 3.6 1102 General-header field names can be extended reliably only in 1103 combination with a change in the protocol version. However, new or 1104 experimental header fields may be given the semantics of general 1105 header fields if all parties in the communication recognize them to 1106 be general-header fields. Unrecognized header fields are treated as 1107 entity-header fields. 1109 4. Request 1111 A request message from a client to a server includes, within the 1112 first line of that message, the method to be applied to the resource, 1113 the identifier of the resource, and the protocol version in use. 1115 Request = Request-Line ; Section 4.1 1116 *(( general-header ; Section 3.5 1117 / request-header ; [Part2], Section 3 1118 / entity-header ) CRLF ) ; [Part3], Section 3.1 1119 CRLF 1120 [ message-body ] ; Section 3.3 1122 4.1. Request-Line 1124 The Request-Line begins with a method token, followed by the request- 1125 target and the protocol version, and ending with CRLF. The elements 1126 are separated by SP characters. No CR or LF is allowed except in the 1127 final CRLF sequence. 1129 Request-Line = Method SP request-target SP HTTP-Version CRLF 1131 4.1.1. Method 1133 The Method token indicates the method to be performed on the resource 1134 identified by the request-target. The method is case-sensitive. 1136 Method = token 1138 4.1.2. request-target 1140 The request-target identifies the resource upon which to apply the 1141 request. 1143 request-target = "*" 1144 / absolute-URI 1145 / ( path-absolute [ "?" query ] ) 1146 / authority 1148 The four options for request-target are dependent on the nature of 1149 the request. The asterisk "*" means that the request does not apply 1150 to a particular resource, but to the server itself, and is only 1151 allowed when the method used does not necessarily apply to a 1152 resource. One example would be 1154 OPTIONS * HTTP/1.1 1156 The absolute-URI form is REQUIRED when the request is being made to a 1157 proxy. The proxy is requested to forward the request or service it 1158 from a valid cache, and return the response. Note that the proxy MAY 1159 forward the request on to another proxy or directly to the server 1160 specified by the absolute-URI. In order to avoid request loops, a 1161 proxy MUST be able to recognize all of its server names, including 1162 any aliases, local variations, and the numeric IP address. An 1163 example Request-Line would be: 1165 GET http://www.example.org/pub/WWW/TheProject.html HTTP/1.1 1167 To allow for transition to absolute-URIs in all requests in future 1168 versions of HTTP, all HTTP/1.1 servers MUST accept the absolute-URI 1169 form in requests, even though HTTP/1.1 clients will only generate 1170 them in requests to proxies. 1172 The authority form is only used by the CONNECT method (Section 7.9 of 1173 [Part2]). 1175 The most common form of request-target is that used to identify a 1176 resource on an origin server or gateway. In this case the absolute 1177 path of the URI MUST be transmitted (see Section 2.6.1, path- 1178 absolute) as the request-target, and the network location of the URI 1179 (authority) MUST be transmitted in a Host header field. For example, 1180 a client wishing to retrieve the resource above directly from the 1181 origin server would create a TCP connection to port 80 of the host 1182 "www.example.org" and send the lines: 1184 GET /pub/WWW/TheProject.html HTTP/1.1 1185 Host: www.example.org 1187 followed by the remainder of the Request. Note that the absolute 1188 path cannot be empty; if none is present in the original URI, it MUST 1189 be given as "/" (the server root). 1191 If a proxy receives a request without any path in the request-target 1192 and the method specified is capable of supporting the asterisk form 1193 of request-target, then the last proxy on the request chain MUST 1194 forward the request with "*" as the final request-target. 1196 For example, the request 1198 OPTIONS http://www.example.org:8001 HTTP/1.1 1200 would be forwarded by the proxy as 1202 OPTIONS * HTTP/1.1 1203 Host: www.example.org:8001 1205 after connecting to port 8001 of host "www.example.org". 1207 The request-target is transmitted in the format specified in 1208 Section 2.6.1. If the request-target is percent-encoded ([RFC3986], 1209 Section 2.1), the origin server MUST decode the request-target in 1210 order to properly interpret the request. Servers SHOULD respond to 1211 invalid request-targets with an appropriate status code. 1213 A transparent proxy MUST NOT rewrite the "path-absolute" part of the 1214 received request-target when forwarding it to the next inbound 1215 server, except as noted above to replace a null path-absolute with 1216 "/". 1218 Note: The "no rewrite" rule prevents the proxy from changing the 1219 meaning of the request when the origin server is improperly using 1220 a non-reserved URI character for a reserved purpose. Implementors 1221 should be aware that some pre-HTTP/1.1 proxies have been known to 1222 rewrite the request-target. 1224 HTTP does not place a pre-defined limit on the length of a request- 1225 target. A server MUST be prepared to receive URIs of unbounded 1226 length and respond with the 414 (URI Too Long) status if the received 1227 request-target would be longer than the server wishes to handle (see 1228 Section 8.4.15 of [Part2]). 1230 Various ad-hoc limitations on request-target length are found in 1231 practice. It is RECOMMENDED that all HTTP senders and recipients 1232 support request-target lengths of 8000 or more OCTETs. 1234 4.2. The Resource Identified by a Request 1236 The exact resource identified by an Internet request is determined by 1237 examining both the request-target and the Host header field. 1239 An origin server that does not allow resources to differ by the 1240 requested host MAY ignore the Host header field value when 1241 determining the resource identified by an HTTP/1.1 request. (But see 1242 Appendix B.1.1 for other requirements on Host support in HTTP/1.1.) 1244 An origin server that does differentiate resources based on the host 1245 requested (sometimes referred to as virtual hosts or vanity host 1246 names) MUST use the following rules for determining the requested 1247 resource on an HTTP/1.1 request: 1249 1. If request-target is an absolute-URI, the host is part of the 1250 request-target. Any Host header field value in the request MUST 1251 be ignored. 1253 2. If the request-target is not an absolute-URI, and the request 1254 includes a Host header field, the host is determined by the Host 1255 header field value. 1257 3. If the host as determined by rule 1 or 2 is not a valid host on 1258 the server, the response MUST be a 400 (Bad Request) error 1259 message. 1261 Recipients of an HTTP/1.0 request that lacks a Host header field MAY 1262 attempt to use heuristics (e.g., examination of the URI path for 1263 something unique to a particular host) in order to determine what 1264 exact resource is being requested. 1266 5. Response 1268 After receiving and interpreting a request message, a server responds 1269 with an HTTP response message. 1271 Response = Status-Line ; Section 5.1 1272 *(( general-header ; Section 3.5 1273 / response-header ; [Part2], Section 5 1274 / entity-header ) CRLF ) ; [Part3], Section 3.1 1275 CRLF 1276 [ message-body ] ; Section 3.3 1278 5.1. Status-Line 1280 The first line of a Response message is the Status-Line, consisting 1281 of the protocol version followed by a numeric status code and its 1282 associated textual phrase, with each element separated by SP 1283 characters. No CR or LF is allowed except in the final CRLF 1284 sequence. 1286 Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF 1288 5.1.1. Status Code and Reason Phrase 1290 The Status-Code element is a 3-digit integer result code of the 1291 attempt to understand and satisfy the request. These codes are fully 1292 defined in Section 8 of [Part2]. The Reason Phrase exists for the 1293 sole purpose of providing a textual description associated with the 1294 numeric status code, out of deference to earlier Internet application 1295 protocols that were more frequently used with interactive text 1296 clients. A client SHOULD ignore the content of the Reason Phrase. 1298 The first digit of the Status-Code defines the class of response. 1299 The last two digits do not have any categorization role. There are 5 1300 values for the first digit: 1302 o 1xx: Informational - Request received, continuing process 1304 o 2xx: Success - The action was successfully received, understood, 1305 and accepted 1307 o 3xx: Redirection - Further action must be taken in order to 1308 complete the request 1310 o 4xx: Client Error - The request contains bad syntax or cannot be 1311 fulfilled 1313 o 5xx: Server Error - The server failed to fulfill an apparently 1314 valid request 1316 Status-Code = 3DIGIT 1317 Reason-Phrase = *( WSP / VCHAR / obs-text ) 1319 6. Protocol Parameters 1321 6.1. Date/Time Formats: Full Date 1323 HTTP applications have historically allowed three different formats 1324 for the representation of date/time stamps: 1326 Sun, 06 Nov 1994 08:49:37 GMT ; RFC 1123 1327 Sunday, 06-Nov-94 08:49:37 GMT ; obsolete RFC 850 format 1328 Sun Nov 6 08:49:37 1994 ; ANSI C's asctime() format 1330 The first format is preferred as an Internet standard and represents 1331 a fixed-length subset of that defined by [RFC1123]. The other 1332 formats are described here only for compatibility with obsolete 1333 implementations. HTTP/1.1 clients and servers that parse the date 1334 value MUST accept all three formats (for compatibility with 1335 HTTP/1.0), though they MUST only generate the RFC 1123 format for 1336 representing HTTP-date values in header fields. See Appendix A for 1337 further information. 1339 All HTTP date/time stamps MUST be represented in Greenwich Mean Time 1340 (GMT), without exception. For the purposes of HTTP, GMT is exactly 1341 equal to UTC (Coordinated Universal Time). This is indicated in the 1342 first two formats by the inclusion of "GMT" as the three-letter 1343 abbreviation for time zone, and MUST be assumed when reading the 1344 asctime format. HTTP-date is case sensitive and MUST NOT include 1345 additional whitespace beyond that specifically included as SP in the 1346 grammar. 1348 HTTP-date = rfc1123-date / obs-date 1350 Preferred format: 1352 rfc1123-date = day-name "," SP date1 SP time-of-day SP GMT 1354 day-name = %x4D.6F.6E ; "Mon", case-sensitive 1355 / %x54.75.65 ; "Tue", case-sensitive 1356 / %x57.65.64 ; "Wed", case-sensitive 1357 / %x54.68.75 ; "Thu", case-sensitive 1358 / %x46.72.69 ; "Fri", case-sensitive 1359 / %x53.61.74 ; "Sat", case-sensitive 1360 / %x53.75.6E ; "Sun", case-sensitive 1362 date1 = day SP month SP year 1363 ; e.g., 02 Jun 1982 1365 day = 2DIGIT 1366 month = %x4A.61.6E ; "Jan", case-sensitive 1367 / %x46.65.62 ; "Feb", case-sensitive 1368 / %x4D.61.72 ; "Mar", case-sensitive 1369 / %x41.70.72 ; "Apr", case-sensitive 1370 / %x4D.61.79 ; "May", case-sensitive 1371 / %x4A.75.6E ; "Jun", case-sensitive 1372 / %x4A.75.6C ; "Jul", case-sensitive 1373 / %x41.75.67 ; "Aug", case-sensitive 1374 / %x53.65.70 ; "Sep", case-sensitive 1375 / %x4F.63.74 ; "Oct", case-sensitive 1376 / %x4E.6F.76 ; "Nov", case-sensitive 1377 / %x44.65.63 ; "Dec", case-sensitive 1378 year = 4DIGIT 1380 GMT = %x47.4D.54 ; "GMT", case-sensitive 1382 time-of-day = hour ":" minute ":" second 1383 ; 00:00:00 - 23:59:59 1385 hour = 2DIGIT 1386 minute = 2DIGIT 1387 second = 2DIGIT 1389 The semantics of day-name, day, month, year, and time-of-day are the 1390 same as those defined for the RFC 5322 constructs with the 1391 corresponding name ([RFC5322], Section 3.3). 1393 Obsolete formats: 1395 obs-date = rfc850-date / asctime-date 1397 rfc850-date = day-name-l "," SP date2 SP time-of-day SP GMT 1398 date2 = day "-" month "-" 2DIGIT 1399 ; day-month-year (e.g., 02-Jun-82) 1401 day-name-l = %x4D.6F.6E.64.61.79 ; "Monday", case-sensitive 1402 / %x54.75.65.73.64.61.79 ; "Tuesday", case-sensitive 1403 / %x57.65.64.6E.65.73.64.61.79 ; "Wednesday", case-sensitive 1404 / %x54.68.75.72.73.64.61.79 ; "Thursday", case-sensitive 1405 / %x46.72.69.64.61.79 ; "Friday", case-sensitive 1406 / %x53.61.74.75.72.64.61.79 ; "Saturday", case-sensitive 1407 / %x53.75.6E.64.61.79 ; "Sunday", case-sensitive 1409 asctime-date = day-name SP date3 SP time-of-day SP year 1410 date3 = month SP ( 2DIGIT / ( SP 1DIGIT )) 1411 ; month day (e.g., Jun 2) 1413 Note: Recipients of date values are encouraged to be robust in 1414 accepting date values that may have been sent by non-HTTP 1415 applications, as is sometimes the case when retrieving or posting 1416 messages via proxies/gateways to SMTP or NNTP. 1418 Note: HTTP requirements for the date/time stamp format apply only 1419 to their usage within the protocol stream. Clients and servers 1420 are not required to use these formats for user presentation, 1421 request logging, etc. 1423 6.2. Transfer Codings 1425 Transfer-coding values are used to indicate an encoding 1426 transformation that has been, can be, or may need to be applied to an 1427 entity-body in order to ensure "safe transport" through the network. 1428 This differs from a content coding in that the transfer-coding is a 1429 property of the message, not of the original entity. 1431 transfer-coding = "chunked" ; Section 6.2.1 1432 / "compress" ; Section 6.2.2.1 1433 / "deflate" ; Section 6.2.2.2 1434 / "gzip" ; Section 6.2.2.3 1435 / transfer-extension 1437 transfer-extension = token *( OWS ";" OWS transfer-parameter ) 1439 Parameters are in the form of attribute/value pairs. 1441 transfer-parameter = attribute BWS "=" BWS value 1442 attribute = token 1443 value = token / quoted-string 1445 All transfer-coding values are case-insensitive. HTTP/1.1 uses 1446 transfer-coding values in the TE header field (Section 9.5) and in 1447 the Transfer-Encoding header field (Section 9.7). 1449 Whenever a transfer-coding is applied to a message-body, the set of 1450 transfer-codings MUST include "chunked", unless the message indicates 1451 it is terminated by closing the connection. When the "chunked" 1452 transfer-coding is used, it MUST be the last transfer-coding applied 1453 to the message-body. The "chunked" transfer-coding MUST NOT be 1454 applied more than once to a message-body. These rules allow the 1455 recipient to determine the transfer-length of the message 1456 (Section 3.4). 1458 Transfer-codings are analogous to the Content-Transfer-Encoding 1459 values of MIME, which were designed to enable safe transport of 1460 binary data over a 7-bit transport service ([RFC2045], Section 6). 1461 However, safe transport has a different focus for an 8bit-clean 1462 transfer protocol. In HTTP, the only unsafe characteristic of 1463 message-bodies is the difficulty in determining the exact body length 1464 (Section 3.4), or the desire to encrypt data over a shared transport. 1466 A server which receives an entity-body with a transfer-coding it does 1467 not understand SHOULD return 501 (Not Implemented), and close the 1468 connection. A server MUST NOT send transfer-codings to an HTTP/1.0 1469 client. 1471 6.2.1. Chunked Transfer Coding 1473 The chunked encoding modifies the body of a message in order to 1474 transfer it as a series of chunks, each with its own size indicator, 1475 followed by an OPTIONAL trailer containing entity-header fields. 1476 This allows dynamically produced content to be transferred along with 1477 the information necessary for the recipient to verify that it has 1478 received the full message. 1480 Chunked-Body = *chunk 1481 last-chunk 1482 trailer-part 1483 CRLF 1485 chunk = chunk-size *WSP [ chunk-ext ] CRLF 1486 chunk-data CRLF 1487 chunk-size = 1*HEXDIG 1488 last-chunk = 1*("0") *WSP [ chunk-ext ] CRLF 1490 chunk-ext = *( ";" *WSP chunk-ext-name 1491 [ "=" chunk-ext-val ] *WSP ) 1492 chunk-ext-name = token 1493 chunk-ext-val = token / quoted-str-nf 1494 chunk-data = 1*OCTET ; a sequence of chunk-size octets 1495 trailer-part = *( entity-header CRLF ) 1497 quoted-str-nf = DQUOTE *( qdtext-nf / quoted-pair ) DQUOTE 1498 ; like quoted-string, but disallowing line folding 1499 qdtext-nf = WSP / %x21 / %x23-5B / %x5D-7E / obs-text 1500 ; WSP / / obs-text 1502 The chunk-size field is a string of hex digits indicating the size of 1503 the chunk-data in octets. The chunked encoding is ended by any chunk 1504 whose size is zero, followed by the trailer, which is terminated by 1505 an empty line. 1507 The trailer allows the sender to include additional HTTP header 1508 fields at the end of the message. The Trailer header field can be 1509 used to indicate which header fields are included in a trailer (see 1510 Section 9.6). 1512 A server using chunked transfer-coding in a response MUST NOT use the 1513 trailer for any header fields unless at least one of the following is 1514 true: 1516 1. the request included a TE header field that indicates "trailers" 1517 is acceptable in the transfer-coding of the response, as 1518 described in Section 9.5; or, 1520 2. the server is the origin server for the response, the trailer 1521 fields consist entirely of optional metadata, and the recipient 1522 could use the message (in a manner acceptable to the origin 1523 server) without receiving this metadata. In other words, the 1524 origin server is willing to accept the possibility that the 1525 trailer fields might be silently discarded along the path to the 1526 client. 1528 This requirement prevents an interoperability failure when the 1529 message is being received by an HTTP/1.1 (or later) proxy and 1530 forwarded to an HTTP/1.0 recipient. It avoids a situation where 1531 compliance with the protocol would have necessitated a possibly 1532 infinite buffer on the proxy. 1534 A process for decoding the "chunked" transfer-coding can be 1535 represented in pseudo-code as: 1537 length := 0 1538 read chunk-size, chunk-ext (if any) and CRLF 1539 while (chunk-size > 0) { 1540 read chunk-data and CRLF 1541 append chunk-data to entity-body 1542 length := length + chunk-size 1543 read chunk-size and CRLF 1544 } 1545 read entity-header 1546 while (entity-header not empty) { 1547 append entity-header to existing header fields 1548 read entity-header 1549 } 1550 Content-Length := length 1551 Remove "chunked" from Transfer-Encoding 1553 All HTTP/1.1 applications MUST be able to receive and decode the 1554 "chunked" transfer-coding, and MUST ignore chunk-ext extensions they 1555 do not understand. 1557 6.2.2. Compression Codings 1559 The codings defined below can be used to compress the payload of a 1560 message. 1562 Note: Use of program names for the identification of encoding 1563 formats is not desirable and is discouraged for future encodings. 1564 Their use here is representative of historical practice, not good 1565 design. 1567 Note: For compatibility with previous implementations of HTTP, 1568 applications SHOULD consider "x-gzip" and "x-compress" to be 1569 equivalent to "gzip" and "compress" respectively. 1571 6.2.2.1. Compress Coding 1573 The "compress" format is produced by the common UNIX file compression 1574 program "compress". This format is an adaptive Lempel-Ziv-Welch 1575 coding (LZW). 1577 6.2.2.2. Deflate Coding 1579 The "zlib" format is defined in [RFC1950] in combination with the 1580 "deflate" compression mechanism described in [RFC1951]. 1582 6.2.2.3. Gzip Coding 1584 The "gzip" format is produced by the file compression program "gzip" 1585 (GNU zip), as described in [RFC1952]. This format is a Lempel-Ziv 1586 coding (LZ77) with a 32 bit CRC. 1588 6.2.3. Transfer Coding Registry 1590 The HTTP Transfer Coding Registry defines the name space for the 1591 transfer coding names. 1593 Registrations MUST include the following fields: 1595 o Name 1597 o Description 1599 o Pointer to specification text 1601 Values to be added to this name space require expert review and a 1602 specification (see "Expert Review" and "Specification Required" in 1603 Section 4.1 of [RFC5226]), and MUST conform to the purpose of 1604 transfer coding defined in this section. 1606 The registry itself is maintained at 1607 . 1609 6.3. Product Tokens 1611 Product tokens are used to allow communicating applications to 1612 identify themselves by software name and version. Most fields using 1613 product tokens also allow sub-products which form a significant part 1614 of the application to be listed, separated by whitespace. By 1615 convention, the products are listed in order of their significance 1616 for identifying the application. 1618 product = token ["/" product-version] 1619 product-version = token 1621 Examples: 1623 User-Agent: CERN-LineMode/2.15 libwww/2.17b3 1624 Server: Apache/0.8.4 1626 Product tokens SHOULD be short and to the point. They MUST NOT be 1627 used for advertising or other non-essential information. Although 1628 any token character MAY appear in a product-version, this token 1629 SHOULD only be used for a version identifier (i.e., successive 1630 versions of the same product SHOULD only differ in the product- 1631 version portion of the product value). 1633 6.4. Quality Values 1635 Both transfer codings (TE request header, Section 9.5) and content 1636 negotiation (Section 4 of [Part3]) use short "floating point" numbers 1637 to indicate the relative importance ("weight") of various negotiable 1638 parameters. A weight is normalized to a real number in the range 0 1639 through 1, where 0 is the minimum and 1 the maximum value. If a 1640 parameter has a quality value of 0, then content with this parameter 1641 is "not acceptable" for the client. HTTP/1.1 applications MUST NOT 1642 generate more than three digits after the decimal point. User 1643 configuration of these values SHOULD also be limited in this fashion. 1645 qvalue = ( "0" [ "." 0*3DIGIT ] ) 1646 / ( "1" [ "." 0*3("0") ] ) 1648 Note: "Quality values" is a misnomer, since these values merely 1649 represent relative degradation in desired quality. 1651 7. Connections 1653 7.1. Persistent Connections 1655 7.1.1. Purpose 1657 Prior to persistent connections, a separate TCP connection was 1658 established to fetch each URL, increasing the load on HTTP servers 1659 and causing congestion on the Internet. The use of inline images and 1660 other associated data often requires a client to make multiple 1661 requests of the same server in a short amount of time. Analysis of 1662 these performance problems and results from a prototype 1663 implementation are available [Pad1995] [Spe]. Implementation 1664 experience and measurements of actual HTTP/1.1 implementations show 1665 good results [Nie1997]. Alternatives have also been explored, for 1666 example, T/TCP [Tou1998]. 1668 Persistent HTTP connections have a number of advantages: 1670 o By opening and closing fewer TCP connections, CPU time is saved in 1671 routers and hosts (clients, servers, proxies, gateways, tunnels, 1672 or caches), and memory used for TCP protocol control blocks can be 1673 saved in hosts. 1675 o HTTP requests and responses can be pipelined on a connection. 1676 Pipelining allows a client to make multiple requests without 1677 waiting for each response, allowing a single TCP connection to be 1678 used much more efficiently, with much lower elapsed time. 1680 o Network congestion is reduced by reducing the number of packets 1681 caused by TCP opens, and by allowing TCP sufficient time to 1682 determine the congestion state of the network. 1684 o Latency on subsequent requests is reduced since there is no time 1685 spent in TCP's connection opening handshake. 1687 o HTTP can evolve more gracefully, since errors can be reported 1688 without the penalty of closing the TCP connection. Clients using 1689 future versions of HTTP might optimistically try a new feature, 1690 but if communicating with an older server, retry with old 1691 semantics after an error is reported. 1693 HTTP implementations SHOULD implement persistent connections. 1695 7.1.2. Overall Operation 1697 A significant difference between HTTP/1.1 and earlier versions of 1698 HTTP is that persistent connections are the default behavior of any 1699 HTTP connection. That is, unless otherwise indicated, the client 1700 SHOULD assume that the server will maintain a persistent connection, 1701 even after error responses from the server. 1703 Persistent connections provide a mechanism by which a client and a 1704 server can signal the close of a TCP connection. This signaling 1705 takes place using the Connection header field (Section 9.1). Once a 1706 close has been signaled, the client MUST NOT send any more requests 1707 on that connection. 1709 7.1.2.1. Negotiation 1711 An HTTP/1.1 server MAY assume that a HTTP/1.1 client intends to 1712 maintain a persistent connection unless a Connection header including 1713 the connection-token "close" was sent in the request. If the server 1714 chooses to close the connection immediately after sending the 1715 response, it SHOULD send a Connection header including the 1716 connection-token "close". 1718 An HTTP/1.1 client MAY expect a connection to remain open, but would 1719 decide to keep it open based on whether the response from a server 1720 contains a Connection header with the connection-token close. In 1721 case the client does not want to maintain a connection for more than 1722 that request, it SHOULD send a Connection header including the 1723 connection-token close. 1725 If either the client or the server sends the close token in the 1726 Connection header, that request becomes the last one for the 1727 connection. 1729 Clients and servers SHOULD NOT assume that a persistent connection is 1730 maintained for HTTP versions less than 1.1 unless it is explicitly 1731 signaled. See Appendix B.2 for more information on backward 1732 compatibility with HTTP/1.0 clients. 1734 In order to remain persistent, all messages on the connection MUST 1735 have a self-defined message length (i.e., one not defined by closure 1736 of the connection), as described in Section 3.4. 1738 7.1.2.2. Pipelining 1740 A client that supports persistent connections MAY "pipeline" its 1741 requests (i.e., send multiple requests without waiting for each 1742 response). A server MUST send its responses to those requests in the 1743 same order that the requests were received. 1745 Clients which assume persistent connections and pipeline immediately 1746 after connection establishment SHOULD be prepared to retry their 1747 connection if the first pipelined attempt fails. If a client does 1748 such a retry, it MUST NOT pipeline before it knows the connection is 1749 persistent. Clients MUST also be prepared to resend their requests 1750 if the server closes the connection before sending all of the 1751 corresponding responses. 1753 Clients SHOULD NOT pipeline requests using non-idempotent methods or 1754 non-idempotent sequences of methods (see Section 7.1.2 of [Part2]). 1755 Otherwise, a premature termination of the transport connection could 1756 lead to indeterminate results. A client wishing to send a non- 1757 idempotent request SHOULD wait to send that request until it has 1758 received the response status for the previous request. 1760 7.1.3. Proxy Servers 1762 It is especially important that proxies correctly implement the 1763 properties of the Connection header field as specified in 1764 Section 9.1. 1766 The proxy server MUST signal persistent connections separately with 1767 its clients and the origin servers (or other proxy servers) that it 1768 connects to. Each persistent connection applies to only one 1769 transport link. 1771 A proxy server MUST NOT establish a HTTP/1.1 persistent connection 1772 with an HTTP/1.0 client (but see Section 19.7.1 of [RFC2068] for 1773 information and discussion of the problems with the Keep-Alive header 1774 implemented by many HTTP/1.0 clients). 1776 7.1.3.1. End-to-end and Hop-by-hop Headers 1778 [[TODO-end-to-end: Restored from . See also 1780 . --jre]] 1782 For the purpose of defining the behavior of caches and non-caching 1783 proxies, we divide HTTP headers into two categories: 1785 o End-to-end headers, which are transmitted to the ultimate 1786 recipient of a request or response. End-to-end headers in 1787 responses MUST be stored as part of a cache entry and MUST be 1788 transmitted in any response formed from a cache entry. 1790 o Hop-by-hop headers, which are meaningful only for a single 1791 transport-level connection, and are not stored by caches or 1792 forwarded by proxies. 1794 The following HTTP/1.1 headers are hop-by-hop headers: 1796 o Connection 1798 o Keep-Alive 1800 o Proxy-Authenticate 1802 o Proxy-Authorization 1804 o TE 1806 o Trailer 1808 o Transfer-Encoding 1810 o Upgrade 1812 All other headers defined by HTTP/1.1 are end-to-end headers. 1814 Other hop-by-hop headers MUST be listed in a Connection header 1815 (Section 9.1). 1817 7.1.3.2. Non-modifiable Headers 1819 [[TODO-non-mod-headers: Restored from . See also 1821 . --jre]] 1823 Some features of HTTP/1.1, such as Digest Authentication, depend on 1824 the value of certain end-to-end headers. A transparent proxy SHOULD 1825 NOT modify an end-to-end header unless the definition of that header 1826 requires or specifically allows that. 1828 A transparent proxy MUST NOT modify any of the following fields in a 1829 request or response, and it MUST NOT add any of these fields if not 1830 already present: 1832 o Content-Location 1834 o Content-MD5 1836 o ETag 1838 o Last-Modified 1840 A transparent proxy MUST NOT modify any of the following fields in a 1841 response: 1843 o Expires 1845 but it MAY add any of these fields if not already present. If an 1846 Expires header is added, it MUST be given a field-value identical to 1847 that of the Date header in that response. 1849 A proxy MUST NOT modify or add any of the following fields in a 1850 message that contains the no-transform cache-control directive, or in 1851 any request: 1853 o Content-Encoding 1855 o Content-Range 1857 o Content-Type 1859 A non-transparent proxy MAY modify or add these fields to a message 1860 that does not include no-transform, but if it does so, it MUST add a 1861 Warning 214 (Transformation applied) if one does not already appear 1862 in the message (see Section 3.6 of [Part6]). 1864 Warning: Unnecessary modification of end-to-end headers might 1865 cause authentication failures if stronger authentication 1866 mechanisms are introduced in later versions of HTTP. Such 1867 authentication mechanisms MAY rely on the values of header fields 1868 not listed here. 1870 The Content-Length field of a request or response is added or deleted 1871 according to the rules in Section 3.4. A transparent proxy MUST 1872 preserve the entity-length (Section 3.2.2 of [Part3]) of the entity- 1873 body, although it MAY change the transfer-length (Section 3.4). 1875 7.1.4. Practical Considerations 1877 Servers will usually have some time-out value beyond which they will 1878 no longer maintain an inactive connection. Proxy servers might make 1879 this a higher value since it is likely that the client will be making 1880 more connections through the same server. The use of persistent 1881 connections places no requirements on the length (or existence) of 1882 this time-out for either the client or the server. 1884 When a client or server wishes to time-out it SHOULD issue a graceful 1885 close on the transport connection. Clients and servers SHOULD both 1886 constantly watch for the other side of the transport close, and 1887 respond to it as appropriate. If a client or server does not detect 1888 the other side's close promptly it could cause unnecessary resource 1889 drain on the network. 1891 A client, server, or proxy MAY close the transport connection at any 1892 time. For example, a client might have started to send a new request 1893 at the same time that the server has decided to close the "idle" 1894 connection. From the server's point of view, the connection is being 1895 closed while it was idle, but from the client's point of view, a 1896 request is in progress. 1898 This means that clients, servers, and proxies MUST be able to recover 1899 from asynchronous close events. Client software SHOULD reopen the 1900 transport connection and retransmit the aborted sequence of requests 1901 without user interaction so long as the request sequence is 1902 idempotent (see Section 7.1.2 of [Part2]). Non-idempotent methods or 1903 sequences MUST NOT be automatically retried, although user agents MAY 1904 offer a human operator the choice of retrying the request(s). 1905 Confirmation by user-agent software with semantic understanding of 1906 the application MAY substitute for user confirmation. The automatic 1907 retry SHOULD NOT be repeated if the second sequence of requests 1908 fails. 1910 Servers SHOULD always respond to at least one request per connection, 1911 if at all possible. Servers SHOULD NOT close a connection in the 1912 middle of transmitting a response, unless a network or client failure 1913 is suspected. 1915 Clients (including proxies) SHOULD limit the number of simultaneous 1916 connections that they maintain to a given server (including proxies). 1918 Previous revisions of HTTP gave a specific number of connections as a 1919 ceiling, but this was found to be impractical for many applications. 1920 As a result, this specification does not mandate a particular maximum 1921 number of connections, but instead encourages clients to be 1922 conservative when opening multiple connections. 1924 In particular, while using multiple connections avoids the "head-of- 1925 line blocking" problem (whereby a request that takes significant 1926 server-side processing and/or has a large payload can block 1927 subsequent requests on the same connection), each connection used 1928 consumes server resources (sometimes significantly), and furthermore 1929 using multiple connections can cause undesirable side effects in 1930 congested networks. 1932 Note that servers might reject traffic that they deem abusive, 1933 including an excessive number of connections from a client. 1935 7.2. Message Transmission Requirements 1937 7.2.1. Persistent Connections and Flow Control 1939 HTTP/1.1 servers SHOULD maintain persistent connections and use TCP's 1940 flow control mechanisms to resolve temporary overloads, rather than 1941 terminating connections with the expectation that clients will retry. 1942 The latter technique can exacerbate network congestion. 1944 7.2.2. Monitoring Connections for Error Status Messages 1946 An HTTP/1.1 (or later) client sending a message-body SHOULD monitor 1947 the network connection for an error status while it is transmitting 1948 the request. If the client sees an error status, it SHOULD 1949 immediately cease transmitting the body. If the body is being sent 1950 using a "chunked" encoding (Section 6.2), a zero length chunk and 1951 empty trailer MAY be used to prematurely mark the end of the message. 1952 If the body was preceded by a Content-Length header, the client MUST 1953 close the connection. 1955 7.2.3. Use of the 100 (Continue) Status 1957 The purpose of the 100 (Continue) status (see Section 8.1.1 of 1958 [Part2]) is to allow a client that is sending a request message with 1959 a request body to determine if the origin server is willing to accept 1960 the request (based on the request headers) before the client sends 1961 the request body. In some cases, it might either be inappropriate or 1962 highly inefficient for the client to send the body if the server will 1963 reject the message without looking at the body. 1965 Requirements for HTTP/1.1 clients: 1967 o If a client will wait for a 100 (Continue) response before sending 1968 the request body, it MUST send an Expect request-header field 1969 (Section 9.2 of [Part2]) with the "100-continue" expectation. 1971 o A client MUST NOT send an Expect request-header field (Section 9.2 1972 of [Part2]) with the "100-continue" expectation if it does not 1973 intend to send a request body. 1975 Because of the presence of older implementations, the protocol allows 1976 ambiguous situations in which a client may send "Expect: 100- 1977 continue" without receiving either a 417 (Expectation Failed) status 1978 or a 100 (Continue) status. Therefore, when a client sends this 1979 header field to an origin server (possibly via a proxy) from which it 1980 has never seen a 100 (Continue) status, the client SHOULD NOT wait 1981 for an indefinite period before sending the request body. 1983 Requirements for HTTP/1.1 origin servers: 1985 o Upon receiving a request which includes an Expect request-header 1986 field with the "100-continue" expectation, an origin server MUST 1987 either respond with 100 (Continue) status and continue to read 1988 from the input stream, or respond with a final status code. The 1989 origin server MUST NOT wait for the request body before sending 1990 the 100 (Continue) response. If it responds with a final status 1991 code, it MAY close the transport connection or it MAY continue to 1992 read and discard the rest of the request. It MUST NOT perform the 1993 requested method if it returns a final status code. 1995 o An origin server SHOULD NOT send a 100 (Continue) response if the 1996 request message does not include an Expect request-header field 1997 with the "100-continue" expectation, and MUST NOT send a 100 1998 (Continue) response if such a request comes from an HTTP/1.0 (or 1999 earlier) client. There is an exception to this rule: for 2000 compatibility with [RFC2068], a server MAY send a 100 (Continue) 2001 status in response to an HTTP/1.1 PUT or POST request that does 2002 not include an Expect request-header field with the "100-continue" 2003 expectation. This exception, the purpose of which is to minimize 2004 any client processing delays associated with an undeclared wait 2005 for 100 (Continue) status, applies only to HTTP/1.1 requests, and 2006 not to requests with any other HTTP-version value. 2008 o An origin server MAY omit a 100 (Continue) response if it has 2009 already received some or all of the request body for the 2010 corresponding request. 2012 o An origin server that sends a 100 (Continue) response MUST 2013 ultimately send a final status code, once the request body is 2014 received and processed, unless it terminates the transport 2015 connection prematurely. 2017 o If an origin server receives a request that does not include an 2018 Expect request-header field with the "100-continue" expectation, 2019 the request includes a request body, and the server responds with 2020 a final status code before reading the entire request body from 2021 the transport connection, then the server SHOULD NOT close the 2022 transport connection until it has read the entire request, or 2023 until the client closes the connection. Otherwise, the client 2024 might not reliably receive the response message. However, this 2025 requirement is not be construed as preventing a server from 2026 defending itself against denial-of-service attacks, or from badly 2027 broken client implementations. 2029 Requirements for HTTP/1.1 proxies: 2031 o If a proxy receives a request that includes an Expect request- 2032 header field with the "100-continue" expectation, and the proxy 2033 either knows that the next-hop server complies with HTTP/1.1 or 2034 higher, or does not know the HTTP version of the next-hop server, 2035 it MUST forward the request, including the Expect header field. 2037 o If the proxy knows that the version of the next-hop server is 2038 HTTP/1.0 or lower, it MUST NOT forward the request, and it MUST 2039 respond with a 417 (Expectation Failed) status. 2041 o Proxies SHOULD maintain a cache recording the HTTP version numbers 2042 received from recently-referenced next-hop servers. 2044 o A proxy MUST NOT forward a 100 (Continue) response if the request 2045 message was received from an HTTP/1.0 (or earlier) client and did 2046 not include an Expect request-header field with the "100-continue" 2047 expectation. This requirement overrides the general rule for 2048 forwarding of 1xx responses (see Section 8.1 of [Part2]). 2050 7.2.4. Client Behavior if Server Prematurely Closes Connection 2052 If an HTTP/1.1 client sends a request which includes a request body, 2053 but which does not include an Expect request-header field with the 2054 "100-continue" expectation, and if the client is not directly 2055 connected to an HTTP/1.1 origin server, and if the client sees the 2056 connection close before receiving any status from the server, the 2057 client SHOULD retry the request. If the client does retry this 2058 request, it MAY use the following "binary exponential backoff" 2059 algorithm to be assured of obtaining a reliable response: 2061 1. Initiate a new connection to the server 2063 2. Transmit the request-headers 2065 3. Initialize a variable R to the estimated round-trip time to the 2066 server (e.g., based on the time it took to establish the 2067 connection), or to a constant value of 5 seconds if the round- 2068 trip time is not available. 2070 4. Compute T = R * (2**N), where N is the number of previous retries 2071 of this request. 2073 5. Wait either for an error response from the server, or for T 2074 seconds (whichever comes first) 2076 6. If no error response is received, after T seconds transmit the 2077 body of the request. 2079 7. If client sees that the connection is closed prematurely, repeat 2080 from step 1 until the request is accepted, an error response is 2081 received, or the user becomes impatient and terminates the retry 2082 process. 2084 If at any point an error status is received, the client 2086 o SHOULD NOT continue and 2088 o SHOULD close the connection if it has not completed sending the 2089 request message. 2091 8. Miscellaneous notes that may disappear 2093 8.1. Scheme aliases considered harmful 2095 [[TBD-aliases-harmful: describe why aliases like webcal are 2096 harmful.]] 2098 8.2. Use of HTTP for proxy communication 2100 [[TBD-proxy-other: Configured to use HTTP to proxy HTTP or other 2101 protocols.]] 2103 8.3. Interception of HTTP for access control 2105 [[TBD-intercept: Interception of HTTP traffic for initiating access 2106 control.]] 2108 8.4. Use of HTTP by other protocols 2110 [[TBD-profiles: Profiles of HTTP defined by other protocol. 2111 Extensions of HTTP like WebDAV.]] 2113 8.5. Use of HTTP by media type specification 2115 [[TBD-hypertext: Instructions on composing HTTP requests via 2116 hypertext formats.]] 2118 9. Header Field Definitions 2120 This section defines the syntax and semantics of HTTP/1.1 header 2121 fields related to message framing and transport protocols. 2123 For entity-header fields, both sender and recipient refer to either 2124 the client or the server, depending on who sends and who receives the 2125 entity. 2127 9.1. Connection 2129 The "Connection" general-header field allows the sender to specify 2130 options that are desired for that particular connection and MUST NOT 2131 be communicated by proxies over further connections. 2133 The Connection header's value has the following grammar: 2135 Connection = "Connection" ":" OWS Connection-v 2136 Connection-v = 1#connection-token 2137 connection-token = token 2139 HTTP/1.1 proxies MUST parse the Connection header field before a 2140 message is forwarded and, for each connection-token in this field, 2141 remove any header field(s) from the message with the same name as the 2142 connection-token. Connection options are signaled by the presence of 2143 a connection-token in the Connection header field, not by any 2144 corresponding additional header field(s), since the additional header 2145 field may not be sent if there are no parameters associated with that 2146 connection option. 2148 Message headers listed in the Connection header MUST NOT include end- 2149 to-end headers, such as Cache-Control. 2151 HTTP/1.1 defines the "close" connection option for the sender to 2152 signal that the connection will be closed after completion of the 2153 response. For example, 2155 Connection: close 2157 in either the request or the response header fields indicates that 2158 the connection SHOULD NOT be considered "persistent" (Section 7.1) 2159 after the current request/response is complete. 2161 An HTTP/1.1 client that does not support persistent connections MUST 2162 include the "close" connection option in every request message. 2164 An HTTP/1.1 server that does not support persistent connections MUST 2165 include the "close" connection option in every response message that 2166 does not have a 1xx (Informational) status code. 2168 A system receiving an HTTP/1.0 (or lower-version) message that 2169 includes a Connection header MUST, for each connection-token in this 2170 field, remove and ignore any header field(s) from the message with 2171 the same name as the connection-token. This protects against 2172 mistaken forwarding of such header fields by pre-HTTP/1.1 proxies. 2173 See Appendix B.2. 2175 9.2. Content-Length 2177 The "Content-Length" entity-header field indicates the size of the 2178 entity-body, in number of OCTETs. In the case of responses to the 2179 HEAD method, it indicates the size of the entity-body that would have 2180 been sent had the request been a GET. 2182 Content-Length = "Content-Length" ":" OWS 1*Content-Length-v 2183 Content-Length-v = 1*DIGIT 2185 An example is 2187 Content-Length: 3495 2189 Applications SHOULD use this field to indicate the transfer-length of 2190 the message-body, unless this is prohibited by the rules in 2191 Section 3.4. 2193 Any Content-Length greater than or equal to zero is a valid value. 2194 Section 3.4 describes how to determine the length of a message-body 2195 if a Content-Length is not given. 2197 Note that the meaning of this field is significantly different from 2198 the corresponding definition in MIME, where it is an optional field 2199 used within the "message/external-body" content-type. In HTTP, it 2200 SHOULD be sent whenever the message's length can be determined prior 2201 to being transferred, unless this is prohibited by the rules in 2202 Section 3.4. 2204 9.3. Date 2206 The "Date" general-header field represents the date and time at which 2207 the message was originated, having the same semantics as the 2208 Origination Date Field (orig-date) defined in Section 3.6.1 of 2209 [RFC5322]. The field value is an HTTP-date, as described in 2210 Section 6.1; it MUST be sent in rfc1123-date format. 2212 Date = "Date" ":" OWS Date-v 2213 Date-v = HTTP-date 2215 An example is 2217 Date: Tue, 15 Nov 1994 08:12:31 GMT 2219 Origin servers MUST include a Date header field in all responses, 2220 except in these cases: 2222 1. If the response status code is 100 (Continue) or 101 (Switching 2223 Protocols), the response MAY include a Date header field, at the 2224 server's option. 2226 2. If the response status code conveys a server error, e.g., 500 2227 (Internal Server Error) or 503 (Service Unavailable), and it is 2228 inconvenient or impossible to generate a valid Date. 2230 3. If the server does not have a clock that can provide a reasonable 2231 approximation of the current time, its responses MUST NOT include 2232 a Date header field. In this case, the rules in Section 9.3.1 2233 MUST be followed. 2235 A received message that does not have a Date header field MUST be 2236 assigned one by the recipient if the message will be cached by that 2237 recipient or gatewayed via a protocol which requires a Date. An HTTP 2238 implementation without a clock MUST NOT cache responses without 2239 revalidating them on every use. An HTTP cache, especially a shared 2240 cache, SHOULD use a mechanism, such as NTP [RFC1305], to synchronize 2241 its clock with a reliable external standard. 2243 Clients SHOULD only send a Date header field in messages that include 2244 an entity-body, as in the case of the PUT and POST requests, and even 2245 then it is optional. A client without a clock MUST NOT send a Date 2246 header field in a request. 2248 The HTTP-date sent in a Date header SHOULD NOT represent a date and 2249 time subsequent to the generation of the message. It SHOULD 2250 represent the best available approximation of the date and time of 2251 message generation, unless the implementation has no means of 2252 generating a reasonably accurate date and time. In theory, the date 2253 ought to represent the moment just before the entity is generated. 2254 In practice, the date can be generated at any time during the message 2255 origination without affecting its semantic value. 2257 9.3.1. Clockless Origin Server Operation 2259 Some origin server implementations might not have a clock available. 2260 An origin server without a clock MUST NOT assign Expires or Last- 2261 Modified values to a response, unless these values were associated 2262 with the resource by a system or user with a reliable clock. It MAY 2263 assign an Expires value that is known, at or before server 2264 configuration time, to be in the past (this allows "pre-expiration" 2265 of responses without storing separate Expires values for each 2266 resource). 2268 9.4. Host 2270 The "Host" request-header field specifies the Internet host and port 2271 number of the resource being requested, allowing the origin server or 2272 gateway to differentiate between internally-ambiguous URLs, such as 2273 the root "/" URL of a server for multiple host names on a single IP 2274 address. 2276 The Host field value MUST represent the naming authority of the 2277 origin server or gateway given by the original URL obtained from the 2278 user or referring resource (generally an http URI, as described in 2279 Section 2.6.1). 2281 Host = "Host" ":" OWS Host-v 2282 Host-v = uri-host [ ":" port ] ; Section 2.6.1 2284 A "host" without any trailing port information implies the default 2285 port for the service requested (e.g., "80" for an HTTP URL). For 2286 example, a request on the origin server for 2287 would properly include: 2289 GET /pub/WWW/ HTTP/1.1 2290 Host: www.example.org 2292 A client MUST include a Host header field in all HTTP/1.1 request 2293 messages. If the requested URI does not include an Internet host 2294 name for the service being requested, then the Host header field MUST 2295 be given with an empty value. An HTTP/1.1 proxy MUST ensure that any 2296 request message it forwards does contain an appropriate Host header 2297 field that identifies the service being requested by the proxy. All 2298 Internet-based HTTP/1.1 servers MUST respond with a 400 (Bad Request) 2299 status code to any HTTP/1.1 request message which lacks a Host header 2300 field. 2302 See Sections 4.2 and B.1.1 for other requirements relating to Host. 2304 9.5. TE 2306 The "TE" request-header field indicates what extension transfer- 2307 codings it is willing to accept in the response, and whether or not 2308 it is willing to accept trailer fields in a chunked transfer-coding. 2310 Its value may consist of the keyword "trailers" and/or a comma- 2311 separated list of extension transfer-coding names with optional 2312 accept parameters (as described in Section 6.2). 2314 TE = "TE" ":" OWS TE-v 2315 TE-v = #t-codings 2316 t-codings = "trailers" / ( transfer-extension [ te-params ] ) 2317 te-params = OWS ";" OWS "q=" qvalue *( te-ext ) 2318 te-ext = OWS ";" OWS token [ "=" ( token / quoted-string ) ] 2320 The presence of the keyword "trailers" indicates that the client is 2321 willing to accept trailer fields in a chunked transfer-coding, as 2322 defined in Section 6.2.1. This keyword is reserved for use with 2323 transfer-coding values even though it does not itself represent a 2324 transfer-coding. 2326 Examples of its use are: 2328 TE: deflate 2329 TE: 2330 TE: trailers, deflate;q=0.5 2332 The TE header field only applies to the immediate connection. 2333 Therefore, the keyword MUST be supplied within a Connection header 2334 field (Section 9.1) whenever TE is present in an HTTP/1.1 message. 2336 A server tests whether a transfer-coding is acceptable, according to 2337 a TE field, using these rules: 2339 1. The "chunked" transfer-coding is always acceptable. If the 2340 keyword "trailers" is listed, the client indicates that it is 2341 willing to accept trailer fields in the chunked response on 2342 behalf of itself and any downstream clients. The implication is 2343 that, if given, the client is stating that either all downstream 2344 clients are willing to accept trailer fields in the forwarded 2345 response, or that it will attempt to buffer the response on 2346 behalf of downstream recipients. 2348 Note: HTTP/1.1 does not define any means to limit the size of a 2349 chunked response such that a client can be assured of buffering 2350 the entire response. 2352 2. If the transfer-coding being tested is one of the transfer- 2353 codings listed in the TE field, then it is acceptable unless it 2354 is accompanied by a qvalue of 0. (As defined in Section 6.4, a 2355 qvalue of 0 means "not acceptable.") 2357 3. If multiple transfer-codings are acceptable, then the acceptable 2358 transfer-coding with the highest non-zero qvalue is preferred. 2359 The "chunked" transfer-coding always has a qvalue of 1. 2361 If the TE field-value is empty or if no TE field is present, the only 2362 transfer-coding is "chunked". A message with no transfer-coding is 2363 always acceptable. 2365 9.6. Trailer 2367 The "Trailer" general-header field indicates that the given set of 2368 header fields is present in the trailer of a message encoded with 2369 chunked transfer-coding. 2371 Trailer = "Trailer" ":" OWS Trailer-v 2372 Trailer-v = 1#field-name 2374 An HTTP/1.1 message SHOULD include a Trailer header field in a 2375 message using chunked transfer-coding with a non-empty trailer. 2376 Doing so allows the recipient to know which header fields to expect 2377 in the trailer. 2379 If no Trailer header field is present, the trailer SHOULD NOT include 2380 any header fields. See Section 6.2.1 for restrictions on the use of 2381 trailer fields in a "chunked" transfer-coding. 2383 Message header fields listed in the Trailer header field MUST NOT 2384 include the following header fields: 2386 o Transfer-Encoding 2388 o Content-Length 2390 o Trailer 2392 9.7. Transfer-Encoding 2394 The "Transfer-Encoding" general-header field indicates what transfer- 2395 codings (if any) have been applied to the message body. It differs 2396 from Content-Encoding (Section 2.2 of [Part3]) in that transfer- 2397 codings are a property of the message (and therefore are removed by 2398 intermediaries), whereas content-codings are not. 2400 Transfer-Encoding = "Transfer-Encoding" ":" OWS 2401 Transfer-Encoding-v 2402 Transfer-Encoding-v = 1#transfer-coding 2404 Transfer-codings are defined in Section 6.2. An example is: 2406 Transfer-Encoding: chunked 2408 If multiple encodings have been applied to an entity, the transfer- 2409 codings MUST be listed in the order in which they were applied. 2410 Additional information about the encoding parameters MAY be provided 2411 by other entity-header fields not defined by this specification. 2413 Many older HTTP/1.0 applications do not understand the Transfer- 2414 Encoding header. 2416 9.8. Upgrade 2418 The "Upgrade" general-header field allows the client to specify what 2419 additional communication protocols it would like to use, if the 2420 server chooses to switch protocols. Additionally, the server MUST 2421 use the Upgrade header field within a 101 (Switching Protocols) 2422 response to indicate which protocol(s) are being switched to. 2424 Upgrade = "Upgrade" ":" OWS Upgrade-v 2425 Upgrade-v = 1#product 2427 For example, 2429 Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11 2431 The Upgrade header field is intended to provide a simple mechanism 2432 for transition from HTTP/1.1 to some other, incompatible protocol. 2433 It does so by allowing the client to advertise its desire to use 2434 another protocol, such as a later version of HTTP with a higher major 2435 version number, even though the current request has been made using 2436 HTTP/1.1. This eases the difficult transition between incompatible 2437 protocols by allowing the client to initiate a request in the more 2438 commonly supported protocol while indicating to the server that it 2439 would like to use a "better" protocol if available (where "better" is 2440 determined by the server, possibly according to the nature of the 2441 method and/or resource being requested). 2443 The Upgrade header field only applies to switching application-layer 2444 protocols upon the existing transport-layer connection. Upgrade 2445 cannot be used to insist on a protocol change; its acceptance and use 2446 by the server is optional. The capabilities and nature of the 2447 application-layer communication after the protocol change is entirely 2448 dependent upon the new protocol chosen, although the first action 2449 after changing the protocol MUST be a response to the initial HTTP 2450 request containing the Upgrade header field. 2452 The Upgrade header field only applies to the immediate connection. 2453 Therefore, the upgrade keyword MUST be supplied within a Connection 2454 header field (Section 9.1) whenever Upgrade is present in an HTTP/1.1 2455 message. 2457 The Upgrade header field cannot be used to indicate a switch to a 2458 protocol on a different connection. For that purpose, it is more 2459 appropriate to use a 301, 302, 303, or 305 redirection response. 2461 This specification only defines the protocol name "HTTP" for use by 2462 the family of Hypertext Transfer Protocols, as defined by the HTTP 2463 version rules of Section 2.5 and future updates to this 2464 specification. Additional tokens can be registered with IANA using 2465 the registration procedure defined below. 2467 9.8.1. Upgrade Token Registry 2469 The HTTP Upgrade Token Registry defines the name space for product 2470 tokens used to identify protocols in the Upgrade header field. Each 2471 registered token should be associated with one or a set of 2472 specifications, and with contact information. 2474 Registrations should be allowed on a First Come First Served basis as 2475 described in Section 4.1 of [RFC5226]. These specifications need not 2476 be IETF documents or be subject to IESG review, but should obey the 2477 following rules: 2479 1. A token, once registered, stays registered forever. 2481 2. The registration MUST name a responsible party for the 2482 registration. 2484 3. The registration MUST name a point of contact. 2486 4. The registration MAY name the documentation required for the 2487 token. 2489 5. The responsible party MAY change the registration at any time. 2490 The IANA will keep a record of all such changes, and make them 2491 available upon request. 2493 6. The responsible party for the first registration of a "product" 2494 token MUST approve later registrations of a "version" token 2495 together with that "product" token before they can be registered. 2497 7. If absolutely required, the IESG MAY reassign the responsibility 2498 for a token. This will normally only be used in the case when a 2499 responsible party cannot be contacted. 2501 It is not required that specifications for upgrade tokens be made 2502 publicly available, but the contact information for the registration 2503 should be. 2505 9.9. Via 2507 The "Via" general-header field MUST be used by gateways and proxies 2508 to indicate the intermediate protocols and recipients between the 2509 user agent and the server on requests, and between the origin server 2510 and the client on responses. It is analogous to the "Received" field 2511 defined in Section 3.6.7 of [RFC5322] and is intended to be used for 2512 tracking message forwards, avoiding request loops, and identifying 2513 the protocol capabilities of all senders along the request/response 2514 chain. 2516 Via = "Via" ":" OWS Via-v 2517 Via-v = 1#( received-protocol RWS received-by 2518 [ RWS comment ] ) 2519 received-protocol = [ protocol-name "/" ] protocol-version 2520 protocol-name = token 2521 protocol-version = token 2522 received-by = ( uri-host [ ":" port ] ) / pseudonym 2523 pseudonym = token 2525 The received-protocol indicates the protocol version of the message 2526 received by the server or client along each segment of the request/ 2527 response chain. The received-protocol version is appended to the Via 2528 field value when the message is forwarded so that information about 2529 the protocol capabilities of upstream applications remains visible to 2530 all recipients. 2532 The protocol-name is optional if and only if it would be "HTTP". The 2533 received-by field is normally the host and optional port number of a 2534 recipient server or client that subsequently forwarded the message. 2535 However, if the real host is considered to be sensitive information, 2536 it MAY be replaced by a pseudonym. If the port is not given, it MAY 2537 be assumed to be the default port of the received-protocol. 2539 Multiple Via field values represent each proxy or gateway that has 2540 forwarded the message. Each recipient MUST append its information 2541 such that the end result is ordered according to the sequence of 2542 forwarding applications. 2544 Comments MAY be used in the Via header field to identify the software 2545 of the recipient proxy or gateway, analogous to the User-Agent and 2546 Server header fields. However, all comments in the Via field are 2547 optional and MAY be removed by any recipient prior to forwarding the 2548 message. 2550 For example, a request message could be sent from an HTTP/1.0 user 2551 agent to an internal proxy code-named "fred", which uses HTTP/1.1 to 2552 forward the request to a public proxy at p.example.net, which 2553 completes the request by forwarding it to the origin server at 2554 www.example.com. The request received by www.example.com would then 2555 have the following Via header field: 2557 Via: 1.0 fred, 1.1 p.example.net (Apache/1.1) 2559 Proxies and gateways used as a portal through a network firewall 2560 SHOULD NOT, by default, forward the names and ports of hosts within 2561 the firewall region. This information SHOULD only be propagated if 2562 explicitly enabled. If not enabled, the received-by host of any host 2563 behind the firewall SHOULD be replaced by an appropriate pseudonym 2564 for that host. 2566 For organizations that have strong privacy requirements for hiding 2567 internal structures, a proxy MAY combine an ordered subsequence of 2568 Via header field entries with identical received-protocol values into 2569 a single such entry. For example, 2571 Via: 1.0 ricky, 1.1 ethel, 1.1 fred, 1.0 lucy 2573 could be collapsed to 2575 Via: 1.0 ricky, 1.1 mertz, 1.0 lucy 2577 Applications SHOULD NOT combine multiple entries unless they are all 2578 under the same organizational control and the hosts have already been 2579 replaced by pseudonyms. Applications MUST NOT combine entries which 2580 have different received-protocol values. 2582 10. IANA Considerations 2584 10.1. Message Header Registration 2586 The Message Header Registry located at should be 2588 updated with the permanent registrations below (see [RFC3864]): 2590 +-------------------+----------+----------+-------------+ 2591 | Header Field Name | Protocol | Status | Reference | 2592 +-------------------+----------+----------+-------------+ 2593 | Connection | http | standard | Section 9.1 | 2594 | Content-Length | http | standard | Section 9.2 | 2595 | Date | http | standard | Section 9.3 | 2596 | Host | http | standard | Section 9.4 | 2597 | TE | http | standard | Section 9.5 | 2598 | Trailer | http | standard | Section 9.6 | 2599 | Transfer-Encoding | http | standard | Section 9.7 | 2600 | Upgrade | http | standard | Section 9.8 | 2601 | Via | http | standard | Section 9.9 | 2602 +-------------------+----------+----------+-------------+ 2604 The change controller is: "IETF (iesg@ietf.org) - Internet 2605 Engineering Task Force". 2607 10.2. URI Scheme Registration 2609 The entries for the "http" and "https" URI Schemes in the registry 2610 located at should 2611 be updated to point to Sections 2.6.1 and 2.6.2 of this document (see 2612 [RFC4395]). 2614 10.3. Internet Media Type Registrations 2616 This document serves as the specification for the Internet media 2617 types "message/http" and "application/http". The following is to be 2618 registered with IANA (see [RFC4288]). 2620 10.3.1. Internet Media Type message/http 2622 The message/http type can be used to enclose a single HTTP request or 2623 response message, provided that it obeys the MIME restrictions for 2624 all "message" types regarding line length and encodings. 2626 Type name: message 2628 Subtype name: http 2630 Required parameters: none 2632 Optional parameters: version, msgtype 2634 version: The HTTP-Version number of the enclosed message (e.g., 2635 "1.1"). If not present, the version can be determined from the 2636 first line of the body. 2638 msgtype: The message type -- "request" or "response". If not 2639 present, the type can be determined from the first line of the 2640 body. 2642 Encoding considerations: only "7bit", "8bit", or "binary" are 2643 permitted 2645 Security considerations: none 2647 Interoperability considerations: none 2649 Published specification: This specification (see Section 10.3.1). 2651 Applications that use this media type: 2653 Additional information: 2655 Magic number(s): none 2657 File extension(s): none 2659 Macintosh file type code(s): none 2661 Person and email address to contact for further information: See 2662 Authors Section. 2664 Intended usage: COMMON 2666 Restrictions on usage: none 2668 Author/Change controller: IESG 2670 10.3.2. Internet Media Type application/http 2672 The application/http type can be used to enclose a pipeline of one or 2673 more HTTP request or response messages (not intermixed). 2675 Type name: application 2677 Subtype name: http 2679 Required parameters: none 2681 Optional parameters: version, msgtype 2683 version: The HTTP-Version number of the enclosed messages (e.g., 2684 "1.1"). If not present, the version can be determined from the 2685 first line of the body. 2687 msgtype: The message type -- "request" or "response". If not 2688 present, the type can be determined from the first line of the 2689 body. 2691 Encoding considerations: HTTP messages enclosed by this type are in 2692 "binary" format; use of an appropriate Content-Transfer-Encoding 2693 is required when transmitted via E-mail. 2695 Security considerations: none 2697 Interoperability considerations: none 2699 Published specification: This specification (see Section 10.3.2). 2701 Applications that use this media type: 2703 Additional information: 2705 Magic number(s): none 2707 File extension(s): none 2709 Macintosh file type code(s): none 2711 Person and email address to contact for further information: See 2712 Authors Section. 2714 Intended usage: COMMON 2715 Restrictions on usage: none 2717 Author/Change controller: IESG 2719 10.4. Transfer Coding Registry 2721 The registration procedure for HTTP Transfer Codings is now defined 2722 by Section 6.2.3 of this document. 2724 The HTTP Transfer Codings Registry located at 2725 should be updated 2726 with the registrations below: 2728 +----------+--------------------------------------+-----------------+ 2729 | Name | Description | Reference | 2730 +----------+--------------------------------------+-----------------+ 2731 | chunked | Transfer in a series of chunks | Section 6.2.1 | 2732 | compress | UNIX "compress" program method | Section 6.2.2.1 | 2733 | deflate | "zlib" format [RFC1950] with | Section 6.2.2.2 | 2734 | | "deflate" compression | | 2735 | gzip | Same as GNU zip [RFC1952] | Section 6.2.2.3 | 2736 +----------+--------------------------------------+-----------------+ 2738 10.5. Upgrade Token Registration 2740 The registration procedure for HTTP Upgrade Tokens -- previously 2741 defined in Section 7.2 of [RFC2817] -- is now defined by 2742 Section 9.8.1 of this document. 2744 The HTTP Status Code Registry located at 2745 should be 2746 updated with the registration below: 2748 +-------+---------------------------+-------------------------------+ 2749 | Value | Description | Reference | 2750 +-------+---------------------------+-------------------------------+ 2751 | HTTP | Hypertext Transfer | Section 2.5 of this | 2752 | | Protocol | specification | 2753 +-------+---------------------------+-------------------------------+ 2755 11. Security Considerations 2757 This section is meant to inform application developers, information 2758 providers, and users of the security limitations in HTTP/1.1 as 2759 described by this document. The discussion does not include 2760 definitive solutions to the problems revealed, though it does make 2761 some suggestions for reducing security risks. 2763 11.1. Personal Information 2765 HTTP clients are often privy to large amounts of personal information 2766 (e.g., the user's name, location, mail address, passwords, encryption 2767 keys, etc.), and SHOULD be very careful to prevent unintentional 2768 leakage of this information. We very strongly recommend that a 2769 convenient interface be provided for the user to control 2770 dissemination of such information, and that designers and 2771 implementors be particularly careful in this area. History shows 2772 that errors in this area often create serious security and/or privacy 2773 problems and generate highly adverse publicity for the implementor's 2774 company. 2776 11.2. Abuse of Server Log Information 2778 A server is in the position to save personal data about a user's 2779 requests which might identify their reading patterns or subjects of 2780 interest. This information is clearly confidential in nature and its 2781 handling can be constrained by law in certain countries. People 2782 using HTTP to provide data are responsible for ensuring that such 2783 material is not distributed without the permission of any individuals 2784 that are identifiable by the published results. 2786 11.3. Attacks Based On File and Path Names 2788 Implementations of HTTP origin servers SHOULD be careful to restrict 2789 the documents returned by HTTP requests to be only those that were 2790 intended by the server administrators. If an HTTP server translates 2791 HTTP URIs directly into file system calls, the server MUST take 2792 special care not to serve files that were not intended to be 2793 delivered to HTTP clients. For example, UNIX, Microsoft Windows, and 2794 other operating systems use ".." as a path component to indicate a 2795 directory level above the current one. On such a system, an HTTP 2796 server MUST disallow any such construct in the request-target if it 2797 would otherwise allow access to a resource outside those intended to 2798 be accessible via the HTTP server. Similarly, files intended for 2799 reference only internally to the server (such as access control 2800 files, configuration files, and script code) MUST be protected from 2801 inappropriate retrieval, since they might contain sensitive 2802 information. Experience has shown that minor bugs in such HTTP 2803 server implementations have turned into security risks. 2805 11.4. DNS Spoofing 2807 Clients using HTTP rely heavily on the Domain Name Service, and are 2808 thus generally prone to security attacks based on the deliberate mis- 2809 association of IP addresses and DNS names. Clients need to be 2810 cautious in assuming the continuing validity of an IP number/DNS name 2811 association. 2813 In particular, HTTP clients SHOULD rely on their name resolver for 2814 confirmation of an IP number/DNS name association, rather than 2815 caching the result of previous host name lookups. Many platforms 2816 already can cache host name lookups locally when appropriate, and 2817 they SHOULD be configured to do so. It is proper for these lookups 2818 to be cached, however, only when the TTL (Time To Live) information 2819 reported by the name server makes it likely that the cached 2820 information will remain useful. 2822 If HTTP clients cache the results of host name lookups in order to 2823 achieve a performance improvement, they MUST observe the TTL 2824 information reported by DNS. 2826 If HTTP clients do not observe this rule, they could be spoofed when 2827 a previously-accessed server's IP address changes. As network 2828 renumbering is expected to become increasingly common [RFC1900], the 2829 possibility of this form of attack will grow. Observing this 2830 requirement thus reduces this potential security vulnerability. 2832 This requirement also improves the load-balancing behavior of clients 2833 for replicated servers using the same DNS name and reduces the 2834 likelihood of a user's experiencing failure in accessing sites which 2835 use that strategy. 2837 11.5. Proxies and Caching 2839 By their very nature, HTTP proxies are men-in-the-middle, and 2840 represent an opportunity for man-in-the-middle attacks. Compromise 2841 of the systems on which the proxies run can result in serious 2842 security and privacy problems. Proxies have access to security- 2843 related information, personal information about individual users and 2844 organizations, and proprietary information belonging to users and 2845 content providers. A compromised proxy, or a proxy implemented or 2846 configured without regard to security and privacy considerations, 2847 might be used in the commission of a wide range of potential attacks. 2849 Proxy operators should protect the systems on which proxies run as 2850 they would protect any system that contains or transports sensitive 2851 information. In particular, log information gathered at proxies 2852 often contains highly sensitive personal information, and/or 2853 information about organizations. Log information should be carefully 2854 guarded, and appropriate guidelines for use should be developed and 2855 followed. (Section 11.2). 2857 Proxy implementors should consider the privacy and security 2858 implications of their design and coding decisions, and of the 2859 configuration options they provide to proxy operators (especially the 2860 default configuration). 2862 Users of a proxy need to be aware that proxies are no trustworthier 2863 than the people who run them; HTTP itself cannot solve this problem. 2865 The judicious use of cryptography, when appropriate, may suffice to 2866 protect against a broad range of security and privacy attacks. Such 2867 cryptography is beyond the scope of the HTTP/1.1 specification. 2869 11.6. Denial of Service Attacks on Proxies 2871 They exist. They are hard to defend against. Research continues. 2872 Beware. 2874 12. Acknowledgments 2876 HTTP has evolved considerably over the years. It has benefited from 2877 a large and active developer community--the many people who have 2878 participated on the www-talk mailing list--and it is that community 2879 which has been most responsible for the success of HTTP and of the 2880 World-Wide Web in general. Marc Andreessen, Robert Cailliau, Daniel 2881 W. Connolly, Bob Denny, John Franks, Jean-Francois Groff, Phillip M. 2882 Hallam-Baker, Hakon W. Lie, Ari Luotonen, Rob McCool, Lou Montulli, 2883 Dave Raggett, Tony Sanders, and Marc VanHeyningen deserve special 2884 recognition for their efforts in defining early aspects of the 2885 protocol. 2887 This document has benefited greatly from the comments of all those 2888 participating in the HTTP-WG. In addition to those already 2889 mentioned, the following individuals have contributed to this 2890 specification: 2892 Gary Adams, Harald Tveit Alvestrand, Keith Ball, Brian Behlendorf, 2893 Paul Burchard, Maurizio Codogno, Mike Cowlishaw, Roman Czyborra, 2894 Michael A. Dolan, Daniel DuBois, David J. Fiander, Alan Freier, Marc 2895 Hedlund, Greg Herlihy, Koen Holtman, Alex Hopmann, Bob Jernigan, Shel 2896 Kaphan, Rohit Khare, John Klensin, Martijn Koster, Alexei Kosut, 2897 David M. Kristol, Daniel LaLiberte, Ben Laurie, Paul J. Leach, Albert 2898 Lunde, John C. Mallery, Jean-Philippe Martin-Flatin, Mitra, David 2899 Morris, Gavin Nicol, Ross Patterson, Bill Perry, Jeffrey Perry, Scott 2900 Powers, Owen Rees, Luigi Rizzo, David Robinson, Marc Salomon, Rich 2901 Salz, Allan M. Schiffman, Jim Seidman, Chuck Shotton, Eric W. Sink, 2902 Simon E. Spero, Richard N. Taylor, Robert S. Thau, Bill (BearHeart) 2903 Weinman, Francois Yergeau, Mary Ellen Zurko, Josh Cohen. 2905 Thanks to the "cave men" of Palo Alto. You know who you are. 2907 Jim Gettys (the editor of [RFC2616]) wishes particularly to thank Roy 2908 Fielding, the editor of [RFC2068], along with John Klensin, Jeff 2909 Mogul, Paul Leach, Dave Kristol, Koen Holtman, John Franks, Josh 2910 Cohen, Alex Hopmann, Scott Lawrence, and Larry Masinter for their 2911 help. And thanks go particularly to Jeff Mogul and Scott Lawrence 2912 for performing the "MUST/MAY/SHOULD" audit. 2914 The Apache Group, Anselm Baird-Smith, author of Jigsaw, and Henrik 2915 Frystyk implemented RFC 2068 early, and we wish to thank them for the 2916 discovery of many of the problems that this document attempts to 2917 rectify. 2919 This specification makes heavy use of the augmented BNF and generic 2920 constructs defined by David H. Crocker for [RFC5234]. Similarly, it 2921 reuses many of the definitions provided by Nathaniel Borenstein and 2922 Ned Freed for MIME [RFC2045]. We hope that their inclusion in this 2923 specification will help reduce past confusion over the relationship 2924 between HTTP and Internet mail message formats. 2926 13. References 2928 13.1. Normative References 2930 [ISO-8859-1] 2931 International Organization for Standardization, 2932 "Information technology -- 8-bit single-byte coded graphic 2933 character sets -- Part 1: Latin alphabet No. 1", ISO/ 2934 IEC 8859-1:1998, 1998. 2936 [Part2] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., 2937 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., 2938 and J. Reschke, Ed., "HTTP/1.1, part 2: Message 2939 Semantics", draft-ietf-httpbis-p2-semantics-09 (work in 2940 progress), March 2010. 2942 [Part3] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., 2943 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., 2944 and J. Reschke, Ed., "HTTP/1.1, part 3: Message Payload 2945 and Content Negotiation", draft-ietf-httpbis-p3-payload-09 2946 (work in progress), March 2010. 2948 [Part5] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., 2949 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., 2950 and J. Reschke, Ed., "HTTP/1.1, part 5: Range Requests and 2951 Partial Responses", draft-ietf-httpbis-p5-range-09 (work 2952 in progress), March 2010. 2954 [Part6] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., 2955 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., 2956 Nottingham, M., Ed., and J. Reschke, Ed., "HTTP/1.1, part 2957 6: Caching", draft-ietf-httpbis-p6-cache-09 (work in 2958 progress), March 2010. 2960 [RFC1950] Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data Format 2961 Specification version 3.3", RFC 1950, May 1996. 2963 RFC 1950 is an Informational RFC, thus it may be less 2964 stable than this specification. On the other hand, this 2965 downward reference was present since the publication of 2966 RFC 2068 in 1997 ([RFC2068]), therefore it is unlikely to 2967 cause problems in practice. See also [BCP97]. 2969 [RFC1951] Deutsch, P., "DEFLATE Compressed Data Format Specification 2970 version 1.3", RFC 1951, May 1996. 2972 RFC 1951 is an Informational RFC, thus it may be less 2973 stable than this specification. On the other hand, this 2974 downward reference was present since the publication of 2975 RFC 2068 in 1997 ([RFC2068]), therefore it is unlikely to 2976 cause problems in practice. See also [BCP97]. 2978 [RFC1952] Deutsch, P., Gailly, J-L., Adler, M., Deutsch, L., and G. 2979 Randers-Pehrson, "GZIP file format specification version 2980 4.3", RFC 1952, May 1996. 2982 RFC 1952 is an Informational RFC, thus it may be less 2983 stable than this specification. On the other hand, this 2984 downward reference was present since the publication of 2985 RFC 2068 in 1997 ([RFC2068]), therefore it is unlikely to 2986 cause problems in practice. See also [BCP97]. 2988 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2989 Requirement Levels", BCP 14, RFC 2119, March 1997. 2991 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 2992 Resource Identifier (URI): Generic Syntax", RFC 3986, 2993 STD 66, January 2005. 2995 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 2996 Specifications: ABNF", STD 68, RFC 5234, January 2008. 2998 [USASCII] American National Standards Institute, "Coded Character 2999 Set -- 7-bit American Standard Code for Information 3000 Interchange", ANSI X3.4, 1986. 3002 13.2. Informative References 3004 [BCP97] Klensin, J. and S. Hartman, "Handling Normative References 3005 to Standards-Track Documents", BCP 97, RFC 4897, 3006 June 2007. 3008 [Kri2001] Kristol, D., "HTTP Cookies: Standards, Privacy, and 3009 Politics", ACM Transactions on Internet Technology Vol. 1, 3010 #2, November 2001, . 3012 [Nie1997] Nielsen, H., Gettys, J., Prud'hommeaux, E., Lie, H., and 3013 C. Lilley, "Network Performance Effects of HTTP/1.1, CSS1, 3014 and PNG", ACM Proceedings of the ACM SIGCOMM '97 3015 conference on Applications, technologies, architectures, 3016 and protocols for computer communication SIGCOMM '97, 3017 September 1997, 3018 . 3020 [Pad1995] Padmanabhan, V. and J. Mogul, "Improving HTTP Latency", 3021 Computer Networks and ISDN Systems v. 28, pp. 25-35, 3022 December 1995, 3023 . 3025 [RFC1123] Braden, R., "Requirements for Internet Hosts - Application 3026 and Support", STD 3, RFC 1123, October 1989. 3028 [RFC1305] Mills, D., "Network Time Protocol (Version 3) 3029 Specification, Implementation", RFC 1305, March 1992. 3031 [RFC1900] Carpenter, B. and Y. Rekhter, "Renumbering Needs Work", 3032 RFC 1900, February 1996. 3034 [RFC1945] Berners-Lee, T., Fielding, R., and H. Nielsen, "Hypertext 3035 Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996. 3037 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 3038 Extensions (MIME) Part One: Format of Internet Message 3039 Bodies", RFC 2045, November 1996. 3041 [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) 3042 Part Three: Message Header Extensions for Non-ASCII Text", 3043 RFC 2047, November 1996. 3045 [RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and T. 3046 Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", 3047 RFC 2068, January 1997. 3049 [RFC2109] Kristol, D. and L. Montulli, "HTTP State Management 3050 Mechanism", RFC 2109, February 1997. 3052 [RFC2145] Mogul, J., Fielding, R., Gettys, J., and H. Nielsen, "Use 3053 and Interpretation of HTTP Version Numbers", RFC 2145, 3054 May 1997. 3056 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 3057 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 3058 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 3060 [RFC2817] Khare, R. and S. Lawrence, "Upgrading to TLS Within 3061 HTTP/1.1", RFC 2817, May 2000. 3063 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 3065 [RFC2965] Kristol, D. and L. Montulli, "HTTP State Management 3066 Mechanism", RFC 2965, October 2000. 3068 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration 3069 Procedures for Message Header Fields", BCP 90, RFC 3864, 3070 September 2004. 3072 [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and 3073 Registration Procedures", BCP 13, RFC 4288, December 2005. 3075 [RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and 3076 Registration Procedures for New URI Schemes", BCP 115, 3077 RFC 4395, February 2006. 3079 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 3080 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 3081 May 2008. 3083 [RFC5322] Resnick, P., "Internet Message Format", RFC 5322, 3084 October 2008. 3086 [Spe] Spero, S., "Analysis of HTTP Performance Problems", 3087 . 3089 [Tou1998] Touch, J., Heidemann, J., and K. Obraczka, "Analysis of 3090 HTTP Performance", ISI Research Report ISI/RR-98-463, 3091 Aug 1998, . 3093 (original report dated Aug. 1996) 3095 Appendix A. Tolerant Applications 3097 Although this document specifies the requirements for the generation 3098 of HTTP/1.1 messages, not all applications will be correct in their 3099 implementation. We therefore recommend that operational applications 3100 be tolerant of deviations whenever those deviations can be 3101 interpreted unambiguously. 3103 Clients SHOULD be tolerant in parsing the Status-Line and servers 3104 SHOULD be tolerant when parsing the Request-Line. In particular, 3105 they SHOULD accept any amount of WSP characters between fields, even 3106 though only a single SP is required. 3108 The line terminator for header fields is the sequence CRLF. However, 3109 we recommend that applications, when parsing such headers, recognize 3110 a single LF as a line terminator and ignore the leading CR. 3112 The character set of an entity-body SHOULD be labeled as the lowest 3113 common denominator of the character codes used within that body, with 3114 the exception that not labeling the entity is preferred over labeling 3115 the entity with the labels US-ASCII or ISO-8859-1. See [Part3]. 3117 Additional rules for requirements on parsing and encoding of dates 3118 and other potential problems with date encodings include: 3120 o HTTP/1.1 clients and caches SHOULD assume that an RFC-850 date 3121 which appears to be more than 50 years in the future is in fact in 3122 the past (this helps solve the "year 2000" problem). 3124 o An HTTP/1.1 implementation MAY internally represent a parsed 3125 Expires date as earlier than the proper value, but MUST NOT 3126 internally represent a parsed Expires date as later than the 3127 proper value. 3129 o All expiration-related calculations MUST be done in GMT. The 3130 local time zone MUST NOT influence the calculation or comparison 3131 of an age or expiration time. 3133 o If an HTTP header incorrectly carries a date value with a time 3134 zone other than GMT, it MUST be converted into GMT using the most 3135 conservative possible conversion. 3137 Appendix B. Compatibility with Previous Versions 3139 HTTP has been in use by the World-Wide Web global information 3140 initiative since 1990. The first version of HTTP, later referred to 3141 as HTTP/0.9, was a simple protocol for hypertext data transfer across 3142 the Internet with only a single method and no metadata. HTTP/1.0, as 3143 defined by [RFC1945], added a range of request methods and MIME-like 3144 messaging that could include metadata about the data transferred and 3145 modifiers on the request/response semantics. However, HTTP/1.0 did 3146 not sufficiently take into consideration the effects of hierarchical 3147 proxies, caching, the need for persistent connections, or name-based 3148 virtual hosts. The proliferation of incompletely-implemented 3149 applications calling themselves "HTTP/1.0" further necessitated a 3150 protocol version change in order for two communicating applications 3151 to determine each other's true capabilities. 3153 HTTP/1.1 remains compatible with HTTP/1.0 by including more stringent 3154 requirements that enable reliable implementations, adding only those 3155 new features that will either be safely ignored by an HTTP/1.0 3156 recipient or only sent when communicating with a party advertising 3157 compliance with HTTP/1.1. 3159 It is beyond the scope of a protocol specification to mandate 3160 compliance with previous versions. HTTP/1.1 was deliberately 3161 designed, however, to make supporting previous versions easy. It is 3162 worth noting that, at the time of composing this specification, we 3163 would expect general-purpose HTTP/1.1 servers to: 3165 o understand any valid request in the format of HTTP/1.0 and 1.1; 3167 o respond appropriately with a message in the same major version 3168 used by the client. 3170 And we would expect HTTP/1.1 clients to: 3172 o understand any valid response in the format of HTTP/1.0 or 1.1. 3174 For most implementations of HTTP/1.0, each connection is established 3175 by the client prior to the request and closed by the server after 3176 sending the response. Some implementations implement the Keep-Alive 3177 version of persistent connections described in Section 19.7.1 of 3178 [RFC2068]. 3180 B.1. Changes from HTTP/1.0 3182 This section summarizes major differences between versions HTTP/1.0 3183 and HTTP/1.1. 3185 B.1.1. Changes to Simplify Multi-homed Web Servers and Conserve IP 3186 Addresses 3188 The requirements that clients and servers support the Host request- 3189 header, report an error if the Host request-header (Section 9.4) is 3190 missing from an HTTP/1.1 request, and accept absolute URIs 3191 (Section 4.1.2) are among the most important changes defined by this 3192 specification. 3194 Older HTTP/1.0 clients assumed a one-to-one relationship of IP 3195 addresses and servers; there was no other established mechanism for 3196 distinguishing the intended server of a request than the IP address 3197 to which that request was directed. The changes outlined above will 3198 allow the Internet, once older HTTP clients are no longer common, to 3199 support multiple Web sites from a single IP address, greatly 3200 simplifying large operational Web servers, where allocation of many 3201 IP addresses to a single host has created serious problems. The 3202 Internet will also be able to recover the IP addresses that have been 3203 allocated for the sole purpose of allowing special-purpose domain 3204 names to be used in root-level HTTP URLs. Given the rate of growth 3205 of the Web, and the number of servers already deployed, it is 3206 extremely important that all implementations of HTTP (including 3207 updates to existing HTTP/1.0 applications) correctly implement these 3208 requirements: 3210 o Both clients and servers MUST support the Host request-header. 3212 o A client that sends an HTTP/1.1 request MUST send a Host header. 3214 o Servers MUST report a 400 (Bad Request) error if an HTTP/1.1 3215 request does not include a Host request-header. 3217 o Servers MUST accept absolute URIs. 3219 B.2. Compatibility with HTTP/1.0 Persistent Connections 3221 Some clients and servers might wish to be compatible with some 3222 previous implementations of persistent connections in HTTP/1.0 3223 clients and servers. Persistent connections in HTTP/1.0 are 3224 explicitly negotiated as they are not the default behavior. HTTP/1.0 3225 experimental implementations of persistent connections are faulty, 3226 and the new facilities in HTTP/1.1 are designed to rectify these 3227 problems. The problem was that some existing HTTP/1.0 clients may be 3228 sending Keep-Alive to a proxy server that doesn't understand 3229 Connection, which would then erroneously forward it to the next 3230 inbound server, which would establish the Keep-Alive connection and 3231 result in a hung HTTP/1.0 proxy waiting for the close on the 3232 response. The result is that HTTP/1.0 clients must be prevented from 3233 using Keep-Alive when talking to proxies. 3235 However, talking to proxies is the most important use of persistent 3236 connections, so that prohibition is clearly unacceptable. Therefore, 3237 we need some other mechanism for indicating a persistent connection 3238 is desired, which is safe to use even when talking to an old proxy 3239 that ignores Connection. Persistent connections are the default for 3240 HTTP/1.1 messages; we introduce a new keyword (Connection: close) for 3241 declaring non-persistence. See Section 9.1. 3243 The original HTTP/1.0 form of persistent connections (the Connection: 3244 Keep-Alive and Keep-Alive header) is documented in Section 19.7.1 of 3245 [RFC2068]. 3247 B.3. Changes from RFC 2068 3249 This specification has been carefully audited to correct and 3250 disambiguate key word usage; RFC 2068 had many problems in respect to 3251 the conventions laid out in [RFC2119]. 3253 Transfer-coding and message lengths all interact in ways that 3254 required fixing exactly when chunked encoding is used (to allow for 3255 transfer encoding that may not be self delimiting); it was important 3256 to straighten out exactly how message lengths are computed. 3257 (Sections 6.2, 3.4, 9.2, see also [Part3], [Part5] and [Part6]) 3259 The use and interpretation of HTTP version numbers has been clarified 3260 by [RFC2145]. Require proxies to upgrade requests to highest 3261 protocol version they support to deal with problems discovered in 3262 HTTP/1.0 implementations (Section 2.5) 3264 Quality Values of zero should indicate that "I don't want something" 3265 to allow clients to refuse a representation. (Section 6.4) 3267 Transfer-coding had significant problems, particularly with 3268 interactions with chunked encoding. The solution is that transfer- 3269 codings become as full fledged as content-codings. This involves 3270 adding an IANA registry for transfer-codings (separate from content 3271 codings), a new header field (TE) and enabling trailer headers in the 3272 future. Transfer encoding is a major performance benefit, so it was 3273 worth fixing [Nie1997]. TE also solves another, obscure, downward 3274 interoperability problem that could have occurred due to interactions 3275 between authentication trailers, chunked encoding and HTTP/1.0 3276 clients.(Section 6.2, 6.2.1, 7.1.3.2, and 9.5) 3278 Proxies should be able to add Content-Length when appropriate. 3279 (Section 7.1.3.2) 3281 B.4. Changes from RFC 2616 3283 Empty list elements in list productions have been deprecated. 3284 (Section 1.2.1) 3285 Rules about implicit linear whitespace between certain grammar 3286 productions have been removed; now it's only allowed when 3287 specifically pointed out in the ABNF. The NUL character is no longer 3288 allowed in comment and quoted-string text. The quoted-pair rule no 3289 longer allows escaping control characters other than HTAB. Non-ASCII 3290 content in header fields and reason phrase has been obsoleted and 3291 made opaque (the TEXT rule was removed) (Section 1.2.2) 3293 Clarify that HTTP-Version is case sensitive. (Section 2.5) 3295 Remove reference to non-existent identity transfer-coding value 3296 tokens. (Sections 6.2 and 3.4) 3298 Require that invalid whitespace around field-names be rejected. 3299 (Section 3.2) 3301 Update use of abs_path production from RFC1808 to the path-absolute + 3302 query components of RFC3986. (Section 4.1.2) 3304 Clarification that the chunk length does not include the count of the 3305 octets in the chunk header and trailer. Furthermore disallowed line 3306 folding in chunk extensions. (Section 6.2.1) 3308 Remove hard limit of two connections per server. (Section 7.1.4) 3310 Clarify exactly when close connection options must be sent. 3311 (Section 9.1) 3313 Appendix C. Collected ABNF 3315 BWS = OWS 3317 Cache-Control = 3318 Chunked-Body = *chunk last-chunk trailer-part CRLF 3319 Connection = "Connection:" OWS Connection-v 3320 Connection-v = *( "," OWS ) connection-token *( OWS "," [ OWS 3321 connection-token ] ) 3322 Content-Length = "Content-Length:" OWS 1*Content-Length-v 3323 Content-Length-v = 1*DIGIT 3325 Date = "Date:" OWS Date-v 3326 Date-v = HTTP-date 3328 GMT = %x47.4D.54 ; GMT 3330 HTTP-Prot-Name = %x48.54.54.50 ; HTTP 3331 HTTP-Version = HTTP-Prot-Name "/" 1*DIGIT "." 1*DIGIT 3332 HTTP-date = rfc1123-date / obs-date 3333 HTTP-message = start-line *( header-field CRLF ) CRLF [ message-body 3334 ] 3335 Host = "Host:" OWS Host-v 3336 Host-v = uri-host [ ":" port ] 3338 Method = token 3340 OWS = *( [ obs-fold ] WSP ) 3342 Pragma = 3344 RWS = 1*( [ obs-fold ] WSP ) 3345 Reason-Phrase = *( WSP / VCHAR / obs-text ) 3346 Request = Request-Line *( ( general-header / request-header / 3347 entity-header ) CRLF ) CRLF [ message-body ] 3348 Request-Line = Method SP request-target SP HTTP-Version CRLF 3349 Response = Status-Line *( ( general-header / response-header / 3350 entity-header ) CRLF ) CRLF [ message-body ] 3352 Status-Code = 3DIGIT 3353 Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF 3355 TE = "TE:" OWS TE-v 3356 TE-v = [ ( "," / t-codings ) *( OWS "," [ OWS t-codings ] ) ] 3357 Trailer = "Trailer:" OWS Trailer-v 3358 Trailer-v = *( "," OWS ) field-name *( OWS "," [ OWS field-name ] ) 3359 Transfer-Encoding = "Transfer-Encoding:" OWS Transfer-Encoding-v 3360 Transfer-Encoding-v = *( "," OWS ) transfer-coding *( OWS "," [ OWS 3361 transfer-coding ] ) 3363 URI = 3364 URI-reference = 3365 Upgrade = "Upgrade:" OWS Upgrade-v 3366 Upgrade-v = *( "," OWS ) product *( OWS "," [ OWS product ] ) 3368 Via = "Via:" OWS Via-v 3369 Via-v = *( "," OWS ) received-protocol RWS received-by [ RWS comment 3370 ] *( OWS "," [ OWS received-protocol RWS received-by [ RWS comment ] 3371 ] ) 3373 Warning = 3375 absolute-URI = 3376 asctime-date = day-name SP date3 SP time-of-day SP year 3377 attribute = token 3378 authority = 3379 chunk = chunk-size *WSP [ chunk-ext ] CRLF chunk-data CRLF 3380 chunk-data = 1*OCTET 3381 chunk-ext = *( ";" *WSP chunk-ext-name [ "=" chunk-ext-val ] *WSP ) 3382 chunk-ext-name = token 3383 chunk-ext-val = token / quoted-str-nf 3384 chunk-size = 1*HEXDIG 3385 comment = "(" *( ctext / quoted-cpair / comment ) ")" 3386 connection-token = token 3387 ctext = OWS / %x21-27 ; '!'-''' 3388 / %x2A-5B ; '*'-'[' 3389 / %x5D-7E ; ']'-'~' 3390 / obs-text 3392 date1 = day SP month SP year 3393 date2 = day "-" month "-" 2DIGIT 3394 date3 = month SP ( 2DIGIT / ( SP DIGIT ) ) 3395 day = 2DIGIT 3396 day-name = %x4D.6F.6E ; Mon 3397 / %x54.75.65 ; Tue 3398 / %x57.65.64 ; Wed 3399 / %x54.68.75 ; Thu 3400 / %x46.72.69 ; Fri 3401 / %x53.61.74 ; Sat 3402 / %x53.75.6E ; Sun 3403 day-name-l = %x4D.6F.6E.64.61.79 ; Monday 3404 / %x54.75.65.73.64.61.79 ; Tuesday 3405 / %x57.65.64.6E.65.73.64.61.79 ; Wednesday 3406 / %x54.68.75.72.73.64.61.79 ; Thursday 3407 / %x46.72.69.64.61.79 ; Friday 3408 / %x53.61.74.75.72.64.61.79 ; Saturday 3409 / %x53.75.6E.64.61.79 ; Sunday 3411 entity-body = 3412 entity-header = 3414 field-content = *( WSP / VCHAR / obs-text ) 3415 field-name = token 3416 field-value = *( field-content / OWS ) 3418 general-header = Cache-Control / Connection / Date / Pragma / Trailer 3419 / Transfer-Encoding / Upgrade / Via / Warning 3421 header-field = field-name ":" OWS [ field-value ] OWS 3422 hour = 2DIGIT 3423 http-URI = "http://" authority path-abempty [ "?" query ] 3424 https-URI = "https://" authority path-abempty [ "?" query ] 3426 last-chunk = 1*"0" *WSP [ chunk-ext ] CRLF 3427 message-body = entity-body / 3428 3429 minute = 2DIGIT 3430 month = %x4A.61.6E ; Jan 3431 / %x46.65.62 ; Feb 3432 / %x4D.61.72 ; Mar 3433 / %x41.70.72 ; Apr 3434 / %x4D.61.79 ; May 3435 / %x4A.75.6E ; Jun 3436 / %x4A.75.6C ; Jul 3437 / %x41.75.67 ; Aug 3438 / %x53.65.70 ; Sep 3439 / %x4F.63.74 ; Oct 3440 / %x4E.6F.76 ; Nov 3441 / %x44.65.63 ; Dec 3443 obs-date = rfc850-date / asctime-date 3444 obs-fold = CRLF 3445 obs-text = %x80-FF 3447 partial-URI = relative-part [ "?" query ] 3448 path-abempty = 3449 path-absolute = 3450 port = 3451 product = token [ "/" product-version ] 3452 product-version = token 3453 protocol-name = token 3454 protocol-version = token 3455 pseudonym = token 3457 qdtext = OWS / "!" / %x23-5B ; '#'-'[' 3458 / %x5D-7E ; ']'-'~' 3459 / obs-text 3460 qdtext-nf = WSP / "!" / %x23-5B ; '#'-'[' 3461 / %x5D-7E ; ']'-'~' 3462 / obs-text 3463 query = 3464 quoted-cpair = "\" ( WSP / VCHAR / obs-text ) 3465 quoted-pair = "\" ( WSP / VCHAR / obs-text ) 3466 quoted-str-nf = DQUOTE *( qdtext-nf / quoted-pair ) DQUOTE 3467 quoted-string = DQUOTE *( qdtext / quoted-pair ) DQUOTE 3468 qvalue = ( "0" [ "." *3DIGIT ] ) / ( "1" [ "." *3"0" ] ) 3470 received-by = ( uri-host [ ":" port ] ) / pseudonym 3471 received-protocol = [ protocol-name "/" ] protocol-version 3472 relative-part = 3473 request-header = 3474 request-target = "*" / absolute-URI / ( path-absolute [ "?" query ] ) 3475 / authority 3476 response-header = 3477 rfc1123-date = day-name "," SP date1 SP time-of-day SP GMT 3478 rfc850-date = day-name-l "," SP date2 SP time-of-day SP GMT 3480 second = 2DIGIT 3481 special = "(" / ")" / "<" / ">" / "@" / "," / ";" / ":" / "\" / 3482 DQUOTE / "/" / "[" / "]" / "?" / "=" / "{" / "}" 3483 start-line = Request-Line / Status-Line 3485 t-codings = "trailers" / ( transfer-extension [ te-params ] ) 3486 tchar = "!" / "#" / "$" / "%" / "&" / "'" / "*" / "+" / "-" / "." / 3487 "^" / "_" / "`" / "|" / "~" / DIGIT / ALPHA 3488 te-ext = OWS ";" OWS token [ "=" ( token / quoted-string ) ] 3489 te-params = OWS ";" OWS "q=" qvalue *te-ext 3490 time-of-day = hour ":" minute ":" second 3491 token = 1*tchar 3492 trailer-part = *( entity-header CRLF ) 3493 transfer-coding = "chunked" / "compress" / "deflate" / "gzip" / 3494 transfer-extension 3495 transfer-extension = token *( OWS ";" OWS transfer-parameter ) 3496 transfer-parameter = attribute BWS "=" BWS value 3498 uri-host = 3500 value = token / quoted-string 3502 year = 4DIGIT 3504 ABNF diagnostics: 3506 ; Chunked-Body defined but not used 3507 ; Content-Length defined but not used 3508 ; HTTP-message defined but not used 3509 ; Host defined but not used 3510 ; Request defined but not used 3511 ; Response defined but not used 3512 ; TE defined but not used 3513 ; URI defined but not used 3514 ; URI-reference defined but not used 3515 ; http-URI defined but not used 3516 ; https-URI defined but not used 3517 ; partial-URI defined but not used 3518 ; special defined but not used 3520 Appendix D. Change Log (to be removed by RFC Editor before publication) 3522 D.1. Since RFC2616 3524 Extracted relevant partitions from [RFC2616]. 3526 D.2. Since draft-ietf-httpbis-p1-messaging-00 3528 Closed issues: 3530 o : "HTTP Version 3531 should be case sensitive" 3532 () 3534 o : "'unsafe' 3535 characters" () 3537 o : "Chunk Size 3538 Definition" () 3540 o : "Message Length" 3541 () 3543 o : "Media Type 3544 Registrations" () 3546 o : "URI includes 3547 query" () 3549 o : "No close on 3550 1xx responses" () 3552 o : "Remove 3553 'identity' token references" 3554 () 3556 o : "Import query 3557 BNF" 3559 o : "qdtext BNF" 3561 o : "Normative and 3562 Informative references" 3564 o : "RFC2606 3565 Compliance" 3567 o : "RFC977 3568 reference" 3570 o : "RFC1700 3571 references" 3573 o : "inconsistency 3574 in date format explanation" 3576 o : "Date reference 3577 typo" 3579 o : "Informative 3580 references" 3582 o : "ISO-8859-1 3583 Reference" 3585 o : "Normative up- 3586 to-date references" 3588 Other changes: 3590 o Update media type registrations to use RFC4288 template. 3592 o Use names of RFC4234 core rules DQUOTE and WSP, fix broken ABNF 3593 for chunk-data (work in progress on 3594 ) 3596 D.3. Since draft-ietf-httpbis-p1-messaging-01 3598 Closed issues: 3600 o : "Bodies on GET 3601 (and other) requests" 3603 o : "Updating to 3604 RFC4288" 3606 o : "Status Code 3607 and Reason Phrase" 3609 o : "rel_path not 3610 used" 3612 Ongoing work on ABNF conversion 3613 (): 3615 o Get rid of duplicate BNF rule names ("host" -> "uri-host", 3616 "trailer" -> "trailer-part"). 3618 o Avoid underscore character in rule names ("http_URL" -> "http- 3619 URL", "abs_path" -> "path-absolute"). 3621 o Add rules for terms imported from URI spec ("absoluteURI", 3622 "authority", "path-absolute", "port", "query", "relativeURI", 3623 "host) -- these will have to be updated when switching over to 3624 RFC3986. 3626 o Synchronize core rules with RFC5234. 3628 o Get rid of prose rules that span multiple lines. 3630 o Get rid of unused rules LOALPHA and UPALPHA. 3632 o Move "Product Tokens" section (back) into Part 1, as "token" is 3633 used in the definition of the Upgrade header. 3635 o Add explicit references to BNF syntax and rules imported from 3636 other parts of the specification. 3638 o Rewrite prose rule "token" in terms of "tchar", rewrite prose rule 3639 "TEXT". 3641 D.4. Since draft-ietf-httpbis-p1-messaging-02 3643 Closed issues: 3645 o : "HTTP-date vs. 3646 rfc1123-date" 3648 o : "WS in quoted- 3649 pair" 3651 Ongoing work on IANA Message Header Registration 3652 (): 3654 o Reference RFC 3984, and update header registrations for headers 3655 defined in this document. 3657 Ongoing work on ABNF conversion 3658 (): 3660 o Replace string literals when the string really is case-sensitive 3661 (HTTP-Version). 3663 D.5. Since draft-ietf-httpbis-p1-messaging-03 3665 Closed issues: 3667 o : "Connection 3668 closing" 3670 o : "Move 3671 registrations and registry information to IANA Considerations" 3673 o : "need new URL 3674 for PAD1995 reference" 3676 o : "IANA 3677 Considerations: update HTTP URI scheme registration" 3679 o : "Cite HTTPS 3680 URI scheme definition" 3682 o : "List-type 3683 headers vs Set-Cookie" 3685 Ongoing work on ABNF conversion 3686 (): 3688 o Replace string literals when the string really is case-sensitive 3689 (HTTP-Date). 3691 o Replace HEX by HEXDIG for future consistence with RFC 5234's core 3692 rules. 3694 D.6. Since draft-ietf-httpbis-p1-messaging-04 3696 Closed issues: 3698 o : "Out-of-date 3699 reference for URIs" 3701 o : "RFC 2822 is 3702 updated by RFC 5322" 3704 Ongoing work on ABNF conversion 3705 (): 3707 o Use "/" instead of "|" for alternatives. 3709 o Get rid of RFC822 dependency; use RFC5234 plus extensions instead. 3711 o Only reference RFC 5234's core rules. 3713 o Introduce new ABNF rules for "bad" whitespace ("BWS"), optional 3714 whitespace ("OWS") and required whitespace ("RWS"). 3716 o Rewrite ABNFs to spell out whitespace rules, factor out header 3717 value format definitions. 3719 D.7. Since draft-ietf-httpbis-p1-messaging-05 3721 Closed issues: 3723 o : "Header LWS" 3725 o : "Sort 1.3 3726 Terminology" 3728 o : "RFC2047 3729 encoded words" 3731 o : "Character 3732 Encodings in TEXT" 3734 o : "Line Folding" 3736 o : "OPTIONS * and 3737 proxies" 3739 o : "Reason-Phrase 3740 BNF" 3742 o : "Use of TEXT" 3744 o : "Join 3745 "Differences Between HTTP Entities and RFC 2045 Entities"?" 3747 o : "RFC822 3748 reference left in discussion of date formats" 3750 Final work on ABNF conversion 3751 (): 3753 o Rewrite definition of list rules, deprecate empty list elements. 3755 o Add appendix containing collected and expanded ABNF. 3757 Other changes: 3759 o Rewrite introduction; add mostly new Architecture Section. 3761 o Move definition of quality values from Part 3 into Part 1; make TE 3762 request header grammar independent of accept-params (defined in 3763 Part 3). 3765 D.8. Since draft-ietf-httpbis-p1-messaging-06 3767 Closed issues: 3769 o : "base for 3770 numeric protocol elements" 3772 o : "comment ABNF" 3774 Partly resolved issues: 3776 o : "205 Bodies" 3777 (took out language that implied that there may be methods for 3778 which a request body MUST NOT be included) 3780 o : "editorial 3781 improvements around HTTP-date" 3783 D.9. Since draft-ietf-httpbis-p1-messaging-07 3785 Closed issues: 3787 o : "Repeating 3788 single-value headers" 3790 o : "increase 3791 connection limit" 3793 o : "IP addresses 3794 in URLs" 3796 o : "take over 3797 HTTP Upgrade Token Registry" 3799 o : "CR and LF in 3800 chunk extension values" 3802 o : "HTTP/0.9 3803 support" 3805 o : "pick IANA 3806 policy (RFC5226) for Transfer Coding / Content Coding" 3808 o : "move 3809 definitions of gzip/deflate/compress to part 1" 3811 o : "disallow 3812 control characters in quoted-pair" 3814 Partly resolved issues: 3816 o : "update IANA 3817 requirements wrt Transfer-Coding values" (add the IANA 3818 Considerations subsection) 3820 D.10. Since draft-ietf-httpbis-p1-messaging-08 3822 Closed issues: 3824 o : "header 3825 parsing, treatment of leading and trailing OWS" 3827 Partly resolved issues: 3829 o : "Placement of 3830 13.5.1 and 13.5.2" 3832 o : "use of term 3833 "word" when talking about header structure" 3835 Index 3837 A 3838 application/http Media Type 58 3840 C 3841 cache 13 3842 cacheable 14 3843 chunked (Coding Format) 32 3844 client 10 3845 Coding Format 3846 chunked 32 3847 compress 34 3848 deflate 35 3849 gzip 35 3850 compress (Coding Format) 34 3851 connection 10 3852 Connection header 46 3853 Content-Length header 47 3855 D 3856 Date header 48 3857 deflate (Coding Format) 35 3858 downstream 12 3860 G 3861 gateway 13 3862 Grammar 3863 absolute-URI 16 3864 ALPHA 7 3865 asctime-date 31 3866 attribute 32 3867 authority 16 3868 BWS 9 3869 chunk 33 3870 chunk-data 33 3871 chunk-ext 33 3872 chunk-ext-name 33 3873 chunk-ext-val 33 3874 chunk-size 33 3875 Chunked-Body 33 3876 comment 21 3877 Connection 46 3878 connection-token 46 3879 Connection-v 46 3880 Content-Length 47 3881 Content-Length-v 47 3882 CR 7 3883 CRLF 7 3884 ctext 21 3885 CTL 7 3886 Date 48 3887 Date-v 48 3888 date1 30 3889 date2 32 3890 date3 32 3891 day 30 3892 day-name 30 3893 day-name-l 30 3894 DIGIT 7 3895 DQUOTE 7 3896 extension-code 29 3897 extension-method 25 3898 field-content 20 3899 field-name 20 3900 field-value 20 3901 general-header 24 3902 GMT 30 3903 header-field 20 3904 HEXDIG 7 3905 Host 49 3906 Host-v 49 3907 hour 30 3908 HTTP-date 30 3909 HTTP-message 19 3910 HTTP-Prot-Name 15 3911 http-URI 16 3912 HTTP-Version 15 3913 https-URI 18 3914 last-chunk 33 3915 LF 7 3916 message-body 22 3917 Method 25 3918 minute 30 3919 month 30 3920 obs-date 31 3921 obs-text 10 3922 OCTET 7 3923 OWS 9 3924 path-absolute 16 3925 port 16 3926 product 35 3927 product-version 35 3928 protocol-name 54 3929 protocol-version 54 3930 pseudonym 54 3931 qdtext 10 3932 qdtext-nf 33 3933 query 16 3934 quoted-cpair 22 3935 quoted-pair 10 3936 quoted-str-nf 33 3937 quoted-string 10 3938 qvalue 36 3939 Reason-Phrase 29 3940 received-by 54 3941 received-protocol 54 3942 Request 25 3943 Request-Line 25 3944 request-target 25 3945 Response 28 3946 rfc850-date 31 3947 rfc1123-date 30 3948 RWS 9 3949 second 30 3950 SP 7 3951 special 9 3952 Status-Code 29 3953 Status-Line 28 3954 t-codings 50 3955 tchar 9 3956 TE 50 3957 te-ext 50 3958 te-params 50 3959 TE-v 50 3960 time-of-day 30 3961 token 9 3962 Trailer 51 3963 trailer-part 33 3964 Trailer-v 51 3965 transfer-coding 31 3966 Transfer-Encoding 52 3967 Transfer-Encoding-v 52 3968 transfer-extension 31 3969 transfer-parameter 32 3970 Upgrade 52 3971 Upgrade-v 52 3972 uri-host 16 3973 URI-reference 16 3974 value 32 3975 VCHAR 7 3976 Via 54 3977 Via-v 54 3978 WSP 7 3979 year 30 3980 gzip (Coding Format) 35 3982 H 3983 header field 19 3984 header section 19 3985 Headers 3986 Connection 46 3987 Content-Length 47 3988 Date 48 3989 Host 49 3990 TE 50 3991 Trailer 51 3992 Transfer-Encoding 52 3993 Upgrade 52 3994 Via 54 3995 headers 19 3996 Host header 49 3997 http URI scheme 16 3998 https URI scheme 17 4000 I 4001 inbound 12 4003 M 4004 Media Type 4005 application/http 58 4006 message/http 56 4007 message 11 4008 message/http Media Type 56 4010 O 4011 origin server 11 4012 outbound 12 4014 P 4015 proxy 12 4017 R 4018 request 11 4019 resource 16 4020 response 11 4021 reverse proxy 13 4023 S 4024 server 10 4026 T 4027 TE header 50 4028 Trailer header 51 4029 Transfer-Encoding header 52 4030 tunnel 13 4032 U 4033 Upgrade header 52 4034 upstream 12 4035 URI scheme 4036 http 16 4037 https 17 4038 user agent 11 4040 V 4041 Via header 54 4043 Authors' Addresses 4045 Roy T. Fielding (editor) 4046 Day Software 4047 23 Corporate Plaza DR, Suite 280 4048 Newport Beach, CA 92660 4049 USA 4051 Phone: +1-949-706-5300 4052 Fax: +1-949-706-5305 4053 Email: fielding@gbiv.com 4054 URI: http://roy.gbiv.com/ 4056 Jim Gettys 4057 One Laptop per Child 4058 21 Oak Knoll Road 4059 Carlisle, MA 01741 4060 USA 4062 Email: jg@laptop.org 4063 URI: http://www.laptop.org/ 4065 Jeffrey C. Mogul 4066 Hewlett-Packard Company 4067 HP Labs, Large Scale Systems Group 4068 1501 Page Mill Road, MS 1177 4069 Palo Alto, CA 94304 4070 USA 4072 Email: JeffMogul@acm.org 4074 Henrik Frystyk Nielsen 4075 Microsoft Corporation 4076 1 Microsoft Way 4077 Redmond, WA 98052 4078 USA 4080 Email: henrikn@microsoft.com 4081 Larry Masinter 4082 Adobe Systems, Incorporated 4083 345 Park Ave 4084 San Jose, CA 95110 4085 USA 4087 Email: LMM@acm.org 4088 URI: http://larry.masinter.net/ 4090 Paul J. Leach 4091 Microsoft Corporation 4092 1 Microsoft Way 4093 Redmond, WA 98052 4095 Email: paulle@microsoft.com 4097 Tim Berners-Lee 4098 World Wide Web Consortium 4099 MIT Computer Science and Artificial Intelligence Laboratory 4100 The Stata Center, Building 32 4101 32 Vassar Street 4102 Cambridge, MA 02139 4103 USA 4105 Email: timbl@w3.org 4106 URI: http://www.w3.org/People/Berners-Lee/ 4108 Yves Lafon (editor) 4109 World Wide Web Consortium 4110 W3C / ERCIM 4111 2004, rte des Lucioles 4112 Sophia-Antipolis, AM 06902 4113 France 4115 Email: ylafon@w3.org 4116 URI: http://www.raubacapeu.net/people/yves/ 4117 Julian F. Reschke (editor) 4118 greenbytes GmbH 4119 Hafenweg 16 4120 Muenster, NW 48155 4121 Germany 4123 Phone: +49 251 2807760 4124 Fax: +49 251 2807761 4125 Email: julian.reschke@greenbytes.de 4126 URI: http://greenbytes.de/tech/webdav/