idnits 2.17.1 draft-ietf-httpbis-p1-messaging-10.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == 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 (July 12, 2010) is 5037 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'BCP97' is defined on line 3072, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO-8859-1' == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p2-semantics-10 == Outdated reference: A later version (-20) exists of draft-ietf-httpbis-p3-payload-10 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p5-range-10 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p6-cache-10 ** 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: 3 errors (**), 0 flaws (~~), 7 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) Alcatel-Lucent 6 Intended status: Standards Track J. Mogul 7 Expires: January 13, 2011 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 July 12, 2010 22 HTTP/1.1, part 1: URIs, Connections, and Message Parsing 23 draft-ietf-httpbis-p1-messaging-10 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.11. 48 Status of This Memo 49 This Internet-Draft is submitted 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). Note that other groups may also distribute 54 working documents as Internet-Drafts. The list of current Internet- 55 Drafts is at http://datatracker.ietf.org/drafts/current/. 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 This Internet-Draft will expire on January 13, 2011. 64 Copyright Notice 66 Copyright (c) 2010 IETF Trust and the persons identified as the 67 document authors. All rights reserved. 69 This document is subject to BCP 78 and the IETF Trust's Legal 70 Provisions Relating to IETF Documents 71 (http://trustee.ietf.org/license-info) in effect on the date of 72 publication of this document. Please review these documents 73 carefully, as they describe your rights and restrictions with respect 74 to this document. Code Components extracted from this document must 75 include Simplified BSD License text as described in Section 4.e of 76 the Trust Legal Provisions and are provided without warranty as 77 described in the Simplified BSD License. 79 This document may contain material from IETF Documents or IETF 80 Contributions published or made publicly available before November 81 10, 2008. The person(s) controlling the copyright in some of this 82 material may not have granted the IETF Trust the right to allow 83 modifications of such material outside the IETF Standards Process. 84 Without obtaining an adequate license from the person(s) controlling 85 the copyright in such materials, this document may not be modified 86 outside the IETF Standards Process, and derivative works of it may 87 not be created outside the IETF Standards Process, except to format 88 it for publication as an RFC or to translate it into languages other 89 than English. 91 Table of Contents 93 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6 94 1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 7 95 1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 7 96 1.2.1. ABNF Extension: #rule . . . . . . . . . . . . . . . . 7 97 1.2.2. Basic Rules . . . . . . . . . . . . . . . . . . . . . 8 98 1.2.3. ABNF Rules defined in other Parts of the 99 Specification . . . . . . . . . . . . . . . . . . . . 10 100 2. HTTP architecture . . . . . . . . . . . . . . . . . . . . . . 11 101 2.1. Client/Server Operation . . . . . . . . . . . . . . . . . 11 102 2.2. Intermediaries . . . . . . . . . . . . . . . . . . . . . . 12 103 2.3. Caches . . . . . . . . . . . . . . . . . . . . . . . . . . 13 104 2.4. Transport Independence . . . . . . . . . . . . . . . . . . 14 105 2.5. HTTP Version . . . . . . . . . . . . . . . . . . . . . . . 15 106 2.6. Uniform Resource Identifiers . . . . . . . . . . . . . . . 16 107 2.6.1. http URI scheme . . . . . . . . . . . . . . . . . . . 17 108 2.6.2. https URI scheme . . . . . . . . . . . . . . . . . . . 18 109 2.6.3. http and https URI Normalization and Comparison . . . 18 110 3. HTTP Message . . . . . . . . . . . . . . . . . . . . . . . . . 19 111 3.1. Message Parsing Robustness . . . . . . . . . . . . . . . . 20 112 3.2. Header Fields . . . . . . . . . . . . . . . . . . . . . . 20 113 3.3. Message Body . . . . . . . . . . . . . . . . . . . . . . . 22 114 3.4. Message Length . . . . . . . . . . . . . . . . . . . . . . 23 115 3.5. General Header Fields . . . . . . . . . . . . . . . . . . 24 116 4. Request . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 117 4.1. Request-Line . . . . . . . . . . . . . . . . . . . . . . . 25 118 4.1.1. Method . . . . . . . . . . . . . . . . . . . . . . . . 25 119 4.1.2. request-target . . . . . . . . . . . . . . . . . . . . 26 120 4.2. The Resource Identified by a Request . . . . . . . . . . . 28 121 4.3. Effective Request URI . . . . . . . . . . . . . . . . . . 28 122 5. Response . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 123 5.1. Status-Line . . . . . . . . . . . . . . . . . . . . . . . 30 124 5.1.1. Status Code and Reason Phrase . . . . . . . . . . . . 30 125 6. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 31 126 6.1. Date/Time Formats: Full Date . . . . . . . . . . . . . . . 31 127 6.2. Transfer Codings . . . . . . . . . . . . . . . . . . . . . 33 128 6.2.1. Chunked Transfer Coding . . . . . . . . . . . . . . . 34 129 6.2.2. Compression Codings . . . . . . . . . . . . . . . . . 36 130 6.2.3. Transfer Coding Registry . . . . . . . . . . . . . . . 37 131 6.3. Product Tokens . . . . . . . . . . . . . . . . . . . . . . 37 132 6.4. Quality Values . . . . . . . . . . . . . . . . . . . . . . 38 133 7. Connections . . . . . . . . . . . . . . . . . . . . . . . . . 38 134 7.1. Persistent Connections . . . . . . . . . . . . . . . . . . 38 135 7.1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . 38 136 7.1.2. Overall Operation . . . . . . . . . . . . . . . . . . 39 137 7.1.3. Proxy Servers . . . . . . . . . . . . . . . . . . . . 41 138 7.1.4. Practical Considerations . . . . . . . . . . . . . . . 43 139 7.2. Message Transmission Requirements . . . . . . . . . . . . 44 140 7.2.1. Persistent Connections and Flow Control . . . . . . . 44 141 7.2.2. Monitoring Connections for Error Status Messages . . . 44 142 7.2.3. Use of the 100 (Continue) Status . . . . . . . . . . . 45 143 7.2.4. Client Behavior if Server Prematurely Closes 144 Connection . . . . . . . . . . . . . . . . . . . . . . 47 146 8. Miscellaneous notes that may disappear . . . . . . . . . . . . 47 147 8.1. Scheme aliases considered harmful . . . . . . . . . . . . 47 148 8.2. Use of HTTP for proxy communication . . . . . . . . . . . 48 149 8.3. Interception of HTTP for access control . . . . . . . . . 48 150 8.4. Use of HTTP by other protocols . . . . . . . . . . . . . . 48 151 8.5. Use of HTTP by media type specification . . . . . . . . . 48 152 9. Header Field Definitions . . . . . . . . . . . . . . . . . . . 48 153 9.1. Connection . . . . . . . . . . . . . . . . . . . . . . . . 48 154 9.2. Content-Length . . . . . . . . . . . . . . . . . . . . . . 49 155 9.3. Date . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 156 9.3.1. Clockless Origin Server Operation . . . . . . . . . . 51 157 9.4. Host . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 158 9.5. TE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 159 9.6. Trailer . . . . . . . . . . . . . . . . . . . . . . . . . 53 160 9.7. Transfer-Encoding . . . . . . . . . . . . . . . . . . . . 54 161 9.8. Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . 54 162 9.8.1. Upgrade Token Registry . . . . . . . . . . . . . . . . 55 163 9.9. Via . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 164 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 58 165 10.1. Message Header Registration . . . . . . . . . . . . . . . 58 166 10.2. URI Scheme Registration . . . . . . . . . . . . . . . . . 58 167 10.3. Internet Media Type Registrations . . . . . . . . . . . . 58 168 10.3.1. Internet Media Type message/http . . . . . . . . . . . 58 169 10.3.2. Internet Media Type application/http . . . . . . . . . 60 170 10.4. Transfer Coding Registry . . . . . . . . . . . . . . . . . 61 171 10.5. Upgrade Token Registration . . . . . . . . . . . . . . . . 61 172 11. Security Considerations . . . . . . . . . . . . . . . . . . . 61 173 11.1. Personal Information . . . . . . . . . . . . . . . . . . . 62 174 11.2. Abuse of Server Log Information . . . . . . . . . . . . . 62 175 11.3. Attacks Based On File and Path Names . . . . . . . . . . . 62 176 11.4. DNS Spoofing . . . . . . . . . . . . . . . . . . . . . . . 62 177 11.5. Proxies and Caching . . . . . . . . . . . . . . . . . . . 63 178 11.6. Denial of Service Attacks on Proxies . . . . . . . . . . . 64 179 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 64 180 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 65 181 13.1. Normative References . . . . . . . . . . . . . . . . . . . 65 182 13.2. Informative References . . . . . . . . . . . . . . . . . . 67 183 Appendix A. Tolerant Applications . . . . . . . . . . . . . . . . 69 184 Appendix B. Compatibility with Previous Versions . . . . . . . . 70 185 B.1. Changes from HTTP/1.0 . . . . . . . . . . . . . . . . . . 71 186 B.1.1. Changes to Simplify Multi-homed Web Servers and 187 Conserve IP Addresses . . . . . . . . . . . . . . . . 71 188 B.2. Compatibility with HTTP/1.0 Persistent Connections . . . . 71 189 B.3. Changes from RFC 2068 . . . . . . . . . . . . . . . . . . 72 190 B.4. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 73 191 Appendix C. Collected ABNF . . . . . . . . . . . . . . . . . . . 73 192 Appendix D. Change Log (to be removed by RFC Editor before 193 publication) . . . . . . . . . . . . . . . . . . . . 78 195 D.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 78 196 D.2. Since draft-ietf-httpbis-p1-messaging-00 . . . . . . . . . 78 197 D.3. Since draft-ietf-httpbis-p1-messaging-01 . . . . . . . . . 80 198 D.4. Since draft-ietf-httpbis-p1-messaging-02 . . . . . . . . . 81 199 D.5. Since draft-ietf-httpbis-p1-messaging-03 . . . . . . . . . 81 200 D.6. Since draft-ietf-httpbis-p1-messaging-04 . . . . . . . . . 82 201 D.7. Since draft-ietf-httpbis-p1-messaging-05 . . . . . . . . . 82 202 D.8. Since draft-ietf-httpbis-p1-messaging-06 . . . . . . . . . 83 203 D.9. Since draft-ietf-httpbis-p1-messaging-07 . . . . . . . . . 84 204 D.10. Since draft-ietf-httpbis-p1-messaging-08 . . . . . . . . . 84 205 D.11. Since draft-ietf-httpbis-p1-messaging-09 . . . . . . . . . 85 206 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 208 1. Introduction 210 The Hypertext Transfer Protocol (HTTP) is an application-level 211 request/response protocol that uses extensible semantics and MIME- 212 like message payloads for flexible interaction with network-based 213 hypertext information systems. HTTP relies upon the Uniform Resource 214 Identifier (URI) standard [RFC3986] to indicate request targets and 215 relationships between resources. Messages are passed in a format 216 similar to that used by Internet mail [RFC5322] and the Multipurpose 217 Internet Mail Extensions (MIME) [RFC2045] (see Appendix A of [Part3] 218 for the differences between HTTP and MIME messages). 220 HTTP is a generic interface protocol for information systems. It is 221 designed to hide the details of how a service is implemented by 222 presenting a uniform interface to clients that is independent of the 223 types of resources provided. Likewise, servers do not need to be 224 aware of each client's purpose: an HTTP request can be considered in 225 isolation rather than being associated with a specific type of client 226 or a predetermined sequence of application steps. The result is a 227 protocol that can be used effectively in many different contexts and 228 for which implementations can evolve independently over time. 230 HTTP is also designed for use as a generic protocol for translating 231 communication to and from other Internet information systems. HTTP 232 proxies and gateways provide access to alternative information 233 services by translating their diverse protocols into a hypertext 234 format that can be viewed and manipulated by clients in the same way 235 as HTTP services. 237 One consequence of HTTP flexibility is that the protocol cannot be 238 defined in terms of what occurs behind the interface. Instead, we 239 are limited to defining the syntax of communication, the intent of 240 received communication, and the expected behavior of recipients. If 241 the communication is considered in isolation, then successful actions 242 should be reflected in corresponding changes to the observable 243 interface provided by servers. However, since multiple clients may 244 act in parallel and perhaps at cross-purposes, we cannot require that 245 such changes be observable beyond the scope of a single response. 247 This document is Part 1 of the seven-part specification of HTTP, 248 defining the protocol referred to as "HTTP/1.1" and obsoleting 249 [RFC2616]. Part 1 describes the architectural elements that are used 250 or referred to in HTTP, defines the "http" and "https" URI schemes, 251 describes overall network operation and connection management, and 252 defines HTTP message framing and forwarding requirements. Our goal 253 is to define all of the mechanisms necessary for HTTP message 254 handling that are independent of message semantics, thereby defining 255 the complete set of requirements for message parsers and message- 256 forwarding intermediaries. 258 1.1. Requirements 260 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 261 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 262 document are to be interpreted as described in [RFC2119]. 264 An implementation is not compliant if it fails to satisfy one or more 265 of the "MUST" or "REQUIRED" level requirements for the protocols it 266 implements. An implementation that satisfies all the "MUST" or 267 "REQUIRED" level and all the "SHOULD" level requirements for its 268 protocols is said to be "unconditionally compliant"; one that 269 satisfies all the "MUST" level requirements but not all the "SHOULD" 270 level requirements for its protocols is said to be "conditionally 271 compliant". 273 1.2. Syntax Notation 275 This specification uses the Augmented Backus-Naur Form (ABNF) 276 notation of [RFC5234]. 278 The following core rules are included by reference, as defined in 279 [RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF 280 (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote), 281 HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any 8-bit 282 sequence of data), SP (space), VCHAR (any visible [USASCII] 283 character), and WSP (whitespace). 285 As a syntactical convention, ABNF rule names prefixed with "obs-" 286 denote "obsolete" grammar rules that appear for historical reasons. 288 1.2.1. ABNF Extension: #rule 290 The #rule extension to the ABNF rules of [RFC5234] is used to improve 291 readability. 293 A construct "#" is defined, similar to "*", for defining comma- 294 delimited lists of elements. The full form is "#element" 295 indicating at least and at most elements, each separated by a 296 single comma (",") and optional whitespace (OWS, Section 1.2.2). 298 Thus, 300 1#element => element *( OWS "," OWS element ) 302 and: 304 #element => [ 1#element ] 306 and for n >= 1 and m > 1: 308 #element => element *( OWS "," OWS element ) 310 For compatibility with legacy list rules, recipients SHOULD accept 311 empty list elements. In other words, consumers would follow the list 312 productions: 314 #element => [ ( "," / element ) *( OWS "," [ OWS element ] ) ] 316 1#element => *( "," OWS ) element *( OWS "," [ OWS element ] ) 318 Note that empty elements do not contribute to the count of elements 319 present, though. 321 For example, given these ABNF productions: 323 example-list = 1#example-list-elmt 324 example-list-elmt = token ; see Section 1.2.2 326 Then these are valid values for example-list (not including the 327 double quotes, which are present for delimitation only): 329 "foo,bar" 330 " foo ,bar," 331 " foo , ,bar,charlie " 332 "foo ,bar, charlie " 334 But these values would be invalid, as at least one non-empty element 335 is required: 337 "" 338 "," 339 ", ," 341 Appendix C shows the collected ABNF, with the list rules expanded as 342 explained above. 344 1.2.2. Basic Rules 346 HTTP/1.1 defines the sequence CR LF as the end-of-line marker for all 347 protocol elements except the entity-body (see Appendix A for tolerant 348 applications). The end-of-line marker within an entity-body is 349 defined by its associated media type, as described in Section 2.3 of 351 [Part3]. 353 This specification uses three rules to denote the use of linear 354 whitespace: OWS (optional whitespace), RWS (required whitespace), and 355 BWS ("bad" whitespace). 357 The OWS rule is used where zero or more linear whitespace characters 358 may appear. OWS SHOULD either not be produced or be produced as a 359 single SP character. Multiple OWS characters that occur within 360 field-content SHOULD be replaced with a single SP before interpreting 361 the field value or forwarding the message downstream. 363 RWS is used when at least one linear whitespace character is required 364 to separate field tokens. RWS SHOULD be produced as a single SP 365 character. Multiple RWS characters that occur within field-content 366 SHOULD be replaced with a single SP before interpreting the field 367 value or forwarding the message downstream. 369 BWS is used where the grammar allows optional whitespace for 370 historical reasons but senders SHOULD NOT produce it in messages. 371 HTTP/1.1 recipients MUST accept such bad optional whitespace and 372 remove it before interpreting the field value or forwarding the 373 message downstream. 375 OWS = *( [ obs-fold ] WSP ) 376 ; "optional" whitespace 377 RWS = 1*( [ obs-fold ] WSP ) 378 ; "required" whitespace 379 BWS = OWS 380 ; "bad" whitespace 381 obs-fold = CRLF 382 ; see Section 3.2 384 Many HTTP/1.1 header field values consist of words (token or quoted- 385 string) separated by whitespace or special characters. These special 386 characters MUST be in a quoted string to be used within a parameter 387 value (as defined in Section 6.2). 389 word = token / quoted-string 391 token = 1*tchar 393 tchar = "!" / "#" / "$" / "%" / "&" / "'" / "*" 394 / "+" / "-" / "." / "^" / "_" / "`" / "|" / "~" 395 / DIGIT / ALPHA 396 ; any VCHAR, except special 398 special = "(" / ")" / "<" / ">" / "@" / "," 399 / ";" / ":" / "\" / DQUOTE / "/" / "[" 400 / "]" / "?" / "=" / "{" / "}" 402 A string of text is parsed as a single word if it is quoted using 403 double-quote marks. 405 quoted-string = DQUOTE *( qdtext / quoted-pair ) DQUOTE 406 qdtext = OWS / %x21 / %x23-5B / %x5D-7E / obs-text 407 ; OWS / / obs-text 408 obs-text = %x80-FF 410 The backslash character ("\") can be used as a single-character 411 quoting mechanism within quoted-string constructs: 413 quoted-pair = "\" ( WSP / VCHAR / obs-text ) 415 Producers SHOULD NOT escape characters that do not require escaping 416 (i.e., other than DQUOTE and the backslash character). 418 1.2.3. ABNF Rules defined in other Parts of the Specification 420 The ABNF rules below are defined in other parts: 422 request-header = 423 response-header = 425 entity-body = 426 entity-header = 428 Cache-Control = 429 Pragma = 430 Warning = 432 2. HTTP architecture 434 HTTP was created for the World Wide Web architecture and has evolved 435 over time to support the scalability needs of a worldwide hypertext 436 system. Much of that architecture is reflected in the terminology 437 and syntax productions used to define HTTP. 439 2.1. Client/Server Operation 441 HTTP is a request/response protocol that operates by exchanging 442 messages across a reliable transport or session-layer connection. An 443 HTTP client is a program that establishes a connection to a server 444 for the purpose of sending one or more HTTP requests. An HTTP server 445 is a program that accepts connections in order to service HTTP 446 requests by sending HTTP responses. 448 Note that the terms "client" and "server" refer only to the roles 449 that these programs perform for a particular connection. The same 450 program may act as a client on some connections and a server on 451 others. We use the term "user agent" to refer to the program that 452 initiates a request, such as a WWW browser, editor, or spider (web- 453 traversing robot), and the term "origin server" to refer to the 454 program that can originate authoritative responses to a request. 456 Most HTTP communication consists of a retrieval request (GET) for a 457 representation of some resource identified by a URI. In the simplest 458 case, this may be accomplished via a single connection (v) between 459 the user agent (UA) and the origin server (O). 461 request chain ------------------------> 462 UA -------------------v------------------- O 463 <----------------------- response chain 465 A client sends an HTTP request to the server in the form of a request 466 message (Section 4), beginning with a method, URI, and protocol 467 version, followed by MIME-like header fields containing request 468 modifiers, client information, and payload metadata, an empty line to 469 indicate the end of the header section, and finally the payload body 470 (if any). 472 A server responds to the client's request by sending an HTTP response 473 message (Section 5), beginning with a status line that includes the 474 protocol version, a success or error code, and textual reason phrase, 475 followed by MIME-like header fields containing server information, 476 resource metadata, and payload metadata, an empty line to indicate 477 the end of the header section, and finally the payload body (if any). 479 The following example illustrates a typical message exchange for a 480 GET request on the URI "http://www.example.com/hello.txt": 482 client request: 484 GET /hello.txt HTTP/1.1 485 User-Agent: curl/7.16.3 libcurl/7.16.3 OpenSSL/0.9.7l zlib/1.2.3 486 Host: www.example.com 487 Accept: */* 489 server response: 491 HTTP/1.1 200 OK 492 Date: Mon, 27 Jul 2009 12:28:53 GMT 493 Server: Apache 494 Last-Modified: Wed, 22 Jul 2009 19:15:56 GMT 495 ETag: "34aa387-d-1568eb00" 496 Accept-Ranges: bytes 497 Content-Length: 14 498 Vary: Accept-Encoding 499 Content-Type: text/plain 501 Hello World! 503 2.2. Intermediaries 505 A more complicated situation occurs when one or more intermediaries 506 are present in the request/response chain. There are three common 507 forms of intermediary: proxy, gateway, and tunnel. In some cases, a 508 single intermediary may act as an origin server, proxy, gateway, or 509 tunnel, switching behavior based on the nature of each request. 511 request chain --------------------------------------> 512 UA -----v----- A -----v----- B -----v----- C -----v----- O 513 <------------------------------------- response chain 515 The figure above shows three intermediaries (A, B, and C) between the 516 user agent and origin server. A request or response message that 517 travels the whole chain will pass through four separate connections. 518 Some HTTP communication options may apply only to the connection with 519 the nearest, non-tunnel neighbor, only to the end-points of the 520 chain, or to all connections along the chain. Although the diagram 521 is linear, each participant may be engaged in multiple, simultaneous 522 communications. For example, B may be receiving requests from many 523 clients other than A, and/or forwarding requests to servers other 524 than C, at the same time that it is handling A's request. 526 We use the terms "upstream" and "downstream" to describe various 527 requirements in relation to the directional flow of a message: all 528 messages flow from upstream to downstream. Likewise, we use the 529 terms "inbound" and "outbound" to refer to directions in relation to 530 the request path: "inbound" means toward the origin server and 531 "outbound" means toward the user agent. 533 A proxy is a message forwarding agent that is selected by the client, 534 usually via local configuration rules, to receive requests for some 535 type(s) of absolute URI and attempt to satisfy those requests via 536 translation through the HTTP interface. Some translations are 537 minimal, such as for proxy requests for "http" URIs, whereas other 538 requests may require translation to and from entirely different 539 application-layer protocols. Proxies are often used to group an 540 organization's HTTP requests through a common intermediary for the 541 sake of security, annotation services, or shared caching. 543 A gateway (a.k.a., reverse proxy) is a receiving agent that acts as a 544 layer above some other server(s) and translates the received requests 545 to the underlying server's protocol. Gateways are often used for 546 load balancing or partitioning HTTP services across multiple 547 machines. Unlike a proxy, a gateway receives requests as if it were 548 the origin server for the requested resource; the requesting client 549 will not be aware that it is communicating with a gateway. A gateway 550 communicates with the client as if the gateway is the origin server 551 and thus is subject to all of the requirements on origin servers for 552 that connection. A gateway communicates with inbound servers using 553 any protocol it desires, including private extensions to HTTP that 554 are outside the scope of this specification. 556 A tunnel acts as a blind relay between two connections without 557 changing the messages. Once active, a tunnel is not considered a 558 party to the HTTP communication, though the tunnel may have been 559 initiated by an HTTP request. A tunnel ceases to exist when both 560 ends of the relayed connection are closed. Tunnels are used to 561 extend a virtual connection through an intermediary, such as when 562 transport-layer security is used to establish private communication 563 through a shared firewall proxy. 565 2.3. Caches 567 Any party to HTTP communication that is not acting as a tunnel may 568 employ an internal cache for handling requests. A cache is a local 569 store of previous response messages and the subsystem that controls 570 its message storage, retrieval, and deletion. A cache stores 571 cacheable responses in order to reduce the response time and network 572 bandwidth consumption on future, equivalent requests. Any client or 573 server may include a cache, though a cache cannot be used by a server 574 while it is acting as a tunnel. 576 The effect of a cache is that the request/response chain is shortened 577 if one of the participants along the chain has a cached response 578 applicable to that request. The following illustrates the resulting 579 chain if B has a cached copy of an earlier response from O (via C) 580 for a request which has not been cached by UA or A. 582 request chain ----------> 583 UA -----v----- A -----v----- B - - - - - - C - - - - - - O 584 <--------- response chain 586 A response is cacheable if a cache is allowed to store a copy of the 587 response message for use in answering subsequent requests. Even when 588 a response is cacheable, there may be additional constraints placed 589 by the client or by the origin server on when that cached response 590 can be used for a particular request. HTTP requirements for cache 591 behavior and cacheable responses are defined in Section 2 of [Part6]. 593 There are a wide variety of architectures and configurations of 594 caches and proxies deployed across the World Wide Web and inside 595 large organizations. These systems include national hierarchies of 596 proxy caches to save transoceanic bandwidth, systems that broadcast 597 or multicast cache entries, organizations that distribute subsets of 598 cached data via optical media, and so on. 600 2.4. Transport Independence 602 HTTP systems are used in a wide variety of environments, from 603 corporate intranets with high-bandwidth links to long-distance 604 communication over low-power radio links and intermittent 605 connectivity. 607 HTTP communication usually takes place over TCP/IP connections. The 608 default port is TCP 80 609 (), but other ports can 610 be used. This does not preclude HTTP from being implemented on top 611 of any other protocol on the Internet, or on other networks. HTTP 612 only presumes a reliable transport; any protocol that provides such 613 guarantees can be used; the mapping of the HTTP/1.1 request and 614 response structures onto the transport data units of the protocol in 615 question is outside the scope of this specification. 617 In HTTP/1.0, most implementations used a new connection for each 618 request/response exchange. In HTTP/1.1, a connection may be used for 619 one or more request/response exchanges, although connections may be 620 closed for a variety of reasons (see Section 7.1). 622 2.5. HTTP Version 624 HTTP uses a "." numbering scheme to indicate versions 625 of the protocol. The protocol versioning policy is intended to allow 626 the sender to indicate the format of a message and its capacity for 627 understanding further HTTP communication, rather than the features 628 obtained via that communication. No change is made to the version 629 number for the addition of message components which do not affect 630 communication behavior or which only add to extensible field values. 631 The number is incremented when the changes made to the 632 protocol add features which do not change the general message parsing 633 algorithm, but which may add to the message semantics and imply 634 additional capabilities of the sender. The number is 635 incremented when the format of a message within the protocol is 636 changed. See [RFC2145] for a fuller explanation. 638 The version of an HTTP message is indicated by an HTTP-Version field 639 in the first line of the message. HTTP-Version is case-sensitive. 641 HTTP-Version = HTTP-Prot-Name "/" 1*DIGIT "." 1*DIGIT 642 HTTP-Prot-Name = %x48.54.54.50 ; "HTTP", case-sensitive 644 Note that the major and minor numbers MUST be treated as separate 645 integers and that each MAY be incremented higher than a single digit. 646 Thus, HTTP/2.4 is a lower version than HTTP/2.13, which in turn is 647 lower than HTTP/12.3. Leading zeros MUST be ignored by recipients 648 and MUST NOT be sent. 650 An application that sends a request or response message that includes 651 HTTP-Version of "HTTP/1.1" MUST be at least conditionally compliant 652 with this specification. Applications that are at least 653 conditionally compliant with this specification SHOULD use an HTTP- 654 Version of "HTTP/1.1" in their messages, and MUST do so for any 655 message that is not compatible with HTTP/1.0. For more details on 656 when to send specific HTTP-Version values, see [RFC2145]. 658 The HTTP version of an application is the highest HTTP version for 659 which the application is at least conditionally compliant. 661 Proxy and gateway applications need to be careful when forwarding 662 messages in protocol versions different from that of the application. 663 Since the protocol version indicates the protocol capability of the 664 sender, a proxy/gateway MUST NOT send a message with a version 665 indicator which is greater than its actual version. If a higher 666 version request is received, the proxy/gateway MUST either downgrade 667 the request version, or respond with an error, or switch to tunnel 668 behavior. 670 Due to interoperability problems with HTTP/1.0 proxies discovered 671 since the publication of [RFC2068], caching proxies MUST, gateways 672 MAY, and tunnels MUST NOT upgrade the request to the highest version 673 they support. The proxy/gateway's response to that request MUST be 674 in the same major version as the request. 676 Note: Converting between versions of HTTP may involve modification 677 of header fields required or forbidden by the versions involved. 679 2.6. Uniform Resource Identifiers 681 Uniform Resource Identifiers (URIs) [RFC3986] are used throughout 682 HTTP as the means for identifying resources. URI references are used 683 to target requests, indicate redirects, and define relationships. 684 HTTP does not limit what a resource may be; it merely defines an 685 interface that can be used to interact with a resource via HTTP. 686 More information on the scope of URIs and resources can be found in 687 [RFC3986]. 689 This specification adopts the definitions of "URI-reference", 690 "absolute-URI", "relative-part", "port", "host", "path-abempty", 691 "path-absolute", "query", and "authority" from [RFC3986]. In 692 addition, we define a partial-URI rule for protocol elements that 693 allow a relative URI without a fragment. 695 URI-reference = 696 absolute-URI = 697 relative-part = 698 authority = 699 path-abempty = 700 path-absolute = 701 port = 702 query = 703 uri-host = 705 partial-URI = relative-part [ "?" query ] 707 Each protocol element in HTTP that allows a URI reference will 708 indicate in its ABNF production whether the element allows only a URI 709 in absolute form (absolute-URI), any relative reference (relative- 710 ref), or some other subset of the URI-reference grammar. Unless 711 otherwise indicated, URI references are parsed relative to the 712 request target (the default base URI for both the request and its 713 corresponding response). 715 2.6.1. http URI scheme 717 The "http" URI scheme is hereby defined for the purpose of minting 718 identifiers according to their association with the hierarchical 719 namespace governed by a potential HTTP origin server listening for 720 TCP connections on a given port. The HTTP server is identified via 721 the generic syntax's authority component, which includes a host 722 identifier and optional TCP port, and the remainder of the URI is 723 considered to be identifying data corresponding to a resource for 724 which that server might provide an HTTP interface. 726 http-URI = "http:" "//" authority path-abempty [ "?" query ] 728 The host identifier within an authority component is defined in 729 [RFC3986], Section 3.2.2. If host is provided as an IP literal or 730 IPv4 address, then the HTTP server is any listener on the indicated 731 TCP port at that IP address. If host is a registered name, then that 732 name is considered an indirect identifier and the recipient might use 733 a name resolution service, such as DNS, to find the address of a 734 listener for that host. The host MUST NOT be empty; if an "http" URI 735 is received with an empty host, then it MUST be rejected as invalid. 736 If the port subcomponent is empty or not given, then TCP port 80 is 737 assumed (the default reserved port for WWW services). 739 Regardless of the form of host identifier, access to that host is not 740 implied by the mere presence of its name or address. The host may or 741 may not exist and, even when it does exist, may or may not be running 742 an HTTP server or listening to the indicated port. The "http" URI 743 scheme makes use of the delegated nature of Internet names and 744 addresses to establish a naming authority (whatever entity has the 745 ability to place an HTTP server at that Internet name or address) and 746 allows that authority to determine which names are valid and how they 747 might be used. 749 When an "http" URI is used within a context that calls for access to 750 the indicated resource, a client MAY attempt access by resolving the 751 host to an IP address, establishing a TCP connection to that address 752 on the indicated port, and sending an HTTP request message to the 753 server containing the URI's identifying data as described in 754 Section 4. If the server responds to that request with a non-interim 755 HTTP response message, as described in Section 5, then that response 756 is considered an authoritative answer to the client's request. 758 Although HTTP is independent of the transport protocol, the "http" 759 scheme is specific to TCP-based services because the name delegation 760 process depends on TCP for establishing authority. An HTTP service 761 based on some other underlying connection protocol would presumably 762 be identified using a different URI scheme, just as the "https" 763 scheme (below) is used for servers that require an SSL/TLS transport 764 layer on a connection. Other protocols may also be used to provide 765 access to "http" identified resources --- it is only the 766 authoritative interface used for mapping the namespace that is 767 specific to TCP. 769 2.6.2. https URI scheme 771 The "https" URI scheme is hereby defined for the purpose of minting 772 identifiers according to their association with the hierarchical 773 namespace governed by a potential HTTP origin server listening for 774 SSL/TLS-secured connections on a given TCP port. The host and port 775 are determined in the same way as for the "http" scheme, except that 776 a default TCP port of 443 is assumed if the port subcomponent is 777 empty or not given. 779 https-URI = "https:" "//" authority path-abempty [ "?" query ] 781 The primary difference between the "http" and "https" schemes is that 782 interaction with the latter is required to be secured for privacy 783 through the use of strong encryption. The URI cannot be sent in a 784 request until the connection is secure. Likewise, the default for 785 caching is that each response that would be considered "public" under 786 the "http" scheme is instead treated as "private" and thus not 787 eligible for shared caching. 789 The process for authoritative access to an "https" identified 790 resource is defined in [RFC2818]. 792 2.6.3. http and https URI Normalization and Comparison 794 Since the "http" and "https" schemes conform to the URI generic 795 syntax, such URIs are normalized and compared according to the 796 algorithm defined in [RFC3986], Section 6, using the defaults 797 described above for each scheme. 799 If the port is equal to the default port for a scheme, the normal 800 form is to elide the port subcomponent. Likewise, an empty path 801 component is equivalent to an absolute path of "/", so the normal 802 form is to provide a path of "/" instead. The scheme and host are 803 case-insensitive and normally provided in lowercase; all other 804 components are compared in a case-sensitive manner. Characters other 805 than those in the "reserved" set are equivalent to their percent- 806 encoded octets (see [RFC3986], Section 2.1): the normal form is to 807 not encode them. 809 For example, the following three URIs are equivalent: 811 http://example.com:80/~smith/home.html 812 http://EXAMPLE.com/%7Esmith/home.html 813 http://EXAMPLE.com:/%7esmith/home.html 815 [[TODO-not-here: This paragraph does not belong here. --roy]] If 816 path-abempty is the empty string (i.e., there is no slash "/" path 817 separator following the authority), then the "http" URI MUST be given 818 as "/" when used as a request-target (Section 4.1.2). If a proxy 819 receives a host name which is not a fully qualified domain name, it 820 MAY add its domain to the host name it received. If a proxy receives 821 a fully qualified domain name, the proxy MUST NOT change the host 822 name. 824 3. HTTP Message 826 All HTTP/1.1 messages consist of a start-line followed by a sequence 827 of characters in a format similar to the Internet Message Format 828 [RFC5322]: zero or more header fields (collectively referred to as 829 the "headers" or the "header section"), an empty line indicating the 830 end of the header section, and an optional message-body. 832 An HTTP message can either be a request from client to server or a 833 response from server to client. Syntactically, the two types of 834 message differ only in the start-line, which is either a Request-Line 835 (for requests) or a Status-Line (for responses), and in the algorithm 836 for determining the length of the message-body (Section 3.4). In 837 theory, a client could receive requests and a server could receive 838 responses, distinguishing them by their different start-line formats, 839 but in practice servers are implemented to only expect a request (a 840 response is interpreted as an unknown or invalid request method) and 841 clients are implemented to only expect a response. 843 HTTP-message = start-line 844 *( header-field CRLF ) 845 CRLF 846 [ message-body ] 847 start-line = Request-Line / Status-Line 849 Whitespace (WSP) MUST NOT be sent between the start-line and the 850 first header field. The presence of whitespace might be an attempt 851 to trick a noncompliant implementation of HTTP into ignoring that 852 field or processing the next line as a new request, either of which 853 may result in security issues when implementations within the request 854 chain interpret the same message differently. HTTP/1.1 servers MUST 855 reject such a message with a 400 (Bad Request) response. 857 3.1. Message Parsing Robustness 859 In the interest of robustness, servers SHOULD ignore at least one 860 empty line received where a Request-Line is expected. In other 861 words, if the server is reading the protocol stream at the beginning 862 of a message and receives a CRLF first, it should ignore the CRLF. 864 Some old HTTP/1.0 client implementations generate an extra CRLF after 865 a POST request as a lame workaround for some early server 866 applications that failed to read message-body content that was not 867 terminated by a line-ending. An HTTP/1.1 client MUST NOT preface or 868 follow a request with an extra CRLF. If terminating the request 869 message-body with a line-ending is desired, then the client MUST 870 include the terminating CRLF octets as part of the message-body 871 length. 873 The normal procedure for parsing an HTTP message is to read the 874 start-line into a structure, read each header field into a hash table 875 by field name until the empty line, and then use the parsed data to 876 determine if a message-body is expected. If a message-body has been 877 indicated, then it is read as a stream until an amount of OCTETs 878 equal to the message-length is read or the connection is closed. 879 Care must be taken to parse an HTTP message as a sequence of OCTETs 880 in an encoding that is a superset of US-ASCII. Attempting to parse 881 HTTP as a stream of Unicode characters in a character encoding like 882 UTF-16 may introduce security flaws due to the differing ways that 883 such parsers interpret invalid characters. 885 3.2. Header Fields 887 Each HTTP header field consists of a case-insensitive field name 888 followed by a colon (":"), optional whitespace, and the field value. 890 header-field = field-name ":" OWS [ field-value ] OWS 891 field-name = token 892 field-value = *( field-content / OWS ) 893 field-content = *( WSP / VCHAR / obs-text ) 895 No whitespace is allowed between the header field name and colon. 896 For security reasons, any request message received containing such 897 whitespace MUST be rejected with a response code of 400 (Bad 898 Request). A proxy MUST remove any such whitespace from a response 899 message before forwarding the message downstream. 901 A field value MAY be preceded by optional whitespace (OWS); a single 902 SP is preferred. The field value does not include any leading or 903 trailing white space: OWS occurring before the first non-whitespace 904 character of the field value or after the last non-whitespace 905 character of the field value is ignored and SHOULD be removed before 906 further processing (as this does not change the meaning of the header 907 field). 909 The order in which header fields with differing field names are 910 received is not significant. However, it is "good practice" to send 911 header fields that contain control data first, such as Host on 912 requests and Date on responses, so that implementations can decide 913 when not to handle a message as early as possible. A server MUST 914 wait until the entire header section is received before interpreting 915 a request message, since later header fields might include 916 conditionals, authentication credentials, or deliberately misleading 917 duplicate header fields that would impact request processing. 919 Multiple header fields with the same field name MUST NOT be sent in a 920 message unless the entire field value for that header field is 921 defined as a comma-separated list [i.e., #(values)]. Multiple header 922 fields with the same field name can be combined into one "field-name: 923 field-value" pair, without changing the semantics of the message, by 924 appending each subsequent field value to the combined field value in 925 order, separated by a comma. The order in which header fields with 926 the same field name are received is therefore significant to the 927 interpretation of the combined field value; a proxy MUST NOT change 928 the order of these field values when forwarding a message. 930 Note: The "Set-Cookie" header as implemented in practice (as 931 opposed to how it is specified in [RFC2109]) can occur multiple 932 times, but does not use the list syntax, and thus cannot be 933 combined into a single line. (See Appendix A.2.3 of [Kri2001] for 934 details.) Also note that the Set-Cookie2 header specified in 935 [RFC2965] does not share this problem. 937 Historically, HTTP header field values could be extended over 938 multiple lines by preceding each extra line with at least one space 939 or horizontal tab character (line folding). This specification 940 deprecates such line folding except within the message/http media 941 type (Section 10.3.1). HTTP/1.1 senders MUST NOT produce messages 942 that include line folding (i.e., that contain any field-content that 943 matches the obs-fold rule) unless the message is intended for 944 packaging within the message/http media type. HTTP/1.1 recipients 945 SHOULD accept line folding and replace any embedded obs-fold 946 whitespace with a single SP prior to interpreting the field value or 947 forwarding the message downstream. 949 Historically, HTTP has allowed field content with text in the ISO- 950 8859-1 [ISO-8859-1] character encoding and supported other character 951 sets only through use of [RFC2047] encoding. In practice, most HTTP 952 header field values use only a subset of the US-ASCII character 953 encoding [USASCII]. Newly defined header fields SHOULD limit their 954 field values to US-ASCII characters. Recipients SHOULD treat other 955 (obs-text) octets in field content as opaque data. 957 Comments can be included in some HTTP header fields by surrounding 958 the comment text with parentheses. Comments are only allowed in 959 fields containing "comment" as part of their field value definition. 961 comment = "(" *( ctext / quoted-cpair / comment ) ")" 962 ctext = OWS / %x21-27 / %x2A-5B / %x5D-7E / obs-text 963 ; OWS / / obs-text 965 The backslash character ("\") can be used as a single-character 966 quoting mechanism within comment constructs: 968 quoted-cpair = "\" ( WSP / VCHAR / obs-text ) 970 Producers SHOULD NOT escape characters that do not require escaping 971 (i.e., other than the backslash character "\" and the parentheses "(" 972 and ")"). 974 3.3. Message Body 976 The message-body (if any) of an HTTP message is used to carry the 977 entity-body associated with the request or response. The message- 978 body differs from the entity-body only when a transfer-coding has 979 been applied, as indicated by the Transfer-Encoding header field 980 (Section 9.7). 982 message-body = entity-body 983 / 985 Transfer-Encoding MUST be used to indicate any transfer-codings 986 applied by an application to ensure safe and proper transfer of the 987 message. Transfer-Encoding is a property of the message, not of the 988 entity, and thus MAY be added or removed by any application along the 989 request/response chain. (However, Section 6.2 places restrictions on 990 when certain transfer-codings may be used.) 992 The rules for when a message-body is allowed in a message differ for 993 requests and responses. 995 The presence of a message-body in a request is signaled by the 996 inclusion of a Content-Length or Transfer-Encoding header field in 997 the request's header fields. When a request message contains both a 998 message-body of non-zero length and a method that does not define any 999 semantics for that request message-body, then an origin server SHOULD 1000 either ignore the message-body or respond with an appropriate error 1001 message (e.g., 413). A proxy or gateway, when presented the same 1002 request, SHOULD either forward the request inbound with the message- 1003 body or ignore the message-body when determining a response. 1005 For response messages, whether or not a message-body is included with 1006 a message is dependent on both the request method and the response 1007 status code (Section 5.1.1). All responses to the HEAD request 1008 method MUST NOT include a message-body, even though the presence of 1009 entity-header fields might lead one to believe they do. All 1xx 1010 (Informational), 204 (No Content), and 304 (Not Modified) responses 1011 MUST NOT include a message-body. All other responses do include a 1012 message-body, although it MAY be of zero length. 1014 3.4. Message Length 1016 The transfer-length of a message is the length of the message-body as 1017 it appears in the message; that is, after any transfer-codings have 1018 been applied. When a message-body is included with a message, the 1019 transfer-length of that body is determined by one of the following 1020 (in order of precedence): 1022 1. Any response message which "MUST NOT" include a message-body 1023 (such as the 1xx, 204, and 304 responses and any response to a 1024 HEAD request) is always terminated by the first empty line after 1025 the header fields, regardless of the entity-header fields present 1026 in the message. 1028 2. If a Transfer-Encoding header field (Section 9.7) is present and 1029 the "chunked" transfer-coding (Section 6.2) is used, the 1030 transfer-length is defined by the use of this transfer-coding. 1031 If a Transfer-Encoding header field is present and the "chunked" 1032 transfer-coding is not present, the transfer-length is defined by 1033 the sender closing the connection. 1035 3. If a Content-Length header field (Section 9.2) is present, its 1036 value in OCTETs represents both the entity-length and the 1037 transfer-length. The Content-Length header field MUST NOT be 1038 sent if these two lengths are different (i.e., if a Transfer- 1039 Encoding header field is present). If a message is received with 1040 both a Transfer-Encoding header field and a Content-Length header 1041 field, the latter MUST be ignored. 1043 4. If the message uses the media type "multipart/byteranges", and 1044 the transfer-length is not otherwise specified, then this self- 1045 delimiting media type defines the transfer-length. This media 1046 type MUST NOT be used unless the sender knows that the recipient 1047 can parse it; the presence in a request of a Range header with 1048 multiple byte-range specifiers from a HTTP/1.1 client implies 1049 that the client can parse multipart/byteranges responses. 1051 A range header might be forwarded by a HTTP/1.0 proxy that 1052 does not understand multipart/byteranges; in this case the 1053 server MUST delimit the message using methods defined in items 1054 1, 3 or 5 of this section. 1056 5. By the server closing the connection. (Closing the connection 1057 cannot be used to indicate the end of a request body, since that 1058 would leave no possibility for the server to send back a 1059 response.) 1061 For compatibility with HTTP/1.0 applications, HTTP/1.1 requests 1062 containing a message-body MUST include a valid Content-Length header 1063 field unless the server is known to be HTTP/1.1 compliant. If a 1064 request contains a message-body and a Content-Length is not given, 1065 the server SHOULD respond with 400 (Bad Request) if it cannot 1066 determine the length of the message, or with 411 (Length Required) if 1067 it wishes to insist on receiving a valid Content-Length. 1069 All HTTP/1.1 applications that receive entities MUST accept the 1070 "chunked" transfer-coding (Section 6.2), thus allowing this mechanism 1071 to be used for messages when the message length cannot be determined 1072 in advance. 1074 Messages MUST NOT include both a Content-Length header field and a 1075 transfer-coding. If the message does include a transfer-coding, the 1076 Content-Length MUST be ignored. 1078 When a Content-Length is given in a message where a message-body is 1079 allowed, its field value MUST exactly match the number of OCTETs in 1080 the message-body. HTTP/1.1 user agents MUST notify the user when an 1081 invalid length is received and detected. 1083 3.5. General Header Fields 1085 There are a few header fields which have general applicability for 1086 both request and response messages, but which do not apply to the 1087 entity being transferred. These header fields apply only to the 1088 message being transmitted. 1090 general-header = Cache-Control ; [Part6], Section 3.2 1091 / Connection ; Section 9.1 1092 / Date ; Section 9.3 1093 / Pragma ; [Part6], Section 3.4 1094 / Trailer ; Section 9.6 1095 / Transfer-Encoding ; Section 9.7 1096 / Upgrade ; Section 9.8 1097 / Via ; Section 9.9 1098 / Warning ; [Part6], Section 3.6 1100 General-header field names can be extended reliably only in 1101 combination with a change in the protocol version. However, new or 1102 experimental header fields may be given the semantics of general 1103 header fields if all parties in the communication recognize them to 1104 be general-header fields. Unrecognized header fields are treated as 1105 entity-header fields. 1107 4. Request 1109 A request message from a client to a server includes, within the 1110 first line of that message, the method to be applied to the resource, 1111 the identifier of the resource, and the protocol version in use. 1113 Request = Request-Line ; Section 4.1 1114 *(( general-header ; Section 3.5 1115 / request-header ; [Part2], Section 3 1116 / entity-header ) CRLF ) ; [Part3], Section 3.1 1117 CRLF 1118 [ message-body ] ; Section 3.3 1120 4.1. Request-Line 1122 The Request-Line begins with a method token, followed by the request- 1123 target and the protocol version, and ending with CRLF. The elements 1124 are separated by SP characters. No CR or LF is allowed except in the 1125 final CRLF sequence. 1127 Request-Line = Method SP request-target SP HTTP-Version CRLF 1129 4.1.1. Method 1131 The Method token indicates the method to be performed on the resource 1132 identified by the request-target. The method is case-sensitive. 1134 Method = token 1136 4.1.2. request-target 1138 The request-target identifies the resource upon which to apply the 1139 request. 1141 request-target = "*" 1142 / absolute-URI 1143 / ( path-absolute [ "?" query ] ) 1144 / authority 1146 The four options for request-target are dependent on the nature of 1147 the request. 1149 The asterisk "*" means that the request does not apply to a 1150 particular resource, but to the server itself, and is only allowed 1151 when the method used does not necessarily apply to a resource. One 1152 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 "/" or "*". 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 Note: Fragments ([RFC3986], Section 3.5) are not part of the 1235 request-target and thus will not be transmitted in an HTTP 1236 request. 1238 4.2. The Resource Identified by a Request 1240 The exact resource identified by an Internet request is determined by 1241 examining both the request-target and the Host header field. 1243 An origin server that does not allow resources to differ by the 1244 requested host MAY ignore the Host header field value when 1245 determining the resource identified by an HTTP/1.1 request. (But see 1246 Appendix B.1.1 for other requirements on Host support in HTTP/1.1.) 1248 An origin server that does differentiate resources based on the host 1249 requested (sometimes referred to as virtual hosts or vanity host 1250 names) MUST use the following rules for determining the requested 1251 resource on an HTTP/1.1 request: 1253 1. If request-target is an absolute-URI, the host is part of the 1254 request-target. Any Host header field value in the request MUST 1255 be ignored. 1257 2. If the request-target is not an absolute-URI, and the request 1258 includes a Host header field, the host is determined by the Host 1259 header field value. 1261 3. If the host as determined by rule 1 or 2 is not a valid host on 1262 the server, the response MUST be a 400 (Bad Request) error 1263 message. 1265 Recipients of an HTTP/1.0 request that lacks a Host header field MAY 1266 attempt to use heuristics (e.g., examination of the URI path for 1267 something unique to a particular host) in order to determine what 1268 exact resource is being requested. 1270 4.3. Effective Request URI 1272 HTTP requests often do not carry the absolute URI ([RFC3986], Section 1273 4.3) for the resource they are intended for; instead, the value needs 1274 to be inferred from the request-target, Host header and other 1275 context. The result of this process is the "Effective Request URI". 1277 If the request-target is an absolute-URI, then the Effective Request 1278 URI is the request-target. 1280 If the request-target uses the path-absolute (plus optional query) 1281 syntax or if it is just the asterisk "*", then the Effective Request 1282 URI is constructed by concatenating 1284 o the scheme name: "http" if the request was received over an 1285 insecure TCP connection, or "https" when received over SSL/ 1286 TLS-secured TCP connection, 1288 o the character sequence "://", 1290 o the authority component, as specified in the Host header 1291 (Section 9.4) and determined by the rules in Section 4.2, 1292 [[effrequri-nohost: Do we need to include the handling of missing 1293 hosts in HTTP/1.0 messages, as described in Section 4.2? --jre]] 1294 and 1296 o the request-target obtained from the Request-Line, unless the 1297 request-target is just the asterisk "*". 1299 Otherwise, when request-target uses the authority form, the Effective 1300 Request URI is undefined. 1302 Example 1: the Effective Request URI for the message 1304 GET /pub/WWW/TheProject.html HTTP/1.1 1305 Host: www.example.org:8080 1307 (received over an insecure TCP connection) is "http", plus "://", 1308 plus the authority component "www.example.org:8080", plus the 1309 request-target "/pub/WWW/TheProject.html", thus 1310 "http://www.example.org:8080/pub/WWW/TheProject.html". 1312 Example 2: the Effective Request URI for the message 1314 GET * HTTP/1.1 1315 Host: www.example.org 1317 (received over an SSL/TLS secured TCP connection) is "https", plus 1318 "://", plus the authority component "www.example.org", thus 1319 "https://www.example.org". 1321 Effective Request URIs are compared using the rules described in 1322 Section 2.6.3, except that empty path components MUST NOT be treated 1323 as equivalent to an absolute path of "/". 1325 5. Response 1327 After receiving and interpreting a request message, a server responds 1328 with an HTTP response message. 1330 Response = Status-Line ; Section 5.1 1331 *(( general-header ; Section 3.5 1332 / response-header ; [Part2], Section 5 1333 / entity-header ) CRLF ) ; [Part3], Section 3.1 1334 CRLF 1335 [ message-body ] ; Section 3.3 1337 5.1. Status-Line 1339 The first line of a Response message is the Status-Line, consisting 1340 of the protocol version followed by a numeric status code and its 1341 associated textual phrase, with each element separated by SP 1342 characters. No CR or LF is allowed except in the final CRLF 1343 sequence. 1345 Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF 1347 5.1.1. Status Code and Reason Phrase 1349 The Status-Code element is a 3-digit integer result code of the 1350 attempt to understand and satisfy the request. These codes are fully 1351 defined in Section 8 of [Part2]. The Reason Phrase exists for the 1352 sole purpose of providing a textual description associated with the 1353 numeric status code, out of deference to earlier Internet application 1354 protocols that were more frequently used with interactive text 1355 clients. A client SHOULD ignore the content of the Reason Phrase. 1357 The first digit of the Status-Code defines the class of response. 1358 The last two digits do not have any categorization role. There are 5 1359 values for the first digit: 1361 o 1xx: Informational - Request received, continuing process 1363 o 2xx: Success - The action was successfully received, understood, 1364 and accepted 1366 o 3xx: Redirection - Further action must be taken in order to 1367 complete the request 1369 o 4xx: Client Error - The request contains bad syntax or cannot be 1370 fulfilled 1372 o 5xx: Server Error - The server failed to fulfill an apparently 1373 valid request 1375 Status-Code = 3DIGIT 1376 Reason-Phrase = *( WSP / VCHAR / obs-text ) 1378 6. Protocol Parameters 1380 6.1. Date/Time Formats: Full Date 1382 HTTP applications have historically allowed three different formats 1383 for the representation of date/time stamps. 1385 The first format is preferred as an Internet standard and represents 1386 a fixed-length subset of that defined by [RFC1123]: 1388 Sun, 06 Nov 1994 08:49:37 GMT ; RFC 1123 1390 The other formats are described here only for compatibility with 1391 obsolete implementations. 1393 Sunday, 06-Nov-94 08:49:37 GMT ; obsolete RFC 850 format 1394 Sun Nov 6 08:49:37 1994 ; ANSI C's asctime() format 1396 HTTP/1.1 clients and servers that parse the date value MUST accept 1397 all three formats (for compatibility with HTTP/1.0), though they MUST 1398 only generate the RFC 1123 format for representing HTTP-date values 1399 in header fields. See Appendix A for further information. 1401 All HTTP date/time stamps MUST be represented in Greenwich Mean Time 1402 (GMT), without exception. For the purposes of HTTP, GMT is exactly 1403 equal to UTC (Coordinated Universal Time). This is indicated in the 1404 first two formats by the inclusion of "GMT" as the three-letter 1405 abbreviation for time zone, and MUST be assumed when reading the 1406 asctime format. HTTP-date is case sensitive and MUST NOT include 1407 additional whitespace beyond that specifically included as SP in the 1408 grammar. 1410 HTTP-date = rfc1123-date / obs-date 1412 Preferred format: 1414 rfc1123-date = day-name "," SP date1 SP time-of-day SP GMT 1416 day-name = %x4D.6F.6E ; "Mon", case-sensitive 1417 / %x54.75.65 ; "Tue", case-sensitive 1418 / %x57.65.64 ; "Wed", case-sensitive 1419 / %x54.68.75 ; "Thu", case-sensitive 1420 / %x46.72.69 ; "Fri", case-sensitive 1421 / %x53.61.74 ; "Sat", case-sensitive 1422 / %x53.75.6E ; "Sun", case-sensitive 1424 date1 = day SP month SP year 1425 ; e.g., 02 Jun 1982 1427 day = 2DIGIT 1428 month = %x4A.61.6E ; "Jan", case-sensitive 1429 / %x46.65.62 ; "Feb", case-sensitive 1430 / %x4D.61.72 ; "Mar", case-sensitive 1431 / %x41.70.72 ; "Apr", case-sensitive 1432 / %x4D.61.79 ; "May", case-sensitive 1433 / %x4A.75.6E ; "Jun", case-sensitive 1434 / %x4A.75.6C ; "Jul", case-sensitive 1435 / %x41.75.67 ; "Aug", case-sensitive 1436 / %x53.65.70 ; "Sep", case-sensitive 1437 / %x4F.63.74 ; "Oct", case-sensitive 1438 / %x4E.6F.76 ; "Nov", case-sensitive 1439 / %x44.65.63 ; "Dec", case-sensitive 1440 year = 4DIGIT 1442 GMT = %x47.4D.54 ; "GMT", case-sensitive 1444 time-of-day = hour ":" minute ":" second 1445 ; 00:00:00 - 23:59:59 1447 hour = 2DIGIT 1448 minute = 2DIGIT 1449 second = 2DIGIT 1451 The semantics of day-name, day, month, year, and time-of-day are the 1452 same as those defined for the RFC 5322 constructs with the 1453 corresponding name ([RFC5322], Section 3.3). 1455 Obsolete formats: 1457 obs-date = rfc850-date / asctime-date 1458 rfc850-date = day-name-l "," SP date2 SP time-of-day SP GMT 1459 date2 = day "-" month "-" 2DIGIT 1460 ; day-month-year (e.g., 02-Jun-82) 1462 day-name-l = %x4D.6F.6E.64.61.79 ; "Monday", case-sensitive 1463 / %x54.75.65.73.64.61.79 ; "Tuesday", case-sensitive 1464 / %x57.65.64.6E.65.73.64.61.79 ; "Wednesday", case-sensitive 1465 / %x54.68.75.72.73.64.61.79 ; "Thursday", case-sensitive 1466 / %x46.72.69.64.61.79 ; "Friday", case-sensitive 1467 / %x53.61.74.75.72.64.61.79 ; "Saturday", case-sensitive 1468 / %x53.75.6E.64.61.79 ; "Sunday", case-sensitive 1470 asctime-date = day-name SP date3 SP time-of-day SP year 1471 date3 = month SP ( 2DIGIT / ( SP 1DIGIT )) 1472 ; month day (e.g., Jun 2) 1474 Note: Recipients of date values are encouraged to be robust in 1475 accepting date values that may have been sent by non-HTTP 1476 applications, as is sometimes the case when retrieving or posting 1477 messages via proxies/gateways to SMTP or NNTP. 1479 Note: HTTP requirements for the date/time stamp format apply only 1480 to their usage within the protocol stream. Clients and servers 1481 are not required to use these formats for user presentation, 1482 request logging, etc. 1484 6.2. Transfer Codings 1486 Transfer-coding values are used to indicate an encoding 1487 transformation that has been, can be, or may need to be applied to an 1488 entity-body in order to ensure "safe transport" through the network. 1489 This differs from a content coding in that the transfer-coding is a 1490 property of the message, not of the original entity. 1492 transfer-coding = "chunked" ; Section 6.2.1 1493 / "compress" ; Section 6.2.2.1 1494 / "deflate" ; Section 6.2.2.2 1495 / "gzip" ; Section 6.2.2.3 1496 / transfer-extension 1497 transfer-extension = token *( OWS ";" OWS transfer-parameter ) 1499 Parameters are in the form of attribute/value pairs. 1501 transfer-parameter = attribute BWS "=" BWS value 1502 attribute = token 1503 value = word 1505 All transfer-coding values are case-insensitive. HTTP/1.1 uses 1506 transfer-coding values in the TE header field (Section 9.5) and in 1507 the Transfer-Encoding header field (Section 9.7). 1509 Whenever a transfer-coding is applied to a message-body, the set of 1510 transfer-codings MUST include "chunked", unless the message indicates 1511 it is terminated by closing the connection. When the "chunked" 1512 transfer-coding is used, it MUST be the last transfer-coding applied 1513 to the message-body. The "chunked" transfer-coding MUST NOT be 1514 applied more than once to a message-body. These rules allow the 1515 recipient to determine the transfer-length of the message 1516 (Section 3.4). 1518 Transfer-codings are analogous to the Content-Transfer-Encoding 1519 values of MIME, which were designed to enable safe transport of 1520 binary data over a 7-bit transport service ([RFC2045], Section 6). 1521 However, safe transport has a different focus for an 8bit-clean 1522 transfer protocol. In HTTP, the only unsafe characteristic of 1523 message-bodies is the difficulty in determining the exact body length 1524 (Section 3.4), or the desire to encrypt data over a shared transport. 1526 A server which receives an entity-body with a transfer-coding it does 1527 not understand SHOULD return 501 (Not Implemented), and close the 1528 connection. A server MUST NOT send transfer-codings to an HTTP/1.0 1529 client. 1531 6.2.1. Chunked Transfer Coding 1533 The chunked encoding modifies the body of a message in order to 1534 transfer it as a series of chunks, each with its own size indicator, 1535 followed by an OPTIONAL trailer containing entity-header fields. 1536 This allows dynamically produced content to be transferred along with 1537 the information necessary for the recipient to verify that it has 1538 received the full message. 1540 Chunked-Body = *chunk 1541 last-chunk 1542 trailer-part 1543 CRLF 1545 chunk = chunk-size *WSP [ chunk-ext ] CRLF 1546 chunk-data CRLF 1547 chunk-size = 1*HEXDIG 1548 last-chunk = 1*("0") *WSP [ chunk-ext ] CRLF 1550 chunk-ext = *( ";" *WSP chunk-ext-name 1551 [ "=" chunk-ext-val ] *WSP ) 1552 chunk-ext-name = token 1553 chunk-ext-val = token / quoted-str-nf 1554 chunk-data = 1*OCTET ; a sequence of chunk-size octets 1555 trailer-part = *( entity-header CRLF ) 1557 quoted-str-nf = DQUOTE *( qdtext-nf / quoted-pair ) DQUOTE 1558 ; like quoted-string, but disallowing line folding 1559 qdtext-nf = WSP / %x21 / %x23-5B / %x5D-7E / obs-text 1560 ; WSP / / obs-text 1562 The chunk-size field is a string of hex digits indicating the size of 1563 the chunk-data in octets. The chunked encoding is ended by any chunk 1564 whose size is zero, followed by the trailer, which is terminated by 1565 an empty line. 1567 The trailer allows the sender to include additional HTTP header 1568 fields at the end of the message. The Trailer header field can be 1569 used to indicate which header fields are included in a trailer (see 1570 Section 9.6). 1572 A server using chunked transfer-coding in a response MUST NOT use the 1573 trailer for any header fields unless at least one of the following is 1574 true: 1576 1. the request included a TE header field that indicates "trailers" 1577 is acceptable in the transfer-coding of the response, as 1578 described in Section 9.5; or, 1580 2. the server is the origin server for the response, the trailer 1581 fields consist entirely of optional metadata, and the recipient 1582 could use the message (in a manner acceptable to the origin 1583 server) without receiving this metadata. In other words, the 1584 origin server is willing to accept the possibility that the 1585 trailer fields might be silently discarded along the path to the 1586 client. 1588 This requirement prevents an interoperability failure when the 1589 message is being received by an HTTP/1.1 (or later) proxy and 1590 forwarded to an HTTP/1.0 recipient. It avoids a situation where 1591 compliance with the protocol would have necessitated a possibly 1592 infinite buffer on the proxy. 1594 A process for decoding the "chunked" transfer-coding can be 1595 represented in pseudo-code as: 1597 length := 0 1598 read chunk-size, chunk-ext (if any) and CRLF 1599 while (chunk-size > 0) { 1600 read chunk-data and CRLF 1601 append chunk-data to entity-body 1602 length := length + chunk-size 1603 read chunk-size and CRLF 1604 } 1605 read entity-header 1606 while (entity-header not empty) { 1607 append entity-header to existing header fields 1608 read entity-header 1609 } 1610 Content-Length := length 1611 Remove "chunked" from Transfer-Encoding 1613 All HTTP/1.1 applications MUST be able to receive and decode the 1614 "chunked" transfer-coding, and MUST ignore chunk-ext extensions they 1615 do not understand. 1617 6.2.2. Compression Codings 1619 The codings defined below can be used to compress the payload of a 1620 message. 1622 Note: Use of program names for the identification of encoding 1623 formats is not desirable and is discouraged for future encodings. 1624 Their use here is representative of historical practice, not good 1625 design. 1627 Note: For compatibility with previous implementations of HTTP, 1628 applications SHOULD consider "x-gzip" and "x-compress" to be 1629 equivalent to "gzip" and "compress" respectively. 1631 6.2.2.1. Compress Coding 1633 The "compress" format is produced by the common UNIX file compression 1634 program "compress". This format is an adaptive Lempel-Ziv-Welch 1635 coding (LZW). 1637 6.2.2.2. Deflate Coding 1639 The "deflate" format is defined as the "deflate" compression 1640 mechanism (described in [RFC1951]) used inside the "zlib" data format 1641 ([RFC1950]). 1643 Note: Some incorrect implementations send the "deflate" compressed 1644 data without the zlib wrapper. 1646 6.2.2.3. Gzip Coding 1648 The "gzip" format is produced by the file compression program "gzip" 1649 (GNU zip), as described in [RFC1952]. This format is a Lempel-Ziv 1650 coding (LZ77) with a 32 bit CRC. 1652 6.2.3. Transfer Coding Registry 1654 The HTTP Transfer Coding Registry defines the name space for the 1655 transfer coding names. 1657 Registrations MUST include the following fields: 1659 o Name 1661 o Description 1663 o Pointer to specification text 1665 Names of transfer codings MUST NOT overlap with names of content 1666 codings (Section 2.2 of [Part3]), unless the encoding transformation 1667 is identical (as it is the case for the compression codings defined 1668 in Section 6.2.2). 1670 Values to be added to this name space require expert review and a 1671 specification (see "Expert Review" and "Specification Required" in 1672 Section 4.1 of [RFC5226]), and MUST conform to the purpose of 1673 transfer coding defined in this section. 1675 The registry itself is maintained at 1676 . 1678 6.3. Product Tokens 1680 Product tokens are used to allow communicating applications to 1681 identify themselves by software name and version. Most fields using 1682 product tokens also allow sub-products which form a significant part 1683 of the application to be listed, separated by whitespace. By 1684 convention, the products are listed in order of their significance 1685 for identifying the application. 1687 product = token ["/" product-version] 1688 product-version = token 1690 Examples: 1692 User-Agent: CERN-LineMode/2.15 libwww/2.17b3 1693 Server: Apache/0.8.4 1695 Product tokens SHOULD be short and to the point. They MUST NOT be 1696 used for advertising or other non-essential information. Although 1697 any token character MAY appear in a product-version, this token 1698 SHOULD only be used for a version identifier (i.e., successive 1699 versions of the same product SHOULD only differ in the product- 1700 version portion of the product value). 1702 6.4. Quality Values 1704 Both transfer codings (TE request header, Section 9.5) and content 1705 negotiation (Section 4 of [Part3]) use short "floating point" numbers 1706 to indicate the relative importance ("weight") of various negotiable 1707 parameters. A weight is normalized to a real number in the range 0 1708 through 1, where 0 is the minimum and 1 the maximum value. If a 1709 parameter has a quality value of 0, then content with this parameter 1710 is "not acceptable" for the client. HTTP/1.1 applications MUST NOT 1711 generate more than three digits after the decimal point. User 1712 configuration of these values SHOULD also be limited in this fashion. 1714 qvalue = ( "0" [ "." 0*3DIGIT ] ) 1715 / ( "1" [ "." 0*3("0") ] ) 1717 Note: "Quality values" is a misnomer, since these values merely 1718 represent relative degradation in desired quality. 1720 7. Connections 1722 7.1. Persistent Connections 1724 7.1.1. Purpose 1726 Prior to persistent connections, a separate TCP connection was 1727 established to fetch each URL, increasing the load on HTTP servers 1728 and causing congestion on the Internet. The use of inline images and 1729 other associated data often requires a client to make multiple 1730 requests of the same server in a short amount of time. Analysis of 1731 these performance problems and results from a prototype 1732 implementation are available [Pad1995] [Spe]. Implementation 1733 experience and measurements of actual HTTP/1.1 implementations show 1734 good results [Nie1997]. Alternatives have also been explored, for 1735 example, T/TCP [Tou1998]. 1737 Persistent HTTP connections have a number of advantages: 1739 o By opening and closing fewer TCP connections, CPU time is saved in 1740 routers and hosts (clients, servers, proxies, gateways, tunnels, 1741 or caches), and memory used for TCP protocol control blocks can be 1742 saved in hosts. 1744 o HTTP requests and responses can be pipelined on a connection. 1745 Pipelining allows a client to make multiple requests without 1746 waiting for each response, allowing a single TCP connection to be 1747 used much more efficiently, with much lower elapsed time. 1749 o Network congestion is reduced by reducing the number of packets 1750 caused by TCP opens, and by allowing TCP sufficient time to 1751 determine the congestion state of the network. 1753 o Latency on subsequent requests is reduced since there is no time 1754 spent in TCP's connection opening handshake. 1756 o HTTP can evolve more gracefully, since errors can be reported 1757 without the penalty of closing the TCP connection. Clients using 1758 future versions of HTTP might optimistically try a new feature, 1759 but if communicating with an older server, retry with old 1760 semantics after an error is reported. 1762 HTTP implementations SHOULD implement persistent connections. 1764 7.1.2. Overall Operation 1766 A significant difference between HTTP/1.1 and earlier versions of 1767 HTTP is that persistent connections are the default behavior of any 1768 HTTP connection. That is, unless otherwise indicated, the client 1769 SHOULD assume that the server will maintain a persistent connection, 1770 even after error responses from the server. 1772 Persistent connections provide a mechanism by which a client and a 1773 server can signal the close of a TCP connection. This signaling 1774 takes place using the Connection header field (Section 9.1). Once a 1775 close has been signaled, the client MUST NOT send any more requests 1776 on that connection. 1778 7.1.2.1. Negotiation 1780 An HTTP/1.1 server MAY assume that a HTTP/1.1 client intends to 1781 maintain a persistent connection unless a Connection header including 1782 the connection-token "close" was sent in the request. If the server 1783 chooses to close the connection immediately after sending the 1784 response, it SHOULD send a Connection header including the 1785 connection-token "close". 1787 An HTTP/1.1 client MAY expect a connection to remain open, but would 1788 decide to keep it open based on whether the response from a server 1789 contains a Connection header with the connection-token close. In 1790 case the client does not want to maintain a connection for more than 1791 that request, it SHOULD send a Connection header including the 1792 connection-token close. 1794 If either the client or the server sends the close token in the 1795 Connection header, that request becomes the last one for the 1796 connection. 1798 Clients and servers SHOULD NOT assume that a persistent connection is 1799 maintained for HTTP versions less than 1.1 unless it is explicitly 1800 signaled. See Appendix B.2 for more information on backward 1801 compatibility with HTTP/1.0 clients. 1803 In order to remain persistent, all messages on the connection MUST 1804 have a self-defined message length (i.e., one not defined by closure 1805 of the connection), as described in Section 3.4. 1807 7.1.2.2. Pipelining 1809 A client that supports persistent connections MAY "pipeline" its 1810 requests (i.e., send multiple requests without waiting for each 1811 response). A server MUST send its responses to those requests in the 1812 same order that the requests were received. 1814 Clients which assume persistent connections and pipeline immediately 1815 after connection establishment SHOULD be prepared to retry their 1816 connection if the first pipelined attempt fails. If a client does 1817 such a retry, it MUST NOT pipeline before it knows the connection is 1818 persistent. Clients MUST also be prepared to resend their requests 1819 if the server closes the connection before sending all of the 1820 corresponding responses. 1822 Clients SHOULD NOT pipeline requests using non-idempotent methods or 1823 non-idempotent sequences of methods (see Section 7.1.2 of [Part2]). 1824 Otherwise, a premature termination of the transport connection could 1825 lead to indeterminate results. A client wishing to send a non- 1826 idempotent request SHOULD wait to send that request until it has 1827 received the response status for the previous request. 1829 7.1.3. Proxy Servers 1831 It is especially important that proxies correctly implement the 1832 properties of the Connection header field as specified in 1833 Section 9.1. 1835 The proxy server MUST signal persistent connections separately with 1836 its clients and the origin servers (or other proxy servers) that it 1837 connects to. Each persistent connection applies to only one 1838 transport link. 1840 A proxy server MUST NOT establish a HTTP/1.1 persistent connection 1841 with an HTTP/1.0 client (but see Section 19.7.1 of [RFC2068] for 1842 information and discussion of the problems with the Keep-Alive header 1843 implemented by many HTTP/1.0 clients). 1845 7.1.3.1. End-to-end and Hop-by-hop Headers 1847 For the purpose of defining the behavior of caches and non-caching 1848 proxies, we divide HTTP headers into two categories: 1850 o End-to-end headers, which are transmitted to the ultimate 1851 recipient of a request or response. End-to-end headers in 1852 responses MUST be stored as part of a cache entry and MUST be 1853 transmitted in any response formed from a cache entry. 1855 o Hop-by-hop headers, which are meaningful only for a single 1856 transport-level connection, and are not stored by caches or 1857 forwarded by proxies. 1859 The following HTTP/1.1 headers are hop-by-hop headers: 1861 o Connection 1863 o Keep-Alive 1865 o Proxy-Authenticate 1867 o Proxy-Authorization 1869 o TE 1871 o Trailer 1872 o Transfer-Encoding 1874 o Upgrade 1876 All other headers defined by HTTP/1.1 are end-to-end headers. 1878 Other hop-by-hop headers MUST be listed in a Connection header 1879 (Section 9.1). 1881 7.1.3.2. Non-modifiable Headers 1883 Some features of HTTP/1.1, such as Digest Authentication, depend on 1884 the value of certain end-to-end headers. A transparent proxy SHOULD 1885 NOT modify an end-to-end header unless the definition of that header 1886 requires or specifically allows that. 1888 A transparent proxy MUST NOT modify any of the following fields in a 1889 request or response, and it MUST NOT add any of these fields if not 1890 already present: 1892 o Content-Location 1894 o Content-MD5 1896 o ETag 1898 o Last-Modified 1900 A transparent proxy MUST NOT modify any of the following fields in a 1901 response: 1903 o Expires 1905 but it MAY add any of these fields if not already present. If an 1906 Expires header is added, it MUST be given a field-value identical to 1907 that of the Date header in that response. 1909 A proxy MUST NOT modify or add any of the following fields in a 1910 message that contains the no-transform cache-control directive, or in 1911 any request: 1913 o Content-Encoding 1915 o Content-Range 1917 o Content-Type 1919 A non-transparent proxy MAY modify or add these fields to a message 1920 that does not include no-transform, but if it does so, it MUST add a 1921 Warning 214 (Transformation applied) if one does not already appear 1922 in the message (see Section 3.6 of [Part6]). 1924 Warning: Unnecessary modification of end-to-end headers might 1925 cause authentication failures if stronger authentication 1926 mechanisms are introduced in later versions of HTTP. Such 1927 authentication mechanisms MAY rely on the values of header fields 1928 not listed here. 1930 The Content-Length field of a request or response is added or deleted 1931 according to the rules in Section 3.4. A transparent proxy MUST 1932 preserve the entity-length (Section 3.2.2 of [Part3]) of the entity- 1933 body, although it MAY change the transfer-length (Section 3.4). 1935 7.1.4. Practical Considerations 1937 Servers will usually have some time-out value beyond which they will 1938 no longer maintain an inactive connection. Proxy servers might make 1939 this a higher value since it is likely that the client will be making 1940 more connections through the same server. The use of persistent 1941 connections places no requirements on the length (or existence) of 1942 this time-out for either the client or the server. 1944 When a client or server wishes to time-out it SHOULD issue a graceful 1945 close on the transport connection. Clients and servers SHOULD both 1946 constantly watch for the other side of the transport close, and 1947 respond to it as appropriate. If a client or server does not detect 1948 the other side's close promptly it could cause unnecessary resource 1949 drain on the network. 1951 A client, server, or proxy MAY close the transport connection at any 1952 time. For example, a client might have started to send a new request 1953 at the same time that the server has decided to close the "idle" 1954 connection. From the server's point of view, the connection is being 1955 closed while it was idle, but from the client's point of view, a 1956 request is in progress. 1958 This means that clients, servers, and proxies MUST be able to recover 1959 from asynchronous close events. Client software SHOULD reopen the 1960 transport connection and retransmit the aborted sequence of requests 1961 without user interaction so long as the request sequence is 1962 idempotent (see Section 7.1.2 of [Part2]). Non-idempotent methods or 1963 sequences MUST NOT be automatically retried, although user agents MAY 1964 offer a human operator the choice of retrying the request(s). 1965 Confirmation by user-agent software with semantic understanding of 1966 the application MAY substitute for user confirmation. The automatic 1967 retry SHOULD NOT be repeated if the second sequence of requests 1968 fails. 1970 Servers SHOULD always respond to at least one request per connection, 1971 if at all possible. Servers SHOULD NOT close a connection in the 1972 middle of transmitting a response, unless a network or client failure 1973 is suspected. 1975 Clients (including proxies) SHOULD limit the number of simultaneous 1976 connections that they maintain to a given server (including proxies). 1978 Previous revisions of HTTP gave a specific number of connections as a 1979 ceiling, but this was found to be impractical for many applications. 1980 As a result, this specification does not mandate a particular maximum 1981 number of connections, but instead encourages clients to be 1982 conservative when opening multiple connections. 1984 In particular, while using multiple connections avoids the "head-of- 1985 line blocking" problem (whereby a request that takes significant 1986 server-side processing and/or has a large payload can block 1987 subsequent requests on the same connection), each connection used 1988 consumes server resources (sometimes significantly), and furthermore 1989 using multiple connections can cause undesirable side effects in 1990 congested networks. 1992 Note that servers might reject traffic that they deem abusive, 1993 including an excessive number of connections from a client. 1995 7.2. Message Transmission Requirements 1997 7.2.1. Persistent Connections and Flow Control 1999 HTTP/1.1 servers SHOULD maintain persistent connections and use TCP's 2000 flow control mechanisms to resolve temporary overloads, rather than 2001 terminating connections with the expectation that clients will retry. 2002 The latter technique can exacerbate network congestion. 2004 7.2.2. Monitoring Connections for Error Status Messages 2006 An HTTP/1.1 (or later) client sending a message-body SHOULD monitor 2007 the network connection for an error status while it is transmitting 2008 the request. If the client sees an error status, it SHOULD 2009 immediately cease transmitting the body. If the body is being sent 2010 using a "chunked" encoding (Section 6.2), a zero length chunk and 2011 empty trailer MAY be used to prematurely mark the end of the message. 2012 If the body was preceded by a Content-Length header, the client MUST 2013 close the connection. 2015 7.2.3. Use of the 100 (Continue) Status 2017 The purpose of the 100 (Continue) status (see Section 8.1.1 of 2018 [Part2]) is to allow a client that is sending a request message with 2019 a request body to determine if the origin server is willing to accept 2020 the request (based on the request headers) before the client sends 2021 the request body. In some cases, it might either be inappropriate or 2022 highly inefficient for the client to send the body if the server will 2023 reject the message without looking at the body. 2025 Requirements for HTTP/1.1 clients: 2027 o If a client will wait for a 100 (Continue) response before sending 2028 the request body, it MUST send an Expect request-header field 2029 (Section 9.2 of [Part2]) with the "100-continue" expectation. 2031 o A client MUST NOT send an Expect request-header field (Section 9.2 2032 of [Part2]) with the "100-continue" expectation if it does not 2033 intend to send a request body. 2035 Because of the presence of older implementations, the protocol allows 2036 ambiguous situations in which a client may send "Expect: 100- 2037 continue" without receiving either a 417 (Expectation Failed) status 2038 or a 100 (Continue) status. Therefore, when a client sends this 2039 header field to an origin server (possibly via a proxy) from which it 2040 has never seen a 100 (Continue) status, the client SHOULD NOT wait 2041 for an indefinite period before sending the request body. 2043 Requirements for HTTP/1.1 origin servers: 2045 o Upon receiving a request which includes an Expect request-header 2046 field with the "100-continue" expectation, an origin server MUST 2047 either respond with 100 (Continue) status and continue to read 2048 from the input stream, or respond with a final status code. The 2049 origin server MUST NOT wait for the request body before sending 2050 the 100 (Continue) response. If it responds with a final status 2051 code, it MAY close the transport connection or it MAY continue to 2052 read and discard the rest of the request. It MUST NOT perform the 2053 requested method if it returns a final status code. 2055 o An origin server SHOULD NOT send a 100 (Continue) response if the 2056 request message does not include an Expect request-header field 2057 with the "100-continue" expectation, and MUST NOT send a 100 2058 (Continue) response if such a request comes from an HTTP/1.0 (or 2059 earlier) client. There is an exception to this rule: for 2060 compatibility with [RFC2068], a server MAY send a 100 (Continue) 2061 status in response to an HTTP/1.1 PUT or POST request that does 2062 not include an Expect request-header field with the "100-continue" 2063 expectation. This exception, the purpose of which is to minimize 2064 any client processing delays associated with an undeclared wait 2065 for 100 (Continue) status, applies only to HTTP/1.1 requests, and 2066 not to requests with any other HTTP-version value. 2068 o An origin server MAY omit a 100 (Continue) response if it has 2069 already received some or all of the request body for the 2070 corresponding request. 2072 o An origin server that sends a 100 (Continue) response MUST 2073 ultimately send a final status code, once the request body is 2074 received and processed, unless it terminates the transport 2075 connection prematurely. 2077 o If an origin server receives a request that does not include an 2078 Expect request-header field with the "100-continue" expectation, 2079 the request includes a request body, and the server responds with 2080 a final status code before reading the entire request body from 2081 the transport connection, then the server SHOULD NOT close the 2082 transport connection until it has read the entire request, or 2083 until the client closes the connection. Otherwise, the client 2084 might not reliably receive the response message. However, this 2085 requirement is not be construed as preventing a server from 2086 defending itself against denial-of-service attacks, or from badly 2087 broken client implementations. 2089 Requirements for HTTP/1.1 proxies: 2091 o If a proxy receives a request that includes an Expect request- 2092 header field with the "100-continue" expectation, and the proxy 2093 either knows that the next-hop server complies with HTTP/1.1 or 2094 higher, or does not know the HTTP version of the next-hop server, 2095 it MUST forward the request, including the Expect header field. 2097 o If the proxy knows that the version of the next-hop server is 2098 HTTP/1.0 or lower, it MUST NOT forward the request, and it MUST 2099 respond with a 417 (Expectation Failed) status. 2101 o Proxies SHOULD maintain a cache recording the HTTP version numbers 2102 received from recently-referenced next-hop servers. 2104 o A proxy MUST NOT forward a 100 (Continue) response if the request 2105 message was received from an HTTP/1.0 (or earlier) client and did 2106 not include an Expect request-header field with the "100-continue" 2107 expectation. This requirement overrides the general rule for 2108 forwarding of 1xx responses (see Section 8.1 of [Part2]). 2110 7.2.4. Client Behavior if Server Prematurely Closes Connection 2112 If an HTTP/1.1 client sends a request which includes a request body, 2113 but which does not include an Expect request-header field with the 2114 "100-continue" expectation, and if the client is not directly 2115 connected to an HTTP/1.1 origin server, and if the client sees the 2116 connection close before receiving any status from the server, the 2117 client SHOULD retry the request. If the client does retry this 2118 request, it MAY use the following "binary exponential backoff" 2119 algorithm to be assured of obtaining a reliable response: 2121 1. Initiate a new connection to the server 2123 2. Transmit the request-headers 2125 3. Initialize a variable R to the estimated round-trip time to the 2126 server (e.g., based on the time it took to establish the 2127 connection), or to a constant value of 5 seconds if the round- 2128 trip time is not available. 2130 4. Compute T = R * (2**N), where N is the number of previous retries 2131 of this request. 2133 5. Wait either for an error response from the server, or for T 2134 seconds (whichever comes first) 2136 6. If no error response is received, after T seconds transmit the 2137 body of the request. 2139 7. If client sees that the connection is closed prematurely, repeat 2140 from step 1 until the request is accepted, an error response is 2141 received, or the user becomes impatient and terminates the retry 2142 process. 2144 If at any point an error status is received, the client 2146 o SHOULD NOT continue and 2148 o SHOULD close the connection if it has not completed sending the 2149 request message. 2151 8. Miscellaneous notes that may disappear 2153 8.1. Scheme aliases considered harmful 2155 [[TBD-aliases-harmful: describe why aliases like webcal are 2156 harmful.]] 2158 8.2. Use of HTTP for proxy communication 2160 [[TBD-proxy-other: Configured to use HTTP to proxy HTTP or other 2161 protocols.]] 2163 8.3. Interception of HTTP for access control 2165 [[TBD-intercept: Interception of HTTP traffic for initiating access 2166 control.]] 2168 8.4. Use of HTTP by other protocols 2170 [[TBD-profiles: Profiles of HTTP defined by other protocol. 2171 Extensions of HTTP like WebDAV.]] 2173 8.5. Use of HTTP by media type specification 2175 [[TBD-hypertext: Instructions on composing HTTP requests via 2176 hypertext formats.]] 2178 9. Header Field Definitions 2180 This section defines the syntax and semantics of HTTP/1.1 header 2181 fields related to message framing and transport protocols. 2183 For entity-header fields, both sender and recipient refer to either 2184 the client or the server, depending on who sends and who receives the 2185 entity. 2187 9.1. Connection 2189 The "Connection" general-header field allows the sender to specify 2190 options that are desired for that particular connection and MUST NOT 2191 be communicated by proxies over further connections. 2193 The Connection header's value has the following grammar: 2195 Connection = "Connection" ":" OWS Connection-v 2196 Connection-v = 1#connection-token 2197 connection-token = token 2199 HTTP/1.1 proxies MUST parse the Connection header field before a 2200 message is forwarded and, for each connection-token in this field, 2201 remove any header field(s) from the message with the same name as the 2202 connection-token. Connection options are signaled by the presence of 2203 a connection-token in the Connection header field, not by any 2204 corresponding additional header field(s), since the additional header 2205 field may not be sent if there are no parameters associated with that 2206 connection option. 2208 Message headers listed in the Connection header MUST NOT include end- 2209 to-end headers, such as Cache-Control. 2211 HTTP/1.1 defines the "close" connection option for the sender to 2212 signal that the connection will be closed after completion of the 2213 response. For example, 2215 Connection: close 2217 in either the request or the response header fields indicates that 2218 the connection SHOULD NOT be considered "persistent" (Section 7.1) 2219 after the current request/response is complete. 2221 An HTTP/1.1 client that does not support persistent connections MUST 2222 include the "close" connection option in every request message. 2224 An HTTP/1.1 server that does not support persistent connections MUST 2225 include the "close" connection option in every response message that 2226 does not have a 1xx (Informational) status code. 2228 A system receiving an HTTP/1.0 (or lower-version) message that 2229 includes a Connection header MUST, for each connection-token in this 2230 field, remove and ignore any header field(s) from the message with 2231 the same name as the connection-token. This protects against 2232 mistaken forwarding of such header fields by pre-HTTP/1.1 proxies. 2233 See Appendix B.2. 2235 9.2. Content-Length 2237 The "Content-Length" entity-header field indicates the size of the 2238 entity-body, in number of OCTETs. In the case of responses to the 2239 HEAD method, it indicates the size of the entity-body that would have 2240 been sent had the request been a GET. 2242 Content-Length = "Content-Length" ":" OWS 1*Content-Length-v 2243 Content-Length-v = 1*DIGIT 2245 An example is 2247 Content-Length: 3495 2249 Applications SHOULD use this field to indicate the transfer-length of 2250 the message-body, unless this is prohibited by the rules in 2251 Section 3.4. 2253 Any Content-Length greater than or equal to zero is a valid value. 2255 Section 3.4 describes how to determine the length of a message-body 2256 if a Content-Length is not given. 2258 Note that the meaning of this field is significantly different from 2259 the corresponding definition in MIME, where it is an optional field 2260 used within the "message/external-body" content-type. In HTTP, it 2261 SHOULD be sent whenever the message's length can be determined prior 2262 to being transferred, unless this is prohibited by the rules in 2263 Section 3.4. 2265 9.3. Date 2267 The "Date" general-header field represents the date and time at which 2268 the message was originated, having the same semantics as the 2269 Origination Date Field (orig-date) defined in Section 3.6.1 of 2270 [RFC5322]. The field value is an HTTP-date, as described in 2271 Section 6.1; it MUST be sent in rfc1123-date format. 2273 Date = "Date" ":" OWS Date-v 2274 Date-v = HTTP-date 2276 An example is 2278 Date: Tue, 15 Nov 1994 08:12:31 GMT 2280 Origin servers MUST include a Date header field in all responses, 2281 except in these cases: 2283 1. If the response status code is 100 (Continue) or 101 (Switching 2284 Protocols), the response MAY include a Date header field, at the 2285 server's option. 2287 2. If the response status code conveys a server error, e.g., 500 2288 (Internal Server Error) or 503 (Service Unavailable), and it is 2289 inconvenient or impossible to generate a valid Date. 2291 3. If the server does not have a clock that can provide a reasonable 2292 approximation of the current time, its responses MUST NOT include 2293 a Date header field. In this case, the rules in Section 9.3.1 2294 MUST be followed. 2296 A received message that does not have a Date header field MUST be 2297 assigned one by the recipient if the message will be cached by that 2298 recipient or gatewayed via a protocol which requires a Date. An HTTP 2299 implementation without a clock MUST NOT cache responses without 2300 revalidating them on every use. An HTTP cache, especially a shared 2301 cache, SHOULD use a mechanism, such as NTP [RFC1305], to synchronize 2302 its clock with a reliable external standard. 2304 Clients SHOULD only send a Date header field in messages that include 2305 an entity-body, as in the case of the PUT and POST requests, and even 2306 then it is optional. A client without a clock MUST NOT send a Date 2307 header field in a request. 2309 The HTTP-date sent in a Date header SHOULD NOT represent a date and 2310 time subsequent to the generation of the message. It SHOULD 2311 represent the best available approximation of the date and time of 2312 message generation, unless the implementation has no means of 2313 generating a reasonably accurate date and time. In theory, the date 2314 ought to represent the moment just before the entity is generated. 2315 In practice, the date can be generated at any time during the message 2316 origination without affecting its semantic value. 2318 9.3.1. Clockless Origin Server Operation 2320 Some origin server implementations might not have a clock available. 2321 An origin server without a clock MUST NOT assign Expires or Last- 2322 Modified values to a response, unless these values were associated 2323 with the resource by a system or user with a reliable clock. It MAY 2324 assign an Expires value that is known, at or before server 2325 configuration time, to be in the past (this allows "pre-expiration" 2326 of responses without storing separate Expires values for each 2327 resource). 2329 9.4. Host 2331 The "Host" request-header field specifies the Internet host and port 2332 number of the resource being requested, allowing the origin server or 2333 gateway to differentiate between internally-ambiguous URLs, such as 2334 the root "/" URL of a server for multiple host names on a single IP 2335 address. 2337 The Host field value MUST represent the naming authority of the 2338 origin server or gateway given by the original URL obtained from the 2339 user or referring resource (generally an http URI, as described in 2340 Section 2.6.1). 2342 Host = "Host" ":" OWS Host-v 2343 Host-v = uri-host [ ":" port ] ; Section 2.6.1 2345 A "host" without any trailing port information implies the default 2346 port for the service requested (e.g., "80" for an HTTP URL). For 2347 example, a request on the origin server for 2348 would properly include: 2350 GET /pub/WWW/ HTTP/1.1 2351 Host: www.example.org 2353 A client MUST include a Host header field in all HTTP/1.1 request 2354 messages. If the requested URI does not include an Internet host 2355 name for the service being requested, then the Host header field MUST 2356 be given with an empty value. An HTTP/1.1 proxy MUST ensure that any 2357 request message it forwards does contain an appropriate Host header 2358 field that identifies the service being requested by the proxy. All 2359 Internet-based HTTP/1.1 servers MUST respond with a 400 (Bad Request) 2360 status code to any HTTP/1.1 request message which lacks a Host header 2361 field. 2363 See Sections 4.2 and B.1.1 for other requirements relating to Host. 2365 9.5. TE 2367 The "TE" request-header field indicates what extension transfer- 2368 codings it is willing to accept in the response, and whether or not 2369 it is willing to accept trailer fields in a chunked transfer-coding. 2371 Its value may consist of the keyword "trailers" and/or a comma- 2372 separated list of extension transfer-coding names with optional 2373 accept parameters (as described in Section 6.2). 2375 TE = "TE" ":" OWS TE-v 2376 TE-v = #t-codings 2377 t-codings = "trailers" / ( transfer-extension [ te-params ] ) 2378 te-params = OWS ";" OWS "q=" qvalue *( te-ext ) 2379 te-ext = OWS ";" OWS token [ "=" word ] 2381 The presence of the keyword "trailers" indicates that the client is 2382 willing to accept trailer fields in a chunked transfer-coding, as 2383 defined in Section 6.2.1. This keyword is reserved for use with 2384 transfer-coding values even though it does not itself represent a 2385 transfer-coding. 2387 Examples of its use are: 2389 TE: deflate 2390 TE: 2391 TE: trailers, deflate;q=0.5 2393 The TE header field only applies to the immediate connection. 2394 Therefore, the keyword MUST be supplied within a Connection header 2395 field (Section 9.1) whenever TE is present in an HTTP/1.1 message. 2397 A server tests whether a transfer-coding is acceptable, according to 2398 a TE field, using these rules: 2400 1. The "chunked" transfer-coding is always acceptable. If the 2401 keyword "trailers" is listed, the client indicates that it is 2402 willing to accept trailer fields in the chunked response on 2403 behalf of itself and any downstream clients. The implication is 2404 that, if given, the client is stating that either all downstream 2405 clients are willing to accept trailer fields in the forwarded 2406 response, or that it will attempt to buffer the response on 2407 behalf of downstream recipients. 2409 Note: HTTP/1.1 does not define any means to limit the size of a 2410 chunked response such that a client can be assured of buffering 2411 the entire response. 2413 2. If the transfer-coding being tested is one of the transfer- 2414 codings listed in the TE field, then it is acceptable unless it 2415 is accompanied by a qvalue of 0. (As defined in Section 6.4, a 2416 qvalue of 0 means "not acceptable.") 2418 3. If multiple transfer-codings are acceptable, then the acceptable 2419 transfer-coding with the highest non-zero qvalue is preferred. 2420 The "chunked" transfer-coding always has a qvalue of 1. 2422 If the TE field-value is empty or if no TE field is present, the only 2423 transfer-coding is "chunked". A message with no transfer-coding is 2424 always acceptable. 2426 9.6. Trailer 2428 The "Trailer" general-header field indicates that the given set of 2429 header fields is present in the trailer of a message encoded with 2430 chunked transfer-coding. 2432 Trailer = "Trailer" ":" OWS Trailer-v 2433 Trailer-v = 1#field-name 2435 An HTTP/1.1 message SHOULD include a Trailer header field in a 2436 message using chunked transfer-coding with a non-empty trailer. 2437 Doing so allows the recipient to know which header fields to expect 2438 in the trailer. 2440 If no Trailer header field is present, the trailer SHOULD NOT include 2441 any header fields. See Section 6.2.1 for restrictions on the use of 2442 trailer fields in a "chunked" transfer-coding. 2444 Message header fields listed in the Trailer header field MUST NOT 2445 include the following header fields: 2447 o Transfer-Encoding 2449 o Content-Length 2451 o Trailer 2453 9.7. Transfer-Encoding 2455 The "Transfer-Encoding" general-header field indicates what transfer- 2456 codings (if any) have been applied to the message body. It differs 2457 from Content-Encoding (Section 2.2 of [Part3]) in that transfer- 2458 codings are a property of the message (and therefore are removed by 2459 intermediaries), whereas content-codings are not. 2461 Transfer-Encoding = "Transfer-Encoding" ":" OWS 2462 Transfer-Encoding-v 2463 Transfer-Encoding-v = 1#transfer-coding 2465 Transfer-codings are defined in Section 6.2. An example is: 2467 Transfer-Encoding: chunked 2469 If multiple encodings have been applied to an entity, the transfer- 2470 codings MUST be listed in the order in which they were applied. 2471 Additional information about the encoding parameters MAY be provided 2472 by other entity-header fields not defined by this specification. 2474 Many older HTTP/1.0 applications do not understand the Transfer- 2475 Encoding header. 2477 9.8. Upgrade 2479 The "Upgrade" general-header field allows the client to specify what 2480 additional communication protocols it would like to use, if the 2481 server chooses to switch protocols. Additionally, the server MUST 2482 use the Upgrade header field within a 101 (Switching Protocols) 2483 response to indicate which protocol(s) are being switched to. 2485 Upgrade = "Upgrade" ":" OWS Upgrade-v 2486 Upgrade-v = 1#product 2488 For example, 2490 Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11 2492 The Upgrade header field is intended to provide a simple mechanism 2493 for transition from HTTP/1.1 to some other, incompatible protocol. 2494 It does so by allowing the client to advertise its desire to use 2495 another protocol, such as a later version of HTTP with a higher major 2496 version number, even though the current request has been made using 2497 HTTP/1.1. This eases the difficult transition between incompatible 2498 protocols by allowing the client to initiate a request in the more 2499 commonly supported protocol while indicating to the server that it 2500 would like to use a "better" protocol if available (where "better" is 2501 determined by the server, possibly according to the nature of the 2502 method and/or resource being requested). 2504 The Upgrade header field only applies to switching application-layer 2505 protocols upon the existing transport-layer connection. Upgrade 2506 cannot be used to insist on a protocol change; its acceptance and use 2507 by the server is optional. The capabilities and nature of the 2508 application-layer communication after the protocol change is entirely 2509 dependent upon the new protocol chosen, although the first action 2510 after changing the protocol MUST be a response to the initial HTTP 2511 request containing the Upgrade header field. 2513 The Upgrade header field only applies to the immediate connection. 2514 Therefore, the upgrade keyword MUST be supplied within a Connection 2515 header field (Section 9.1) whenever Upgrade is present in an HTTP/1.1 2516 message. 2518 The Upgrade header field cannot be used to indicate a switch to a 2519 protocol on a different connection. For that purpose, it is more 2520 appropriate to use a 301, 302, 303, or 305 redirection response. 2522 This specification only defines the protocol name "HTTP" for use by 2523 the family of Hypertext Transfer Protocols, as defined by the HTTP 2524 version rules of Section 2.5 and future updates to this 2525 specification. Additional tokens can be registered with IANA using 2526 the registration procedure defined below. 2528 9.8.1. Upgrade Token Registry 2530 The HTTP Upgrade Token Registry defines the name space for product 2531 tokens used to identify protocols in the Upgrade header field. Each 2532 registered token should be associated with one or a set of 2533 specifications, and with contact information. 2535 Registrations should be allowed on a First Come First Served basis as 2536 described in Section 4.1 of [RFC5226]. These specifications need not 2537 be IETF documents or be subject to IESG review, but should obey the 2538 following rules: 2540 1. A token, once registered, stays registered forever. 2542 2. The registration MUST name a responsible party for the 2543 registration. 2545 3. The registration MUST name a point of contact. 2547 4. The registration MAY name the documentation required for the 2548 token. 2550 5. The responsible party MAY change the registration at any time. 2551 The IANA will keep a record of all such changes, and make them 2552 available upon request. 2554 6. The responsible party for the first registration of a "product" 2555 token MUST approve later registrations of a "version" token 2556 together with that "product" token before they can be registered. 2558 7. If absolutely required, the IESG MAY reassign the responsibility 2559 for a token. This will normally only be used in the case when a 2560 responsible party cannot be contacted. 2562 It is not required that specifications for upgrade tokens be made 2563 publicly available, but the contact information for the registration 2564 should be. 2566 9.9. Via 2568 The "Via" general-header field MUST be used by gateways and proxies 2569 to indicate the intermediate protocols and recipients between the 2570 user agent and the server on requests, and between the origin server 2571 and the client on responses. It is analogous to the "Received" field 2572 defined in Section 3.6.7 of [RFC5322] and is intended to be used for 2573 tracking message forwards, avoiding request loops, and identifying 2574 the protocol capabilities of all senders along the request/response 2575 chain. 2577 Via = "Via" ":" OWS Via-v 2578 Via-v = 1#( received-protocol RWS received-by 2579 [ RWS comment ] ) 2580 received-protocol = [ protocol-name "/" ] protocol-version 2581 protocol-name = token 2582 protocol-version = token 2583 received-by = ( uri-host [ ":" port ] ) / pseudonym 2584 pseudonym = token 2586 The received-protocol indicates the protocol version of the message 2587 received by the server or client along each segment of the request/ 2588 response chain. The received-protocol version is appended to the Via 2589 field value when the message is forwarded so that information about 2590 the protocol capabilities of upstream applications remains visible to 2591 all recipients. 2593 The protocol-name is optional if and only if it would be "HTTP". The 2594 received-by field is normally the host and optional port number of a 2595 recipient server or client that subsequently forwarded the message. 2596 However, if the real host is considered to be sensitive information, 2597 it MAY be replaced by a pseudonym. If the port is not given, it MAY 2598 be assumed to be the default port of the received-protocol. 2600 Multiple Via field values represent each proxy or gateway that has 2601 forwarded the message. Each recipient MUST append its information 2602 such that the end result is ordered according to the sequence of 2603 forwarding applications. 2605 Comments MAY be used in the Via header field to identify the software 2606 of the recipient proxy or gateway, analogous to the User-Agent and 2607 Server header fields. However, all comments in the Via field are 2608 optional and MAY be removed by any recipient prior to forwarding the 2609 message. 2611 For example, a request message could be sent from an HTTP/1.0 user 2612 agent to an internal proxy code-named "fred", which uses HTTP/1.1 to 2613 forward the request to a public proxy at p.example.net, which 2614 completes the request by forwarding it to the origin server at 2615 www.example.com. The request received by www.example.com would then 2616 have the following Via header field: 2618 Via: 1.0 fred, 1.1 p.example.net (Apache/1.1) 2620 Proxies and gateways used as a portal through a network firewall 2621 SHOULD NOT, by default, forward the names and ports of hosts within 2622 the firewall region. This information SHOULD only be propagated if 2623 explicitly enabled. If not enabled, the received-by host of any host 2624 behind the firewall SHOULD be replaced by an appropriate pseudonym 2625 for that host. 2627 For organizations that have strong privacy requirements for hiding 2628 internal structures, a proxy MAY combine an ordered subsequence of 2629 Via header field entries with identical received-protocol values into 2630 a single such entry. For example, 2632 Via: 1.0 ricky, 1.1 ethel, 1.1 fred, 1.0 lucy 2634 could be collapsed to 2636 Via: 1.0 ricky, 1.1 mertz, 1.0 lucy 2638 Applications SHOULD NOT combine multiple entries unless they are all 2639 under the same organizational control and the hosts have already been 2640 replaced by pseudonyms. Applications MUST NOT combine entries which 2641 have different received-protocol values. 2643 10. IANA Considerations 2645 10.1. Message Header Registration 2647 The Message Header Registry located at should be 2649 updated with the permanent registrations below (see [RFC3864]): 2651 +-------------------+----------+----------+-------------+ 2652 | Header Field Name | Protocol | Status | Reference | 2653 +-------------------+----------+----------+-------------+ 2654 | Connection | http | standard | Section 9.1 | 2655 | Content-Length | http | standard | Section 9.2 | 2656 | Date | http | standard | Section 9.3 | 2657 | Host | http | standard | Section 9.4 | 2658 | TE | http | standard | Section 9.5 | 2659 | Trailer | http | standard | Section 9.6 | 2660 | Transfer-Encoding | http | standard | Section 9.7 | 2661 | Upgrade | http | standard | Section 9.8 | 2662 | Via | http | standard | Section 9.9 | 2663 +-------------------+----------+----------+-------------+ 2665 The change controller is: "IETF (iesg@ietf.org) - Internet 2666 Engineering Task Force". 2668 10.2. URI Scheme Registration 2670 The entries for the "http" and "https" URI Schemes in the registry 2671 located at should 2672 be updated to point to Sections 2.6.1 and 2.6.2 of this document (see 2673 [RFC4395]). 2675 10.3. Internet Media Type Registrations 2677 This document serves as the specification for the Internet media 2678 types "message/http" and "application/http". The following is to be 2679 registered with IANA (see [RFC4288]). 2681 10.3.1. Internet Media Type message/http 2683 The message/http type can be used to enclose a single HTTP request or 2684 response message, provided that it obeys the MIME restrictions for 2685 all "message" types regarding line length and encodings. 2687 Type name: message 2689 Subtype name: http 2691 Required parameters: none 2693 Optional parameters: version, msgtype 2695 version: The HTTP-Version number of the enclosed message (e.g., 2696 "1.1"). If not present, the version can be determined from the 2697 first line of the body. 2699 msgtype: The message type -- "request" or "response". If not 2700 present, the type can be determined from the first line of the 2701 body. 2703 Encoding considerations: only "7bit", "8bit", or "binary" are 2704 permitted 2706 Security considerations: none 2708 Interoperability considerations: none 2710 Published specification: This specification (see Section 10.3.1). 2712 Applications that use this media type: 2714 Additional information: 2716 Magic number(s): none 2718 File extension(s): none 2720 Macintosh file type code(s): none 2722 Person and email address to contact for further information: See 2723 Authors Section. 2725 Intended usage: COMMON 2727 Restrictions on usage: none 2729 Author/Change controller: IESG 2731 10.3.2. Internet Media Type application/http 2733 The application/http type can be used to enclose a pipeline of one or 2734 more HTTP request or response messages (not intermixed). 2736 Type name: application 2738 Subtype name: http 2740 Required parameters: none 2742 Optional parameters: version, msgtype 2744 version: The HTTP-Version number of the enclosed messages (e.g., 2745 "1.1"). If not present, the version can be determined from the 2746 first line of the body. 2748 msgtype: The message type -- "request" or "response". If not 2749 present, the type can be determined from the first line of the 2750 body. 2752 Encoding considerations: HTTP messages enclosed by this type are in 2753 "binary" format; use of an appropriate Content-Transfer-Encoding 2754 is required when transmitted via E-mail. 2756 Security considerations: none 2758 Interoperability considerations: none 2760 Published specification: This specification (see Section 10.3.2). 2762 Applications that use this media type: 2764 Additional information: 2766 Magic number(s): none 2768 File extension(s): none 2770 Macintosh file type code(s): none 2772 Person and email address to contact for further information: See 2773 Authors Section. 2775 Intended usage: COMMON 2776 Restrictions on usage: none 2778 Author/Change controller: IESG 2780 10.4. Transfer Coding Registry 2782 The registration procedure for HTTP Transfer Codings is now defined 2783 by Section 6.2.3 of this document. 2785 The HTTP Transfer Codings Registry located at 2786 should be updated 2787 with the registrations below: 2789 +----------+--------------------------------------+-----------------+ 2790 | Name | Description | Reference | 2791 +----------+--------------------------------------+-----------------+ 2792 | chunked | Transfer in a series of chunks | Section 6.2.1 | 2793 | compress | UNIX "compress" program method | Section 6.2.2.1 | 2794 | deflate | "deflate" compression mechanism | Section 6.2.2.2 | 2795 | | ([RFC1951]) used inside the "zlib" | | 2796 | | data format ([RFC1950]) | | 2797 | gzip | Same as GNU zip [RFC1952] | Section 6.2.2.3 | 2798 +----------+--------------------------------------+-----------------+ 2800 10.5. Upgrade Token Registration 2802 The registration procedure for HTTP Upgrade Tokens -- previously 2803 defined in Section 7.2 of [RFC2817] -- is now defined by 2804 Section 9.8.1 of this document. 2806 The HTTP Status Code Registry located at 2807 should be 2808 updated with the registration below: 2810 +-------+---------------------------+-------------------------------+ 2811 | Value | Description | Reference | 2812 +-------+---------------------------+-------------------------------+ 2813 | HTTP | Hypertext Transfer | Section 2.5 of this | 2814 | | Protocol | specification | 2815 +-------+---------------------------+-------------------------------+ 2817 11. Security Considerations 2819 This section is meant to inform application developers, information 2820 providers, and users of the security limitations in HTTP/1.1 as 2821 described by this document. The discussion does not include 2822 definitive solutions to the problems revealed, though it does make 2823 some suggestions for reducing security risks. 2825 11.1. Personal Information 2827 HTTP clients are often privy to large amounts of personal information 2828 (e.g., the user's name, location, mail address, passwords, encryption 2829 keys, etc.), and SHOULD be very careful to prevent unintentional 2830 leakage of this information. We very strongly recommend that a 2831 convenient interface be provided for the user to control 2832 dissemination of such information, and that designers and 2833 implementors be particularly careful in this area. History shows 2834 that errors in this area often create serious security and/or privacy 2835 problems and generate highly adverse publicity for the implementor's 2836 company. 2838 11.2. Abuse of Server Log Information 2840 A server is in the position to save personal data about a user's 2841 requests which might identify their reading patterns or subjects of 2842 interest. This information is clearly confidential in nature and its 2843 handling can be constrained by law in certain countries. People 2844 using HTTP to provide data are responsible for ensuring that such 2845 material is not distributed without the permission of any individuals 2846 that are identifiable by the published results. 2848 11.3. Attacks Based On File and Path Names 2850 Implementations of HTTP origin servers SHOULD be careful to restrict 2851 the documents returned by HTTP requests to be only those that were 2852 intended by the server administrators. If an HTTP server translates 2853 HTTP URIs directly into file system calls, the server MUST take 2854 special care not to serve files that were not intended to be 2855 delivered to HTTP clients. For example, UNIX, Microsoft Windows, and 2856 other operating systems use ".." as a path component to indicate a 2857 directory level above the current one. On such a system, an HTTP 2858 server MUST disallow any such construct in the request-target if it 2859 would otherwise allow access to a resource outside those intended to 2860 be accessible via the HTTP server. Similarly, files intended for 2861 reference only internally to the server (such as access control 2862 files, configuration files, and script code) MUST be protected from 2863 inappropriate retrieval, since they might contain sensitive 2864 information. Experience has shown that minor bugs in such HTTP 2865 server implementations have turned into security risks. 2867 11.4. DNS Spoofing 2869 Clients using HTTP rely heavily on the Domain Name Service, and are 2870 thus generally prone to security attacks based on the deliberate mis- 2871 association of IP addresses and DNS names. Clients need to be 2872 cautious in assuming the continuing validity of an IP number/DNS name 2873 association. 2875 In particular, HTTP clients SHOULD rely on their name resolver for 2876 confirmation of an IP number/DNS name association, rather than 2877 caching the result of previous host name lookups. Many platforms 2878 already can cache host name lookups locally when appropriate, and 2879 they SHOULD be configured to do so. It is proper for these lookups 2880 to be cached, however, only when the TTL (Time To Live) information 2881 reported by the name server makes it likely that the cached 2882 information will remain useful. 2884 If HTTP clients cache the results of host name lookups in order to 2885 achieve a performance improvement, they MUST observe the TTL 2886 information reported by DNS. 2888 If HTTP clients do not observe this rule, they could be spoofed when 2889 a previously-accessed server's IP address changes. As network 2890 renumbering is expected to become increasingly common [RFC1900], the 2891 possibility of this form of attack will grow. Observing this 2892 requirement thus reduces this potential security vulnerability. 2894 This requirement also improves the load-balancing behavior of clients 2895 for replicated servers using the same DNS name and reduces the 2896 likelihood of a user's experiencing failure in accessing sites which 2897 use that strategy. 2899 11.5. Proxies and Caching 2901 By their very nature, HTTP proxies are men-in-the-middle, and 2902 represent an opportunity for man-in-the-middle attacks. Compromise 2903 of the systems on which the proxies run can result in serious 2904 security and privacy problems. Proxies have access to security- 2905 related information, personal information about individual users and 2906 organizations, and proprietary information belonging to users and 2907 content providers. A compromised proxy, or a proxy implemented or 2908 configured without regard to security and privacy considerations, 2909 might be used in the commission of a wide range of potential attacks. 2911 Proxy operators should protect the systems on which proxies run as 2912 they would protect any system that contains or transports sensitive 2913 information. In particular, log information gathered at proxies 2914 often contains highly sensitive personal information, and/or 2915 information about organizations. Log information should be carefully 2916 guarded, and appropriate guidelines for use should be developed and 2917 followed. (Section 11.2). 2919 Proxy implementors should consider the privacy and security 2920 implications of their design and coding decisions, and of the 2921 configuration options they provide to proxy operators (especially the 2922 default configuration). 2924 Users of a proxy need to be aware that proxies are no trustworthier 2925 than the people who run them; HTTP itself cannot solve this problem. 2927 The judicious use of cryptography, when appropriate, may suffice to 2928 protect against a broad range of security and privacy attacks. Such 2929 cryptography is beyond the scope of the HTTP/1.1 specification. 2931 11.6. Denial of Service Attacks on Proxies 2933 They exist. They are hard to defend against. Research continues. 2934 Beware. 2936 12. Acknowledgments 2938 HTTP has evolved considerably over the years. It has benefited from 2939 a large and active developer community--the many people who have 2940 participated on the www-talk mailing list--and it is that community 2941 which has been most responsible for the success of HTTP and of the 2942 World-Wide Web in general. Marc Andreessen, Robert Cailliau, Daniel 2943 W. Connolly, Bob Denny, John Franks, Jean-Francois Groff, Phillip M. 2944 Hallam-Baker, Hakon W. Lie, Ari Luotonen, Rob McCool, Lou Montulli, 2945 Dave Raggett, Tony Sanders, and Marc VanHeyningen deserve special 2946 recognition for their efforts in defining early aspects of the 2947 protocol. 2949 This document has benefited greatly from the comments of all those 2950 participating in the HTTP-WG. In addition to those already 2951 mentioned, the following individuals have contributed to this 2952 specification: 2954 Gary Adams, Harald Tveit Alvestrand, Keith Ball, Brian Behlendorf, 2955 Paul Burchard, Maurizio Codogno, Josh Cohen, Mike Cowlishaw, Roman 2956 Czyborra, Michael A. Dolan, Daniel DuBois, David J. Fiander, Alan 2957 Freier, Marc Hedlund, Greg Herlihy, Koen Holtman, Alex Hopmann, Bob 2958 Jernigan, Shel Kaphan, Rohit Khare, John Klensin, Martijn Koster, 2959 Alexei Kosut, David M. Kristol, Daniel LaLiberte, Ben Laurie, Paul J. 2960 Leach, Albert Lunde, John C. Mallery, Jean-Philippe Martin-Flatin, 2961 Mitra, David Morris, Gavin Nicol, Ross Patterson, Bill Perry, Jeffrey 2962 Perry, Scott Powers, Owen Rees, Luigi Rizzo, David Robinson, Marc 2963 Salomon, Rich Salz, Allan M. Schiffman, Jim Seidman, Chuck Shotton, 2964 Eric W. Sink, Simon E. Spero, Richard N. Taylor, Robert S. Thau, Bill 2965 (BearHeart) Weinman, Francois Yergeau, Mary Ellen Zurko. 2967 Thanks to the "cave men" of Palo Alto. You know who you are. 2969 Jim Gettys (the editor of [RFC2616]) wishes particularly to thank Roy 2970 Fielding, the editor of [RFC2068], along with John Klensin, Jeff 2971 Mogul, Paul Leach, Dave Kristol, Koen Holtman, John Franks, Josh 2972 Cohen, Alex Hopmann, Scott Lawrence, and Larry Masinter for their 2973 help. And thanks go particularly to Jeff Mogul and Scott Lawrence 2974 for performing the "MUST/MAY/SHOULD" audit. 2976 The Apache Group, Anselm Baird-Smith, author of Jigsaw, and Henrik 2977 Frystyk implemented RFC 2068 early, and we wish to thank them for the 2978 discovery of many of the problems that this document attempts to 2979 rectify. 2981 This specification makes heavy use of the augmented BNF and generic 2982 constructs defined by David H. Crocker for [RFC5234]. Similarly, it 2983 reuses many of the definitions provided by Nathaniel Borenstein and 2984 Ned Freed for MIME [RFC2045]. We hope that their inclusion in this 2985 specification will help reduce past confusion over the relationship 2986 between HTTP and Internet mail message formats. 2988 13. References 2990 13.1. Normative References 2992 [ISO-8859-1] International Organization for Standardization, 2993 "Information technology -- 8-bit single-byte coded 2994 graphic character sets -- Part 1: Latin alphabet No. 2995 1", ISO/IEC 8859-1:1998, 1998. 2997 [Part2] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., 2998 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., 2999 Ed., and J. Reschke, Ed., "HTTP/1.1, part 2: Message 3000 Semantics", draft-ietf-httpbis-p2-semantics-10 (work in 3001 progress), July 2010. 3003 [Part3] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., 3004 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., 3005 Ed., and J. Reschke, Ed., "HTTP/1.1, part 3: Message 3006 Payload and Content Negotiation", 3007 draft-ietf-httpbis-p3-payload-10 (work in progress), 3008 July 2010. 3010 [Part5] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., 3011 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., 3012 Ed., and J. Reschke, Ed., "HTTP/1.1, part 5: Range 3013 Requests and Partial Responses", 3014 draft-ietf-httpbis-p5-range-10 (work in progress), 3015 July 2010. 3017 [Part6] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., 3018 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., 3019 Ed., Nottingham, M., Ed., and J. Reschke, Ed., 3020 "HTTP/1.1, part 6: Caching", 3021 draft-ietf-httpbis-p6-cache-10 (work in progress), 3022 July 2010. 3024 [RFC1950] Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data 3025 Format Specification version 3.3", RFC 1950, May 1996. 3027 RFC 1950 is an Informational RFC, thus it may be less 3028 stable than this specification. On the other hand, 3029 this downward reference was present since the 3030 publication of RFC 2068 in 1997 ([RFC2068]), therefore 3031 it is unlikely to cause problems in practice. See also 3032 [BCP97]. 3034 [RFC1951] Deutsch, P., "DEFLATE Compressed Data Format 3035 Specification version 1.3", RFC 1951, May 1996. 3037 RFC 1951 is an Informational RFC, thus it may be less 3038 stable than this specification. On the other hand, 3039 this downward reference was present since the 3040 publication of RFC 2068 in 1997 ([RFC2068]), therefore 3041 it is unlikely to cause problems in practice. See also 3042 [BCP97]. 3044 [RFC1952] Deutsch, P., Gailly, J-L., Adler, M., Deutsch, L., and 3045 G. Randers-Pehrson, "GZIP file format specification 3046 version 4.3", RFC 1952, May 1996. 3048 RFC 1952 is an Informational RFC, thus it may be less 3049 stable than this specification. On the other hand, 3050 this downward reference was present since the 3051 publication of RFC 2068 in 1997 ([RFC2068]), therefore 3052 it is unlikely to cause problems in practice. See also 3053 [BCP97]. 3055 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3056 Requirement Levels", BCP 14, RFC 2119, March 1997. 3058 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, 3059 "Uniform Resource Identifier (URI): Generic Syntax", 3060 RFC 3986, STD 66, January 2005. 3062 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for 3063 Syntax Specifications: ABNF", STD 68, RFC 5234, 3064 January 2008. 3066 [USASCII] American National Standards Institute, "Coded Character 3067 Set -- 7-bit American Standard Code for Information 3068 Interchange", ANSI X3.4, 1986. 3070 13.2. Informative References 3072 [BCP97] Klensin, J. and S. Hartman, "Handling Normative 3073 References to Standards-Track Documents", BCP 97, 3074 RFC 4897, June 2007. 3076 [Kri2001] Kristol, D., "HTTP Cookies: Standards, Privacy, and 3077 Politics", ACM Transactions on Internet Technology Vol. 3078 1, #2, November 2001, 3079 . 3081 [Nie1997] Frystyk, H., Gettys, J., Prud'hommeaux, E., Lie, H., 3082 and C. Lilley, "Network Performance Effects of 3083 HTTP/1.1, CSS1, and PNG", ACM Proceedings of the ACM 3084 SIGCOMM '97 conference on Applications, technologies, 3085 architectures, and protocols for computer communication 3086 SIGCOMM '97, September 1997, 3087 . 3089 [Pad1995] Padmanabhan, V. and J. Mogul, "Improving HTTP Latency", 3090 Computer Networks and ISDN Systems v. 28, pp. 25-35, 3091 December 1995, 3092 . 3094 [RFC1123] Braden, R., "Requirements for Internet Hosts - 3095 Application and Support", STD 3, RFC 1123, 3096 October 1989. 3098 [RFC1305] Mills, D., "Network Time Protocol (Version 3) 3099 Specification, Implementation", RFC 1305, March 1992. 3101 [RFC1900] Carpenter, B. and Y. Rekhter, "Renumbering Needs Work", 3102 RFC 1900, February 1996. 3104 [RFC1945] Berners-Lee, T., Fielding, R., and H. Nielsen, 3105 "Hypertext Transfer Protocol -- HTTP/1.0", RFC 1945, 3106 May 1996. 3108 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet 3109 Mail Extensions (MIME) Part One: Format of Internet 3110 Message Bodies", RFC 2045, November 1996. 3112 [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail 3113 Extensions) Part Three: Message Header Extensions for 3114 Non-ASCII Text", RFC 2047, November 1996. 3116 [RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and 3117 T. Berners-Lee, "Hypertext Transfer Protocol -- 3118 HTTP/1.1", RFC 2068, January 1997. 3120 [RFC2109] Kristol, D. and L. Montulli, "HTTP State Management 3121 Mechanism", RFC 2109, February 1997. 3123 [RFC2145] Mogul, J., Fielding, R., Gettys, J., and H. Nielsen, 3124 "Use and Interpretation of HTTP Version Numbers", 3125 RFC 2145, May 1997. 3127 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 3128 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 3129 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 3131 [RFC2817] Khare, R. and S. Lawrence, "Upgrading to TLS Within 3132 HTTP/1.1", RFC 2817, May 2000. 3134 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 3136 [RFC2965] Kristol, D. and L. Montulli, "HTTP State Management 3137 Mechanism", RFC 2965, October 2000. 3139 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration 3140 Procedures for Message Header Fields", BCP 90, 3141 RFC 3864, September 2004. 3143 [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications 3144 and Registration Procedures", BCP 13, RFC 4288, 3145 December 2005. 3147 [RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines 3148 and Registration Procedures for New URI Schemes", 3149 BCP 115, RFC 4395, February 2006. 3151 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing 3152 an IANA Considerations Section in RFCs", BCP 26, 3153 RFC 5226, May 2008. 3155 [RFC5322] Resnick, P., "Internet Message Format", RFC 5322, 3156 October 2008. 3158 [Spe] Spero, S., "Analysis of HTTP Performance Problems", 3159 . 3161 [Tou1998] Touch, J., Heidemann, J., and K. Obraczka, "Analysis of 3162 HTTP Performance", ISI Research Report ISI/RR-98-463, 3163 Aug 1998, . 3165 (original report dated Aug. 1996) 3167 Appendix A. Tolerant Applications 3169 Although this document specifies the requirements for the generation 3170 of HTTP/1.1 messages, not all applications will be correct in their 3171 implementation. We therefore recommend that operational applications 3172 be tolerant of deviations whenever those deviations can be 3173 interpreted unambiguously. 3175 Clients SHOULD be tolerant in parsing the Status-Line and servers 3176 SHOULD be tolerant when parsing the Request-Line. In particular, 3177 they SHOULD accept any amount of WSP characters between fields, even 3178 though only a single SP is required. 3180 The line terminator for header fields is the sequence CRLF. However, 3181 we recommend that applications, when parsing such headers, recognize 3182 a single LF as a line terminator and ignore the leading CR. 3184 The character set of an entity-body SHOULD be labeled as the lowest 3185 common denominator of the character codes used within that body, with 3186 the exception that not labeling the entity is preferred over labeling 3187 the entity with the labels US-ASCII or ISO-8859-1. See [Part3]. 3189 Additional rules for requirements on parsing and encoding of dates 3190 and other potential problems with date encodings include: 3192 o HTTP/1.1 clients and caches SHOULD assume that an RFC-850 date 3193 which appears to be more than 50 years in the future is in fact in 3194 the past (this helps solve the "year 2000" problem). 3196 o Although all date formats are specified to be case-sensitive, 3197 recipients SHOULD match day, week and timezone names case- 3198 insensitively. 3200 o An HTTP/1.1 implementation MAY internally represent a parsed 3201 Expires date as earlier than the proper value, but MUST NOT 3202 internally represent a parsed Expires date as later than the 3203 proper value. 3205 o All expiration-related calculations MUST be done in GMT. The 3206 local time zone MUST NOT influence the calculation or comparison 3207 of an age or expiration time. 3209 o If an HTTP header incorrectly carries a date value with a time 3210 zone other than GMT, it MUST be converted into GMT using the most 3211 conservative possible conversion. 3213 Appendix B. Compatibility with Previous Versions 3215 HTTP has been in use by the World-Wide Web global information 3216 initiative since 1990. The first version of HTTP, later referred to 3217 as HTTP/0.9, was a simple protocol for hypertext data transfer across 3218 the Internet with only a single method and no metadata. HTTP/1.0, as 3219 defined by [RFC1945], added a range of request methods and MIME-like 3220 messaging that could include metadata about the data transferred and 3221 modifiers on the request/response semantics. However, HTTP/1.0 did 3222 not sufficiently take into consideration the effects of hierarchical 3223 proxies, caching, the need for persistent connections, or name-based 3224 virtual hosts. The proliferation of incompletely-implemented 3225 applications calling themselves "HTTP/1.0" further necessitated a 3226 protocol version change in order for two communicating applications 3227 to determine each other's true capabilities. 3229 HTTP/1.1 remains compatible with HTTP/1.0 by including more stringent 3230 requirements that enable reliable implementations, adding only those 3231 new features that will either be safely ignored by an HTTP/1.0 3232 recipient or only sent when communicating with a party advertising 3233 compliance with HTTP/1.1. 3235 It is beyond the scope of a protocol specification to mandate 3236 compliance with previous versions. HTTP/1.1 was deliberately 3237 designed, however, to make supporting previous versions easy. It is 3238 worth noting that, at the time of composing this specification, we 3239 would expect general-purpose HTTP/1.1 servers to: 3241 o understand any valid request in the format of HTTP/1.0 and 1.1; 3243 o respond appropriately with a message in the same major version 3244 used by the client. 3246 And we would expect HTTP/1.1 clients to: 3248 o understand any valid response in the format of HTTP/1.0 or 1.1. 3250 For most implementations of HTTP/1.0, each connection is established 3251 by the client prior to the request and closed by the server after 3252 sending the response. Some implementations implement the Keep-Alive 3253 version of persistent connections described in Section 19.7.1 of 3254 [RFC2068]. 3256 B.1. Changes from HTTP/1.0 3258 This section summarizes major differences between versions HTTP/1.0 3259 and HTTP/1.1. 3261 B.1.1. Changes to Simplify Multi-homed Web Servers and Conserve IP 3262 Addresses 3264 The requirements that clients and servers support the Host request- 3265 header, report an error if the Host request-header (Section 9.4) is 3266 missing from an HTTP/1.1 request, and accept absolute URIs 3267 (Section 4.1.2) are among the most important changes defined by this 3268 specification. 3270 Older HTTP/1.0 clients assumed a one-to-one relationship of IP 3271 addresses and servers; there was no other established mechanism for 3272 distinguishing the intended server of a request than the IP address 3273 to which that request was directed. The changes outlined above will 3274 allow the Internet, once older HTTP clients are no longer common, to 3275 support multiple Web sites from a single IP address, greatly 3276 simplifying large operational Web servers, where allocation of many 3277 IP addresses to a single host has created serious problems. The 3278 Internet will also be able to recover the IP addresses that have been 3279 allocated for the sole purpose of allowing special-purpose domain 3280 names to be used in root-level HTTP URLs. Given the rate of growth 3281 of the Web, and the number of servers already deployed, it is 3282 extremely important that all implementations of HTTP (including 3283 updates to existing HTTP/1.0 applications) correctly implement these 3284 requirements: 3286 o Both clients and servers MUST support the Host request-header. 3288 o A client that sends an HTTP/1.1 request MUST send a Host header. 3290 o Servers MUST report a 400 (Bad Request) error if an HTTP/1.1 3291 request does not include a Host request-header. 3293 o Servers MUST accept absolute URIs. 3295 B.2. Compatibility with HTTP/1.0 Persistent Connections 3297 Some clients and servers might wish to be compatible with some 3298 previous implementations of persistent connections in HTTP/1.0 3299 clients and servers. Persistent connections in HTTP/1.0 are 3300 explicitly negotiated as they are not the default behavior. HTTP/1.0 3301 experimental implementations of persistent connections are faulty, 3302 and the new facilities in HTTP/1.1 are designed to rectify these 3303 problems. The problem was that some existing HTTP/1.0 clients may be 3304 sending Keep-Alive to a proxy server that doesn't understand 3305 Connection, which would then erroneously forward it to the next 3306 inbound server, which would establish the Keep-Alive connection and 3307 result in a hung HTTP/1.0 proxy waiting for the close on the 3308 response. The result is that HTTP/1.0 clients must be prevented from 3309 using Keep-Alive when talking to proxies. 3311 However, talking to proxies is the most important use of persistent 3312 connections, so that prohibition is clearly unacceptable. Therefore, 3313 we need some other mechanism for indicating a persistent connection 3314 is desired, which is safe to use even when talking to an old proxy 3315 that ignores Connection. Persistent connections are the default for 3316 HTTP/1.1 messages; we introduce a new keyword (Connection: close) for 3317 declaring non-persistence. See Section 9.1. 3319 The original HTTP/1.0 form of persistent connections (the Connection: 3320 Keep-Alive and Keep-Alive header) is documented in Section 19.7.1 of 3321 [RFC2068]. 3323 B.3. Changes from RFC 2068 3325 This specification has been carefully audited to correct and 3326 disambiguate key word usage; RFC 2068 had many problems in respect to 3327 the conventions laid out in [RFC2119]. 3329 Transfer-coding and message lengths all interact in ways that 3330 required fixing exactly when chunked encoding is used (to allow for 3331 transfer encoding that may not be self delimiting); it was important 3332 to straighten out exactly how message lengths are computed. 3333 (Sections 6.2, 3.4, 9.2, see also [Part3], [Part5] and [Part6]) 3335 The use and interpretation of HTTP version numbers has been clarified 3336 by [RFC2145]. Require proxies to upgrade requests to highest 3337 protocol version they support to deal with problems discovered in 3338 HTTP/1.0 implementations (Section 2.5) 3340 Quality Values of zero should indicate that "I don't want something" 3341 to allow clients to refuse a representation. (Section 6.4) 3343 Transfer-coding had significant problems, particularly with 3344 interactions with chunked encoding. The solution is that transfer- 3345 codings become as full fledged as content-codings. This involves 3346 adding an IANA registry for transfer-codings (separate from content 3347 codings), a new header field (TE) and enabling trailer headers in the 3348 future. Transfer encoding is a major performance benefit, so it was 3349 worth fixing [Nie1997]. TE also solves another, obscure, downward 3350 interoperability problem that could have occurred due to interactions 3351 between authentication trailers, chunked encoding and HTTP/1.0 3352 clients.(Section 6.2, 6.2.1, 7.1.3.2, and 9.5) 3354 Proxies should be able to add Content-Length when appropriate. 3355 (Section 7.1.3.2) 3357 B.4. Changes from RFC 2616 3359 Empty list elements in list productions have been deprecated. 3360 (Section 1.2.1) 3362 Rules about implicit linear whitespace between certain grammar 3363 productions have been removed; now it's only allowed when 3364 specifically pointed out in the ABNF. The NUL character is no longer 3365 allowed in comment and quoted-string text. The quoted-pair rule no 3366 longer allows escaping control characters other than HTAB. Non-ASCII 3367 content in header fields and reason phrase has been obsoleted and 3368 made opaque (the TEXT rule was removed) (Section 1.2.2) 3370 Clarify that HTTP-Version is case sensitive. (Section 2.5) 3372 Remove reference to non-existent identity transfer-coding value 3373 tokens. (Sections 6.2 and 3.4) 3375 Require that invalid whitespace around field-names be rejected. 3376 (Section 3.2) 3378 Update use of abs_path production from RFC1808 to the path-absolute + 3379 query components of RFC3986. (Section 4.1.2) 3381 Clarification that the chunk length does not include the count of the 3382 octets in the chunk header and trailer. Furthermore disallowed line 3383 folding in chunk extensions. (Section 6.2.1) 3385 Remove hard limit of two connections per server. (Section 7.1.4) 3387 Clarify exactly when close connection options must be sent. 3388 (Section 9.1) 3390 Appendix C. Collected ABNF 3392 BWS = OWS 3394 Cache-Control = 3395 Chunked-Body = *chunk last-chunk trailer-part CRLF 3396 Connection = "Connection:" OWS Connection-v 3397 Connection-v = *( "," OWS ) connection-token *( OWS "," [ OWS 3398 connection-token ] ) 3399 Content-Length = "Content-Length:" OWS 1*Content-Length-v 3400 Content-Length-v = 1*DIGIT 3402 Date = "Date:" OWS Date-v 3403 Date-v = HTTP-date 3405 GMT = %x47.4D.54 ; GMT 3407 HTTP-Prot-Name = %x48.54.54.50 ; HTTP 3408 HTTP-Version = HTTP-Prot-Name "/" 1*DIGIT "." 1*DIGIT 3409 HTTP-date = rfc1123-date / obs-date 3410 HTTP-message = start-line *( header-field CRLF ) CRLF [ message-body 3411 ] 3412 Host = "Host:" OWS Host-v 3413 Host-v = uri-host [ ":" port ] 3415 Method = token 3417 OWS = *( [ obs-fold ] WSP ) 3419 Pragma = 3421 RWS = 1*( [ obs-fold ] WSP ) 3422 Reason-Phrase = *( WSP / VCHAR / obs-text ) 3423 Request = Request-Line *( ( general-header / request-header / 3424 entity-header ) CRLF ) CRLF [ message-body ] 3425 Request-Line = Method SP request-target SP HTTP-Version CRLF 3426 Response = Status-Line *( ( general-header / response-header / 3427 entity-header ) CRLF ) CRLF [ message-body ] 3429 Status-Code = 3DIGIT 3430 Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF 3432 TE = "TE:" OWS TE-v 3433 TE-v = [ ( "," / t-codings ) *( OWS "," [ OWS t-codings ] ) ] 3434 Trailer = "Trailer:" OWS Trailer-v 3435 Trailer-v = *( "," OWS ) field-name *( OWS "," [ OWS field-name ] ) 3436 Transfer-Encoding = "Transfer-Encoding:" OWS Transfer-Encoding-v 3437 Transfer-Encoding-v = *( "," OWS ) transfer-coding *( OWS "," [ OWS 3438 transfer-coding ] ) 3440 URI-reference = 3441 Upgrade = "Upgrade:" OWS Upgrade-v 3442 Upgrade-v = *( "," OWS ) product *( OWS "," [ OWS product ] ) 3444 Via = "Via:" OWS Via-v 3445 Via-v = *( "," OWS ) received-protocol RWS received-by [ RWS comment 3446 ] *( OWS "," [ OWS received-protocol RWS received-by [ RWS comment ] 3447 ] ) 3449 Warning = 3451 absolute-URI = 3452 asctime-date = day-name SP date3 SP time-of-day SP year 3453 attribute = token 3454 authority = 3456 chunk = chunk-size *WSP [ chunk-ext ] CRLF chunk-data CRLF 3457 chunk-data = 1*OCTET 3458 chunk-ext = *( ";" *WSP chunk-ext-name [ "=" chunk-ext-val ] *WSP ) 3459 chunk-ext-name = token 3460 chunk-ext-val = token / quoted-str-nf 3461 chunk-size = 1*HEXDIG 3462 comment = "(" *( ctext / quoted-cpair / comment ) ")" 3463 connection-token = token 3464 ctext = OWS / %x21-27 ; '!'-''' 3465 / %x2A-5B ; '*'-'[' 3466 / %x5D-7E ; ']'-'~' 3467 / obs-text 3469 date1 = day SP month SP year 3470 date2 = day "-" month "-" 2DIGIT 3471 date3 = month SP ( 2DIGIT / ( SP DIGIT ) ) 3472 day = 2DIGIT 3473 day-name = %x4D.6F.6E ; Mon 3474 / %x54.75.65 ; Tue 3475 / %x57.65.64 ; Wed 3476 / %x54.68.75 ; Thu 3477 / %x46.72.69 ; Fri 3478 / %x53.61.74 ; Sat 3479 / %x53.75.6E ; Sun 3480 day-name-l = %x4D.6F.6E.64.61.79 ; Monday 3481 / %x54.75.65.73.64.61.79 ; Tuesday 3482 / %x57.65.64.6E.65.73.64.61.79 ; Wednesday 3483 / %x54.68.75.72.73.64.61.79 ; Thursday 3484 / %x46.72.69.64.61.79 ; Friday 3485 / %x53.61.74.75.72.64.61.79 ; Saturday 3486 / %x53.75.6E.64.61.79 ; Sunday 3488 entity-body = 3489 entity-header = 3491 field-content = *( WSP / VCHAR / obs-text ) 3492 field-name = token 3493 field-value = *( field-content / OWS ) 3495 general-header = Cache-Control / Connection / Date / Pragma / Trailer 3496 / Transfer-Encoding / Upgrade / Via / Warning 3498 header-field = field-name ":" OWS [ field-value ] OWS 3499 hour = 2DIGIT 3500 http-URI = "http://" authority path-abempty [ "?" query ] 3501 https-URI = "https://" authority path-abempty [ "?" query ] 3503 last-chunk = 1*"0" *WSP [ chunk-ext ] CRLF 3505 message-body = entity-body / 3506 3507 minute = 2DIGIT 3508 month = %x4A.61.6E ; Jan 3509 / %x46.65.62 ; Feb 3510 / %x4D.61.72 ; Mar 3511 / %x41.70.72 ; Apr 3512 / %x4D.61.79 ; May 3513 / %x4A.75.6E ; Jun 3514 / %x4A.75.6C ; Jul 3515 / %x41.75.67 ; Aug 3516 / %x53.65.70 ; Sep 3517 / %x4F.63.74 ; Oct 3518 / %x4E.6F.76 ; Nov 3519 / %x44.65.63 ; Dec 3521 obs-date = rfc850-date / asctime-date 3522 obs-fold = CRLF 3523 obs-text = %x80-FF 3525 partial-URI = relative-part [ "?" query ] 3526 path-abempty = 3527 path-absolute = 3528 port = 3529 product = token [ "/" product-version ] 3530 product-version = token 3531 protocol-name = token 3532 protocol-version = token 3533 pseudonym = token 3535 qdtext = OWS / "!" / %x23-5B ; '#'-'[' 3536 / %x5D-7E ; ']'-'~' 3537 / obs-text 3538 qdtext-nf = WSP / "!" / %x23-5B ; '#'-'[' 3539 / %x5D-7E ; ']'-'~' 3540 / obs-text 3541 query = 3542 quoted-cpair = "\" ( WSP / VCHAR / obs-text ) 3543 quoted-pair = "\" ( WSP / VCHAR / obs-text ) 3544 quoted-str-nf = DQUOTE *( qdtext-nf / quoted-pair ) DQUOTE 3545 quoted-string = DQUOTE *( qdtext / quoted-pair ) DQUOTE 3546 qvalue = ( "0" [ "." *3DIGIT ] ) / ( "1" [ "." *3"0" ] ) 3548 received-by = ( uri-host [ ":" port ] ) / pseudonym 3549 received-protocol = [ protocol-name "/" ] protocol-version 3550 relative-part = 3551 request-header = 3552 request-target = "*" / absolute-URI / ( path-absolute [ "?" query ] ) 3553 / authority 3554 response-header = 3555 rfc1123-date = day-name "," SP date1 SP time-of-day SP GMT 3556 rfc850-date = day-name-l "," SP date2 SP time-of-day SP GMT 3558 second = 2DIGIT 3559 special = "(" / ")" / "<" / ">" / "@" / "," / ";" / ":" / "\" / 3560 DQUOTE / "/" / "[" / "]" / "?" / "=" / "{" / "}" 3561 start-line = Request-Line / Status-Line 3563 t-codings = "trailers" / ( transfer-extension [ te-params ] ) 3564 tchar = "!" / "#" / "$" / "%" / "&" / "'" / "*" / "+" / "-" / "." / 3565 "^" / "_" / "`" / "|" / "~" / DIGIT / ALPHA 3566 te-ext = OWS ";" OWS token [ "=" word ] 3567 te-params = OWS ";" OWS "q=" qvalue *te-ext 3568 time-of-day = hour ":" minute ":" second 3569 token = 1*tchar 3570 trailer-part = *( entity-header CRLF ) 3571 transfer-coding = "chunked" / "compress" / "deflate" / "gzip" / 3572 transfer-extension 3573 transfer-extension = token *( OWS ";" OWS transfer-parameter ) 3574 transfer-parameter = attribute BWS "=" BWS value 3576 uri-host = 3578 value = word 3580 word = token / quoted-string 3582 year = 4DIGIT 3583 ABNF diagnostics: 3585 ; Chunked-Body defined but not used 3586 ; Content-Length defined but not used 3587 ; HTTP-message defined but not used 3588 ; Host defined but not used 3589 ; Request defined but not used 3590 ; Response defined but not used 3591 ; TE defined but not used 3592 ; URI-reference defined but not used 3593 ; http-URI defined but not used 3594 ; https-URI defined but not used 3595 ; partial-URI defined but not used 3596 ; special defined but not used 3598 Appendix D. Change Log (to be removed by RFC Editor before publication) 3600 D.1. Since RFC2616 3602 Extracted relevant partitions from [RFC2616]. 3604 D.2. Since draft-ietf-httpbis-p1-messaging-00 3606 Closed issues: 3608 o : "HTTP Version 3609 should be case sensitive" 3610 () 3612 o : "'unsafe' 3613 characters" () 3615 o : "Chunk Size 3616 Definition" () 3618 o : "Message Length" 3619 () 3621 o : "Media Type 3622 Registrations" () 3624 o : "URI includes 3625 query" () 3627 o : "No close on 3628 1xx responses" () 3630 o : "Remove 3631 'identity' token references" 3632 () 3634 o : "Import query 3635 BNF" 3637 o : "qdtext BNF" 3639 o : "Normative and 3640 Informative references" 3642 o : "RFC2606 3643 Compliance" 3645 o : "RFC977 3646 reference" 3648 o : "RFC1700 3649 references" 3651 o : "inconsistency 3652 in date format explanation" 3654 o : "Date reference 3655 typo" 3657 o : "Informative 3658 references" 3660 o : "ISO-8859-1 3661 Reference" 3663 o : "Normative up- 3664 to-date references" 3666 Other changes: 3668 o Update media type registrations to use RFC4288 template. 3670 o Use names of RFC4234 core rules DQUOTE and WSP, fix broken ABNF 3671 for chunk-data (work in progress on 3672 ) 3674 D.3. Since draft-ietf-httpbis-p1-messaging-01 3676 Closed issues: 3678 o : "Bodies on GET 3679 (and other) requests" 3681 o : "Updating to 3682 RFC4288" 3684 o : "Status Code 3685 and Reason Phrase" 3687 o : "rel_path not 3688 used" 3690 Ongoing work on ABNF conversion 3691 (): 3693 o Get rid of duplicate BNF rule names ("host" -> "uri-host", 3694 "trailer" -> "trailer-part"). 3696 o Avoid underscore character in rule names ("http_URL" -> "http- 3697 URL", "abs_path" -> "path-absolute"). 3699 o Add rules for terms imported from URI spec ("absoluteURI", 3700 "authority", "path-absolute", "port", "query", "relativeURI", 3701 "host) -- these will have to be updated when switching over to 3702 RFC3986. 3704 o Synchronize core rules with RFC5234. 3706 o Get rid of prose rules that span multiple lines. 3708 o Get rid of unused rules LOALPHA and UPALPHA. 3710 o Move "Product Tokens" section (back) into Part 1, as "token" is 3711 used in the definition of the Upgrade header. 3713 o Add explicit references to BNF syntax and rules imported from 3714 other parts of the specification. 3716 o Rewrite prose rule "token" in terms of "tchar", rewrite prose rule 3717 "TEXT". 3719 D.4. Since draft-ietf-httpbis-p1-messaging-02 3721 Closed issues: 3723 o : "HTTP-date vs. 3724 rfc1123-date" 3726 o : "WS in quoted- 3727 pair" 3729 Ongoing work on IANA Message Header Registration 3730 (): 3732 o Reference RFC 3984, and update header registrations for headers 3733 defined in this document. 3735 Ongoing work on ABNF conversion 3736 (): 3738 o Replace string literals when the string really is case-sensitive 3739 (HTTP-Version). 3741 D.5. Since draft-ietf-httpbis-p1-messaging-03 3743 Closed issues: 3745 o : "Connection 3746 closing" 3748 o : "Move 3749 registrations and registry information to IANA Considerations" 3751 o : "need new URL 3752 for PAD1995 reference" 3754 o : "IANA 3755 Considerations: update HTTP URI scheme registration" 3757 o : "Cite HTTPS 3758 URI scheme definition" 3760 o : "List-type 3761 headers vs Set-Cookie" 3763 Ongoing work on ABNF conversion 3764 (): 3766 o Replace string literals when the string really is case-sensitive 3767 (HTTP-Date). 3769 o Replace HEX by HEXDIG for future consistence with RFC 5234's core 3770 rules. 3772 D.6. Since draft-ietf-httpbis-p1-messaging-04 3774 Closed issues: 3776 o : "Out-of-date 3777 reference for URIs" 3779 o : "RFC 2822 is 3780 updated by RFC 5322" 3782 Ongoing work on ABNF conversion 3783 (): 3785 o Use "/" instead of "|" for alternatives. 3787 o Get rid of RFC822 dependency; use RFC5234 plus extensions instead. 3789 o Only reference RFC 5234's core rules. 3791 o Introduce new ABNF rules for "bad" whitespace ("BWS"), optional 3792 whitespace ("OWS") and required whitespace ("RWS"). 3794 o Rewrite ABNFs to spell out whitespace rules, factor out header 3795 value format definitions. 3797 D.7. Since draft-ietf-httpbis-p1-messaging-05 3799 Closed issues: 3801 o : "Header LWS" 3803 o : "Sort 1.3 3804 Terminology" 3806 o : "RFC2047 3807 encoded words" 3809 o : "Character 3810 Encodings in TEXT" 3812 o : "Line Folding" 3813 o : "OPTIONS * and 3814 proxies" 3816 o : "Reason-Phrase 3817 BNF" 3819 o : "Use of TEXT" 3821 o : "Join 3822 "Differences Between HTTP Entities and RFC 2045 Entities"?" 3824 o : "RFC822 3825 reference left in discussion of date formats" 3827 Final work on ABNF conversion 3828 (): 3830 o Rewrite definition of list rules, deprecate empty list elements. 3832 o Add appendix containing collected and expanded ABNF. 3834 Other changes: 3836 o Rewrite introduction; add mostly new Architecture Section. 3838 o Move definition of quality values from Part 3 into Part 1; make TE 3839 request header grammar independent of accept-params (defined in 3840 Part 3). 3842 D.8. Since draft-ietf-httpbis-p1-messaging-06 3844 Closed issues: 3846 o : "base for 3847 numeric protocol elements" 3849 o : "comment ABNF" 3851 Partly resolved issues: 3853 o : "205 Bodies" 3854 (took out language that implied that there may be methods for 3855 which a request body MUST NOT be included) 3857 o : "editorial 3858 improvements around HTTP-date" 3860 D.9. Since draft-ietf-httpbis-p1-messaging-07 3862 Closed issues: 3864 o : "Repeating 3865 single-value headers" 3867 o : "increase 3868 connection limit" 3870 o : "IP addresses 3871 in URLs" 3873 o : "take over 3874 HTTP Upgrade Token Registry" 3876 o : "CR and LF in 3877 chunk extension values" 3879 o : "HTTP/0.9 3880 support" 3882 o : "pick IANA 3883 policy (RFC5226) for Transfer Coding / Content Coding" 3885 o : "move 3886 definitions of gzip/deflate/compress to part 1" 3888 o : "disallow 3889 control characters in quoted-pair" 3891 Partly resolved issues: 3893 o : "update IANA 3894 requirements wrt Transfer-Coding values" (add the IANA 3895 Considerations subsection) 3897 D.10. Since draft-ietf-httpbis-p1-messaging-08 3899 Closed issues: 3901 o : "header 3902 parsing, treatment of leading and trailing OWS" 3904 Partly resolved issues: 3906 o : "Placement of 3907 13.5.1 and 13.5.2" 3909 o : "use of term 3910 "word" when talking about header structure" 3912 D.11. Since draft-ietf-httpbis-p1-messaging-09 3914 Closed issues: 3916 o : "Clarification 3917 of the term 'deflate'" 3919 o : "OPTIONS * and 3920 proxies" 3922 o : "IANA registry 3923 for content/transfer encodings" 3925 o : "Case- 3926 sensitivity of HTTP-date" 3928 o : "use of term 3929 "word" when talking about header structure" 3931 Partly resolved issues: 3933 o : "Term for the 3934 requested resource's URI" 3936 Index 3938 A 3939 application/http Media Type 60 3941 C 3942 cache 13 3943 cacheable 14 3944 chunked (Coding Format) 34 3945 client 11 3946 Coding Format 3947 chunked 34 3948 compress 36 3949 deflate 37 3950 gzip 37 3951 compress (Coding Format) 36 3952 connection 11 3953 Connection header 48 3954 Content-Length header 49 3956 D 3957 Date header 50 3958 deflate (Coding Format) 37 3959 downstream 12 3961 E 3962 Effective Request URI 28 3964 G 3965 gateway 13 3966 Grammar 3967 absolute-URI 16 3968 ALPHA 7 3969 asctime-date 33 3970 attribute 33 3971 authority 16 3972 BWS 9 3973 chunk 35 3974 chunk-data 35 3975 chunk-ext 35 3976 chunk-ext-name 35 3977 chunk-ext-val 35 3978 chunk-size 35 3979 Chunked-Body 35 3980 comment 22 3981 Connection 48 3982 connection-token 48 3983 Connection-v 48 3984 Content-Length 49 3985 Content-Length-v 49 3986 CR 7 3987 CRLF 7 3988 ctext 22 3989 CTL 7 3990 Date 50 3991 Date-v 50 3992 date1 32 3993 date2 33 3994 date3 33 3995 day 32 3996 day-name 32 3997 day-name-l 32 3998 DIGIT 7 3999 DQUOTE 7 4000 extension-code 31 4001 extension-method 25 4002 field-content 20 4003 field-name 20 4004 field-value 20 4005 general-header 25 4006 GMT 32 4007 header-field 20 4008 HEXDIG 7 4009 Host 51 4010 Host-v 51 4011 hour 32 4012 HTTP-date 31 4013 HTTP-message 19 4014 HTTP-Prot-Name 15 4015 http-URI 17 4016 HTTP-Version 15 4017 https-URI 18 4018 last-chunk 35 4019 LF 7 4020 message-body 22 4021 Method 25 4022 minute 32 4023 month 32 4024 obs-date 32 4025 obs-text 10 4026 OCTET 7 4027 OWS 9 4028 path-absolute 16 4029 port 16 4030 product 38 4031 product-version 38 4032 protocol-name 56 4033 protocol-version 56 4034 pseudonym 56 4035 qdtext 10 4036 qdtext-nf 35 4037 query 16 4038 quoted-cpair 22 4039 quoted-pair 10 4040 quoted-str-nf 35 4041 quoted-string 10 4042 qvalue 38 4043 Reason-Phrase 31 4044 received-by 56 4045 received-protocol 56 4046 Request 25 4047 Request-Line 25 4048 request-target 26 4049 Response 30 4050 rfc850-date 33 4051 rfc1123-date 32 4052 RWS 9 4053 second 32 4054 SP 7 4055 special 10 4056 Status-Code 31 4057 Status-Line 30 4058 t-codings 52 4059 tchar 10 4060 TE 52 4061 te-ext 52 4062 te-params 52 4063 TE-v 52 4064 time-of-day 32 4065 token 10 4066 Trailer 53 4067 trailer-part 35 4068 Trailer-v 53 4069 transfer-coding 33 4070 Transfer-Encoding 54 4071 Transfer-Encoding-v 54 4072 transfer-extension 33 4073 transfer-parameter 33 4074 Upgrade 54 4075 Upgrade-v 54 4076 uri-host 16 4077 URI-reference 16 4078 value 33 4079 VCHAR 7 4080 Via 56 4081 Via-v 56 4082 word 10 4083 WSP 7 4084 year 32 4085 gzip (Coding Format) 37 4087 H 4088 header field 19 4089 header section 19 4090 Headers 4091 Connection 48 4092 Content-Length 49 4093 Date 50 4094 Host 51 4095 TE 52 4096 Trailer 53 4097 Transfer-Encoding 54 4098 Upgrade 54 4099 Via 56 4100 headers 19 4101 Host header 51 4102 http URI scheme 17 4103 https URI scheme 18 4105 I 4106 inbound 12 4108 M 4109 Media Type 4110 application/http 60 4111 message/http 58 4112 message 11 4113 message/http Media Type 58 4115 O 4116 origin server 11 4117 outbound 12 4119 P 4120 proxy 13 4122 R 4123 request 11 4124 resource 16 4125 response 11 4126 reverse proxy 13 4128 S 4129 server 11 4131 T 4132 TE header 52 4133 Trailer header 53 4134 Transfer-Encoding header 54 4135 tunnel 13 4137 U 4138 Upgrade header 54 4139 upstream 12 4140 URI scheme 4141 http 17 4142 https 18 4143 user agent 11 4145 V 4146 Via header 56 4148 Authors' Addresses 4150 Roy T. Fielding (editor) 4151 Day Software 4152 23 Corporate Plaza DR, Suite 280 4153 Newport Beach, CA 92660 4154 USA 4156 Phone: +1-949-706-5300 4157 Fax: +1-949-706-5305 4158 EMail: fielding@gbiv.com 4159 URI: http://roy.gbiv.com/ 4161 Jim Gettys 4162 Alcatel-Lucent Bell Labs 4163 21 Oak Knoll Road 4164 Carlisle, MA 01741 4165 USA 4167 EMail: jg@freedesktop.org 4168 URI: http://gettys.wordpress.com/ 4170 Jeffrey C. Mogul 4171 Hewlett-Packard Company 4172 HP Labs, Large Scale Systems Group 4173 1501 Page Mill Road, MS 1177 4174 Palo Alto, CA 94304 4175 USA 4177 EMail: JeffMogul@acm.org 4179 Henrik Frystyk Nielsen 4180 Microsoft Corporation 4181 1 Microsoft Way 4182 Redmond, WA 98052 4183 USA 4185 EMail: henrikn@microsoft.com 4186 Larry Masinter 4187 Adobe Systems, Incorporated 4188 345 Park Ave 4189 San Jose, CA 95110 4190 USA 4192 EMail: LMM@acm.org 4193 URI: http://larry.masinter.net/ 4195 Paul J. Leach 4196 Microsoft Corporation 4197 1 Microsoft Way 4198 Redmond, WA 98052 4200 EMail: paulle@microsoft.com 4202 Tim Berners-Lee 4203 World Wide Web Consortium 4204 MIT Computer Science and Artificial Intelligence Laboratory 4205 The Stata Center, Building 32 4206 32 Vassar Street 4207 Cambridge, MA 02139 4208 USA 4210 EMail: timbl@w3.org 4211 URI: http://www.w3.org/People/Berners-Lee/ 4213 Yves Lafon (editor) 4214 World Wide Web Consortium 4215 W3C / ERCIM 4216 2004, rte des Lucioles 4217 Sophia-Antipolis, AM 06902 4218 France 4220 EMail: ylafon@w3.org 4221 URI: http://www.raubacapeu.net/people/yves/ 4222 Julian F. Reschke (editor) 4223 greenbytes GmbH 4224 Hafenweg 16 4225 Muenster, NW 48155 4226 Germany 4228 Phone: +49 251 2807760 4229 Fax: +49 251 2807761 4230 EMail: julian.reschke@greenbytes.de 4231 URI: http://greenbytes.de/tech/webdav/