idnits 2.17.00 (12 Aug 2021) /tmp/idnits31217/draft-ietf-httpbis-p1-messaging-12.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 : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC2817, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC2817, updated by this document, for RFC5378 checks: 1998-11-18) -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 25, 2010) is 4225 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 3124, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO-8859-1' == Outdated reference: draft-ietf-httpbis-p2-semantics has been published as RFC 7231 == Outdated reference: A later version (-20) exists of draft-ietf-httpbis-p3-payload-12 == Outdated reference: draft-ietf-httpbis-p6-cache has been published as RFC 7234 ** 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 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 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 (~~), 5 warnings (==), 14 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: April 28, 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 October 25, 2010 22 HTTP/1.1, part 1: URIs, Connections, and Message Parsing 23 draft-ietf-httpbis-p1-messaging-12 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.13. 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 April 28, 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-related architecture . . . . . . . . . . . . . . . . . . 10 101 2.1. Client/Server Messaging . . . . . . . . . . . . . . . . . 10 102 2.2. Intermediaries . . . . . . . . . . . . . . . . . . . . . . 12 103 2.3. Caches . . . . . . . . . . . . . . . . . . . . . . . . . . 13 104 2.4. Transport Independence . . . . . . . . . . . . . . . . . . 14 105 2.5. HTTP Version . . . . . . . . . . . . . . . . . . . . . . . 14 106 2.6. Uniform Resource Identifiers . . . . . . . . . . . . . . . 16 107 2.6.1. http URI scheme . . . . . . . . . . . . . . . . . . . 16 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. General Header Fields . . . . . . . . . . . . . . . . . . 25 115 4. Request . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 116 4.1. Request-Line . . . . . . . . . . . . . . . . . . . . . . . 26 117 4.1.1. Method . . . . . . . . . . . . . . . . . . . . . . . . 26 118 4.1.2. request-target . . . . . . . . . . . . . . . . . . . . 27 119 4.2. The Resource Identified by a Request . . . . . . . . . . . 29 120 4.3. Effective Request URI . . . . . . . . . . . . . . . . . . 29 121 5. Response . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 122 5.1. Status-Line . . . . . . . . . . . . . . . . . . . . . . . 31 123 5.1.1. Status Code and Reason Phrase . . . . . . . . . . . . 31 124 6. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 32 125 6.1. Date/Time Formats: Full Date . . . . . . . . . . . . . . . 32 126 6.2. Transfer Codings . . . . . . . . . . . . . . . . . . . . . 34 127 6.2.1. Chunked Transfer Coding . . . . . . . . . . . . . . . 35 128 6.2.2. Compression Codings . . . . . . . . . . . . . . . . . 37 129 6.2.3. Transfer Coding Registry . . . . . . . . . . . . . . . 38 130 6.3. Product Tokens . . . . . . . . . . . . . . . . . . . . . . 39 131 6.4. Quality Values . . . . . . . . . . . . . . . . . . . . . . 39 132 7. Connections . . . . . . . . . . . . . . . . . . . . . . . . . 39 133 7.1. Persistent Connections . . . . . . . . . . . . . . . . . . 40 134 7.1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . 40 135 7.1.2. Overall Operation . . . . . . . . . . . . . . . . . . 40 136 7.1.3. Proxy Servers . . . . . . . . . . . . . . . . . . . . 42 137 7.1.4. Practical Considerations . . . . . . . . . . . . . . . 44 138 7.2. Message Transmission Requirements . . . . . . . . . . . . 45 139 7.2.1. Persistent Connections and Flow Control . . . . . . . 45 140 7.2.2. Monitoring Connections for Error Status Messages . . . 45 141 7.2.3. Use of the 100 (Continue) Status . . . . . . . . . . . 46 142 7.2.4. Client Behavior if Server Prematurely Closes 143 Connection . . . . . . . . . . . . . . . . . . . . . . 48 144 8. Miscellaneous notes that might disappear . . . . . . . . . . . 49 145 8.1. Scheme aliases considered harmful . . . . . . . . . . . . 49 146 8.2. Use of HTTP for proxy communication . . . . . . . . . . . 49 147 8.3. Interception of HTTP for access control . . . . . . . . . 49 148 8.4. Use of HTTP by other protocols . . . . . . . . . . . . . . 49 149 8.5. Use of HTTP by media type specification . . . . . . . . . 49 150 9. Header Field Definitions . . . . . . . . . . . . . . . . . . . 49 151 9.1. Connection . . . . . . . . . . . . . . . . . . . . . . . . 49 152 9.2. Content-Length . . . . . . . . . . . . . . . . . . . . . . 50 153 9.3. Date . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 154 9.3.1. Clockless Origin Server Operation . . . . . . . . . . 52 155 9.4. Host . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 156 9.5. TE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 157 9.6. Trailer . . . . . . . . . . . . . . . . . . . . . . . . . 54 158 9.7. Transfer-Encoding . . . . . . . . . . . . . . . . . . . . 55 159 9.8. Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . 55 160 9.8.1. Upgrade Token Registry . . . . . . . . . . . . . . . . 56 161 9.9. Via . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 162 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 59 163 10.1. Header Field Registration . . . . . . . . . . . . . . . . 59 164 10.2. URI Scheme Registration . . . . . . . . . . . . . . . . . 59 165 10.3. Internet Media Type Registrations . . . . . . . . . . . . 59 166 10.3.1. Internet Media Type message/http . . . . . . . . . . . 59 167 10.3.2. Internet Media Type application/http . . . . . . . . . 61 168 10.4. Transfer Coding Registry . . . . . . . . . . . . . . . . . 62 169 10.5. Upgrade Token Registration . . . . . . . . . . . . . . . . 62 170 11. Security Considerations . . . . . . . . . . . . . . . . . . . 62 171 11.1. Personal Information . . . . . . . . . . . . . . . . . . . 63 172 11.2. Abuse of Server Log Information . . . . . . . . . . . . . 63 173 11.3. Attacks Based On File and Path Names . . . . . . . . . . . 63 174 11.4. DNS Spoofing . . . . . . . . . . . . . . . . . . . . . . . 63 175 11.5. Proxies and Caching . . . . . . . . . . . . . . . . . . . 64 176 11.6. Denial of Service Attacks on Proxies . . . . . . . . . . . 65 177 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 65 178 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 66 179 13.1. Normative References . . . . . . . . . . . . . . . . . . . 66 180 13.2. Informative References . . . . . . . . . . . . . . . . . . 68 181 Appendix A. Tolerant Applications . . . . . . . . . . . . . . . . 70 182 Appendix B. Compatibility with Previous Versions . . . . . . . . 71 183 B.1. Changes from HTTP/1.0 . . . . . . . . . . . . . . . . . . 71 184 B.1.1. Changes to Simplify Multi-homed Web Servers and 185 Conserve IP Addresses . . . . . . . . . . . . . . . . 72 186 B.2. Compatibility with HTTP/1.0 Persistent Connections . . . . 72 187 B.3. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 73 188 Appendix C. Collected ABNF . . . . . . . . . . . . . . . . . . . 74 189 Appendix D. Change Log (to be removed by RFC Editor before 190 publication) . . . . . . . . . . . . . . . . . . . . 78 191 D.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 78 192 D.2. Since draft-ietf-httpbis-p1-messaging-00 . . . . . . . . . 78 193 D.3. Since draft-ietf-httpbis-p1-messaging-01 . . . . . . . . . 80 194 D.4. Since draft-ietf-httpbis-p1-messaging-02 . . . . . . . . . 81 195 D.5. Since draft-ietf-httpbis-p1-messaging-03 . . . . . . . . . 81 196 D.6. Since draft-ietf-httpbis-p1-messaging-04 . . . . . . . . . 82 197 D.7. Since draft-ietf-httpbis-p1-messaging-05 . . . . . . . . . 82 198 D.8. Since draft-ietf-httpbis-p1-messaging-06 . . . . . . . . . 83 199 D.9. Since draft-ietf-httpbis-p1-messaging-07 . . . . . . . . . 84 200 D.10. Since draft-ietf-httpbis-p1-messaging-08 . . . . . . . . . 84 201 D.11. Since draft-ietf-httpbis-p1-messaging-09 . . . . . . . . . 85 202 D.12. Since draft-ietf-httpbis-p1-messaging-10 . . . . . . . . . 85 203 D.13. Since draft-ietf-httpbis-p1-messaging-11 . . . . . . . . . 86 204 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 206 1. Introduction 208 The Hypertext Transfer Protocol (HTTP) is an application-level 209 request/response protocol that uses extensible semantics and MIME- 210 like message payloads for flexible interaction with network-based 211 hypertext information systems. HTTP relies upon the Uniform Resource 212 Identifier (URI) standard [RFC3986] to indicate request targets and 213 relationships between resources. Messages are passed in a format 214 similar to that used by Internet mail [RFC5322] and the Multipurpose 215 Internet Mail Extensions (MIME) [RFC2045] (see Appendix A of [Part3] 216 for the differences between HTTP and MIME messages). 218 HTTP is a generic interface protocol for information systems. It is 219 designed to hide the details of how a service is implemented by 220 presenting a uniform interface to clients that is independent of the 221 types of resources provided. Likewise, servers do not need to be 222 aware of each client's purpose: an HTTP request can be considered in 223 isolation rather than being associated with a specific type of client 224 or a predetermined sequence of application steps. The result is a 225 protocol that can be used effectively in many different contexts and 226 for which implementations can evolve independently over time. 228 HTTP is also designed for use as an intermediation protocol for 229 translating communication to and from non-HTTP information systems. 230 HTTP proxies and gateways can provide access to alternative 231 information services by translating their diverse protocols into a 232 hypertext format that can be viewed and manipulated by clients in the 233 same way as HTTP services. 235 One consequence of HTTP flexibility is that the protocol cannot be 236 defined in terms of what occurs behind the interface. Instead, we 237 are limited to defining the syntax of communication, the intent of 238 received communication, and the expected behavior of recipients. If 239 the communication is considered in isolation, then successful actions 240 ought to be reflected in corresponding changes to the observable 241 interface provided by servers. However, since multiple clients might 242 act in parallel and perhaps at cross-purposes, we cannot require that 243 such changes be observable beyond the scope of a single response. 245 This document is Part 1 of the seven-part specification of HTTP, 246 defining the protocol referred to as "HTTP/1.1" and obsoleting 247 [RFC2616]. Part 1 describes the architectural elements that are used 248 or referred to in HTTP, defines the "http" and "https" URI schemes, 249 describes overall network operation and connection management, and 250 defines HTTP message framing and forwarding requirements. Our goal 251 is to define all of the mechanisms necessary for HTTP message 252 handling that are independent of message semantics, thereby defining 253 the complete set of requirements for message parsers and message- 254 forwarding intermediaries. 256 1.1. Requirements 258 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 259 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 260 document are to be interpreted as described in [RFC2119]. 262 An implementation is not compliant if it fails to satisfy one or more 263 of the "MUST" or "REQUIRED" level requirements for the protocols it 264 implements. An implementation that satisfies all the "MUST" or 265 "REQUIRED" level and all the "SHOULD" level requirements for its 266 protocols is said to be "unconditionally compliant"; one that 267 satisfies all the "MUST" level requirements but not all the "SHOULD" 268 level requirements for its protocols is said to be "conditionally 269 compliant". 271 1.2. Syntax Notation 273 This specification uses the Augmented Backus-Naur Form (ABNF) 274 notation of [RFC5234]. 276 The following core rules are included by reference, as defined in 277 [RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF 278 (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote), 279 HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any 8-bit 280 sequence of data), SP (space), VCHAR (any visible [USASCII] 281 character), and WSP (whitespace). 283 As a syntactic convention, ABNF rule names prefixed with "obs-" 284 denote "obsolete" grammar rules that appear for historical reasons. 286 1.2.1. ABNF Extension: #rule 288 The #rule extension to the ABNF rules of [RFC5234] is used to improve 289 readability. 291 A construct "#" is defined, similar to "*", for defining comma- 292 delimited lists of elements. The full form is "#element" 293 indicating at least and at most elements, each separated by a 294 single comma (",") and optional whitespace (OWS, Section 1.2.2). 296 Thus, 298 1#element => element *( OWS "," OWS element ) 300 and: 302 #element => [ 1#element ] 304 and for n >= 1 and m > 1: 306 #element => element *( OWS "," OWS element ) 308 For compatibility with legacy list rules, recipients SHOULD accept 309 empty list elements. In other words, consumers would follow the list 310 productions: 312 #element => [ ( "," / element ) *( OWS "," [ OWS element ] ) ] 314 1#element => *( "," OWS ) element *( OWS "," [ OWS element ] ) 316 Note that empty elements do not contribute to the count of elements 317 present, though. 319 For example, given these ABNF productions: 321 example-list = 1#example-list-elmt 322 example-list-elmt = token ; see Section 1.2.2 324 Then these are valid values for example-list (not including the 325 double quotes, which are present for delimitation only): 327 "foo,bar" 328 " foo ,bar," 329 " foo , ,bar,charlie " 330 "foo ,bar, charlie " 332 But these values would be invalid, as at least one non-empty element 333 is required: 335 "" 336 "," 337 ", ," 339 Appendix C shows the collected ABNF, with the list rules expanded as 340 explained above. 342 1.2.2. Basic Rules 344 HTTP/1.1 defines the sequence CR LF as the end-of-line marker for all 345 protocol elements other than the message-body (see Appendix A for 346 tolerant applications). 348 This specification uses three rules to denote the use of linear 349 whitespace: OWS (optional whitespace), RWS (required whitespace), and 350 BWS ("bad" whitespace). 352 The OWS rule is used where zero or more linear whitespace characters 353 might appear. OWS SHOULD either not be produced or be produced as a 354 single SP character. Multiple OWS characters that occur within 355 field-content SHOULD be replaced with a single SP before interpreting 356 the field value or forwarding the message downstream. 358 RWS is used when at least one linear whitespace character is required 359 to separate field tokens. RWS SHOULD be produced as a single SP 360 character. Multiple RWS characters that occur within field-content 361 SHOULD be replaced with a single SP before interpreting the field 362 value or forwarding the message downstream. 364 BWS is used where the grammar allows optional whitespace for 365 historical reasons but senders SHOULD NOT produce it in messages. 366 HTTP/1.1 recipients MUST accept such bad optional whitespace and 367 remove it before interpreting the field value or forwarding the 368 message downstream. 370 OWS = *( [ obs-fold ] WSP ) 371 ; "optional" whitespace 372 RWS = 1*( [ obs-fold ] WSP ) 373 ; "required" whitespace 374 BWS = OWS 375 ; "bad" whitespace 376 obs-fold = CRLF 377 ; see Section 3.2 379 Many HTTP/1.1 header field values consist of words (token or quoted- 380 string) separated by whitespace or special characters. These special 381 characters MUST be in a quoted string to be used within a parameter 382 value (as defined in Section 6.2). 384 word = token / quoted-string 386 token = 1*tchar 388 tchar = "!" / "#" / "$" / "%" / "&" / "'" / "*" 389 / "+" / "-" / "." / "^" / "_" / "`" / "|" / "~" 390 / DIGIT / ALPHA 391 ; any VCHAR, except special 393 special = "(" / ")" / "<" / ">" / "@" / "," 394 / ";" / ":" / "\" / DQUOTE / "/" / "[" 395 / "]" / "?" / "=" / "{" / "}" 397 A string of text is parsed as a single word if it is quoted using 398 double-quote marks. 400 quoted-string = DQUOTE *( qdtext / quoted-pair ) DQUOTE 401 qdtext = OWS / %x21 / %x23-5B / %x5D-7E / obs-text 402 ; OWS / / obs-text 403 obs-text = %x80-FF 405 The backslash character ("\") can be used as a single-character 406 quoting mechanism within quoted-string constructs: 408 quoted-pair = "\" ( WSP / VCHAR / obs-text ) 410 Producers SHOULD NOT escape characters that do not require escaping 411 (i.e., other than DQUOTE and the backslash character). 413 1.2.3. ABNF Rules defined in other Parts of the Specification 415 The ABNF rules below are defined in other parts: 417 request-header = 418 response-header = 420 MIME-Version = 422 Cache-Control = 423 Pragma = 424 Warning = 426 2. HTTP-related architecture 428 HTTP was created for the World Wide Web architecture and has evolved 429 over time to support the scalability needs of a worldwide hypertext 430 system. Much of that architecture is reflected in the terminology 431 and syntax productions used to define HTTP. 433 2.1. Client/Server Messaging 435 HTTP is a stateless request/response protocol that operates by 436 exchanging messages across a reliable transport or session-layer 437 connection. An HTTP "client" is a program that establishes a 438 connection to a server for the purpose of sending one or more HTTP 439 requests. An HTTP "server" is a program that accepts connections in 440 order to service HTTP requests by sending HTTP responses. 442 Note that the terms client and server refer only to the roles that 443 these programs perform for a particular connection. The same program 444 might act as a client on some connections and a server on others. We 445 use the term "user agent" to refer to the program that initiates a 446 request, such as a WWW browser, editor, or spider (web-traversing 447 robot), and the term "origin server" to refer to the program that can 448 originate authoritative responses to a request. For general 449 requirements, we use the term "sender" to refer to whichever 450 component sent a given message and the term "recipient" to refer to 451 any component that receives the message. 453 Most HTTP communication consists of a retrieval request (GET) for a 454 representation of some resource identified by a URI. In the simplest 455 case, this might be accomplished via a single bidirectional 456 connection (===) between the user agent (UA) and the origin server 457 (O). 459 request > 460 UA ======================================= O 461 < response 463 A client sends an HTTP request to the server in the form of a request 464 message (Section 4), beginning with a method, URI, and protocol 465 version, followed by MIME-like header fields containing request 466 modifiers, client information, and payload metadata, an empty line to 467 indicate the end of the header section, and finally the payload body 468 (if any). 470 A server responds to the client's request by sending an HTTP response 471 message (Section 5), beginning with a status line that includes the 472 protocol version, a success or error code, and textual reason phrase, 473 followed by MIME-like header fields containing server information, 474 resource metadata, and payload metadata, an empty line to indicate 475 the end of the header section, and finally the payload body (if any). 477 The following example illustrates a typical message exchange for a 478 GET request on the URI "http://www.example.com/hello.txt": 480 client request: 482 GET /hello.txt HTTP/1.1 483 User-Agent: curl/7.16.3 libcurl/7.16.3 OpenSSL/0.9.7l zlib/1.2.3 484 Host: www.example.com 485 Accept: */* 487 server response: 489 HTTP/1.1 200 OK 490 Date: Mon, 27 Jul 2009 12:28:53 GMT 491 Server: Apache 492 Last-Modified: Wed, 22 Jul 2009 19:15:56 GMT 493 ETag: "34aa387-d-1568eb00" 494 Accept-Ranges: bytes 495 Content-Length: 14 496 Vary: Accept-Encoding 497 Content-Type: text/plain 499 Hello World! 501 2.2. Intermediaries 503 A more complicated situation occurs when one or more intermediaries 504 are present in the request/response chain. There are three common 505 forms of intermediary: proxy, gateway, and tunnel. In some cases, a 506 single intermediary might act as an origin server, proxy, gateway, or 507 tunnel, switching behavior based on the nature of each request. 509 > > > > 510 UA =========== A =========== B =========== C =========== O 511 < < < < 513 The figure above shows three intermediaries (A, B, and C) between the 514 user agent and origin server. A request or response message that 515 travels the whole chain will pass through four separate connections. 516 Some HTTP communication options might apply only to the connection 517 with the nearest, non-tunnel neighbor, only to the end-points of the 518 chain, or to all connections along the chain. Although the diagram 519 is linear, each participant might be engaged in multiple, 520 simultaneous communications. For example, B might be receiving 521 requests from many clients other than A, and/or forwarding requests 522 to servers other than C, at the same time that it is handling A's 523 request. 525 We use the terms "upstream" and "downstream" to describe various 526 requirements in relation to the directional flow of a message: all 527 messages flow from upstream to downstream. Likewise, we use the 528 terms "inbound" and "outbound" to refer to directions in relation to 529 the request path: "inbound" means toward the origin server and 530 "outbound" means toward the user agent. 532 A "proxy" is a message forwarding agent that is selected by the 533 client, usually via local configuration rules, to receive requests 534 for some type(s) of absolute URI and attempt to satisfy those 535 requests via translation through the HTTP interface. Some 536 translations are minimal, such as for proxy requests for "http" URIs, 537 whereas other requests might require translation to and from entirely 538 different application-layer protocols. Proxies are often used to 539 group an organization's HTTP requests through a common intermediary 540 for the sake of security, annotation services, or shared caching. 542 A "gateway" (a.k.a., "reverse proxy") is a receiving agent that acts 543 as a layer above some other server(s) and translates the received 544 requests to the underlying server's protocol. Gateways are often 545 used for load balancing or partitioning HTTP services across multiple 546 machines. Unlike a proxy, a gateway receives requests as if it were 547 the origin server for the target resource; the requesting client will 548 not be aware that it is communicating with a gateway. A gateway 549 communicates with the client as if the gateway is the origin server 550 and thus is subject to all of the requirements on origin servers for 551 that connection. A gateway communicates with inbound servers using 552 any protocol it desires, including private extensions to HTTP that 553 are outside the scope of this specification. 555 A "tunnel" acts as a blind relay between two connections without 556 changing the messages. Once active, a tunnel is not considered a 557 party to the HTTP communication, though the tunnel might have been 558 initiated by an HTTP request. A tunnel ceases to exist when both 559 ends of the relayed connection are closed. Tunnels are used to 560 extend a virtual connection through an intermediary, such as when 561 transport-layer security is used to establish private communication 562 through a shared firewall proxy. 564 2.3. Caches 566 A "cache" is a local store of previous response messages and the 567 subsystem that controls its message storage, retrieval, and deletion. 568 A cache stores cacheable responses in order to reduce the response 569 time and network bandwidth consumption on future, equivalent 570 requests. Any client or server MAY employ a cache, though a cache 571 cannot be used by a server while it is acting as a tunnel. 573 The effect of a cache is that the request/response chain is shortened 574 if one of the participants along the chain has a cached response 575 applicable to that request. The following illustrates the resulting 576 chain if B has a cached copy of an earlier response from O (via C) 577 for a request which has not been cached by UA or A. 579 > > 580 UA =========== A =========== B - - - - - - C - - - - - - O 581 < < 583 A response is "cacheable" if a cache is allowed to store a copy of 584 the response message for use in answering subsequent requests. Even 585 when a response is cacheable, there might be additional constraints 586 placed by the client or by the origin server on when that cached 587 response can be used for a particular request. HTTP requirements for 588 cache behavior and cacheable responses are defined in Section 2 of 589 [Part6]. 591 There are a wide variety of architectures and configurations of 592 caches and proxies deployed across the World Wide Web and inside 593 large organizations. These systems include national hierarchies of 594 proxy caches to save transoceanic bandwidth, systems that broadcast 595 or multicast cache entries, organizations that distribute subsets of 596 cached data via optical media, and so on. 598 2.4. Transport Independence 600 HTTP systems are used in a wide variety of environments, from 601 corporate intranets with high-bandwidth links to long-distance 602 communication over low-power radio links and intermittent 603 connectivity. 605 HTTP communication usually takes place over TCP/IP connections. The 606 default port is TCP 80 607 (), but other ports can 608 be used. This does not preclude HTTP from being implemented on top 609 of any other protocol on the Internet, or on other networks. HTTP 610 only presumes a reliable transport; any protocol that provides such 611 guarantees can be used; the mapping of the HTTP/1.1 request and 612 response structures onto the transport data units of the protocol in 613 question is outside the scope of this specification. 615 In HTTP/1.0, most implementations used a new connection for each 616 request/response exchange. In HTTP/1.1, a connection might be used 617 for one or more request/response exchanges, although connections 618 might be closed for a variety of reasons (see Section 7.1). 620 2.5. HTTP Version 622 HTTP uses a "." numbering scheme to indicate versions 623 of the protocol. The protocol versioning policy is intended to allow 624 the sender to indicate the format of a message and its capacity for 625 understanding further HTTP communication, rather than the features 626 obtained via that communication. No change is made to the version 627 number for the addition of message components which do not affect 628 communication behavior or which only add to extensible field values. 629 The number is incremented when the changes made to the 630 protocol add features which do not change the general message parsing 631 algorithm, but which might add to the message semantics and imply 632 additional capabilities of the sender. The number is 633 incremented when the format of a message within the protocol is 634 changed. See [RFC2145] for a fuller explanation. 636 The version of an HTTP message is indicated by an HTTP-Version field 637 in the first line of the message. HTTP-Version is case-sensitive. 639 HTTP-Version = HTTP-Prot-Name "/" 1*DIGIT "." 1*DIGIT 640 HTTP-Prot-Name = %x48.54.54.50 ; "HTTP", case-sensitive 642 Note that the major and minor numbers MUST be treated as separate 643 integers and that each MAY be incremented higher than a single digit. 644 Thus, HTTP/2.4 is a lower version than HTTP/2.13, which in turn is 645 lower than HTTP/12.3. Leading zeros MUST be ignored by recipients 646 and MUST NOT be sent. 648 An application that sends a request or response message that includes 649 HTTP-Version of "HTTP/1.1" MUST be at least conditionally compliant 650 with this specification. Applications that are at least 651 conditionally compliant with this specification SHOULD use an HTTP- 652 Version of "HTTP/1.1" in their messages, and MUST do so for any 653 message that is not compatible with HTTP/1.0. For more details on 654 when to send specific HTTP-Version values, see [RFC2145]. 656 The HTTP version of an application is the highest HTTP version for 657 which the application is at least conditionally compliant. 659 Proxy and gateway applications need to be careful when forwarding 660 messages in protocol versions different from that of the application. 661 Since the protocol version indicates the protocol capability of the 662 sender, a proxy/gateway MUST NOT send a message with a version 663 indicator which is greater than its actual version. If a higher 664 version request is received, the proxy/gateway MUST either downgrade 665 the request version, or respond with an error, or switch to tunnel 666 behavior. 668 Due to interoperability problems with HTTP/1.0 proxies discovered 669 since the publication of [RFC2068], caching proxies MUST, gateways 670 MAY, and tunnels MUST NOT upgrade the request to the highest version 671 they support. The proxy/gateway's response to that request MUST be 672 in the same major version as the request. 674 Note: Converting between versions of HTTP might involve 675 modification of header fields required or forbidden by the 676 versions involved. 678 2.6. Uniform Resource Identifiers 680 Uniform Resource Identifiers (URIs) [RFC3986] are used throughout 681 HTTP as the means for identifying resources. URI references are used 682 to target requests, indicate redirects, and define relationships. 683 HTTP does not limit what a resource might be; it merely defines an 684 interface that can be used to interact with a resource via HTTP. 685 More information on the scope of URIs and resources can be found in 686 [RFC3986]. 688 This specification adopts the definitions of "URI-reference", 689 "absolute-URI", "relative-part", "port", "host", "path-abempty", 690 "path-absolute", "query", and "authority" from [RFC3986]. In 691 addition, we define a partial-URI rule for protocol elements that 692 allow a relative URI without a fragment. 694 URI-reference = 695 absolute-URI = 696 relative-part = 697 authority = 698 path-abempty = 699 path-absolute = 700 port = 701 query = 702 uri-host = 704 partial-URI = relative-part [ "?" query ] 706 Each protocol element in HTTP that allows a URI reference will 707 indicate in its ABNF production whether the element allows only a URI 708 in absolute form (absolute-URI), any relative reference (relative- 709 ref), or some other subset of the URI-reference grammar. Unless 710 otherwise indicated, URI references are parsed relative to the 711 request target (the default base URI for both the request and its 712 corresponding response). 714 2.6.1. http URI scheme 716 The "http" URI scheme is hereby defined for the purpose of minting 717 identifiers according to their association with the hierarchical 718 namespace governed by a potential HTTP origin server listening for 719 TCP connections on a given port. The HTTP server is identified via 720 the generic syntax's authority component, which includes a host 721 identifier and optional TCP port, and the remainder of the URI is 722 considered to be identifying data corresponding to a resource for 723 which that server might provide an HTTP interface. 725 http-URI = "http:" "//" authority path-abempty [ "?" query ] 727 The host identifier within an authority component is defined in 728 [RFC3986], Section 3.2.2. If host is provided as an IP literal or 729 IPv4 address, then the HTTP server is any listener on the indicated 730 TCP port at that IP address. If host is a registered name, then that 731 name is considered an indirect identifier and the recipient might use 732 a name resolution service, such as DNS, to find the address of a 733 listener for that host. The host MUST NOT be empty; if an "http" URI 734 is received with an empty host, then it MUST be rejected as invalid. 735 If the port subcomponent is empty or not given, then TCP port 80 is 736 assumed (the default reserved port for WWW services). 738 Regardless of the form of host identifier, access to that host is not 739 implied by the mere presence of its name or address. The host might 740 or might not exist and, even when it does exist, might or might not 741 be running an HTTP server or listening to the indicated port. The 742 "http" URI scheme makes use of the delegated nature of Internet names 743 and addresses to establish a naming authority (whatever entity has 744 the ability to place an HTTP server at that Internet name or address) 745 and allows that authority to determine which names are valid and how 746 they might be used. 748 When an "http" URI is used within a context that calls for access to 749 the indicated resource, a client MAY attempt access by resolving the 750 host to an IP address, establishing a TCP connection to that address 751 on the indicated port, and sending an HTTP request message to the 752 server containing the URI's identifying data as described in 753 Section 4. If the server responds to that request with a non-interim 754 HTTP response message, as described in Section 5, then that response 755 is considered an authoritative answer to the client's request. 757 Although HTTP is independent of the transport protocol, the "http" 758 scheme is specific to TCP-based services because the name delegation 759 process depends on TCP for establishing authority. An HTTP service 760 based on some other underlying connection protocol would presumably 761 be identified using a different URI scheme, just as the "https" 762 scheme (below) is used for servers that require an SSL/TLS transport 763 layer on a connection. Other protocols might also be used to provide 764 access to "http" identified resources --- it is only the 765 authoritative interface used for mapping the namespace that is 766 specific to TCP. 768 The URI generic syntax for authority also includes a deprecated 769 userinfo subcomponent ([RFC3986], Section 3.2.1) for including user 770 authentication information in the URI. The userinfo subcomponent 771 (and its "@" delimiter) MUST NOT be used in an "http" URI. URI 772 reference recipients SHOULD parse for the existence of userinfo and 773 treat its presence as an error, likely indicating that the deprecated 774 subcomponent is being used to obscure the authority for the sake of 775 phishing attacks. 777 2.6.2. https URI scheme 779 The "https" URI scheme is hereby defined for the purpose of minting 780 identifiers according to their association with the hierarchical 781 namespace governed by a potential HTTP origin server listening for 782 SSL/TLS-secured connections on a given TCP port. 784 All of the requirements listed above for the "http" scheme are also 785 requirements for the "https" scheme, except that a default TCP port 786 of 443 is assumed if the port subcomponent is empty or not given, and 787 the TCP connection MUST be secured for privacy through the use of 788 strong encryption prior to sending the first HTTP request. 790 https-URI = "https:" "//" authority path-abempty [ "?" query ] 792 Unlike the "http" scheme, responses to "https" identified requests 793 are never "public" and thus are ineligible for shared caching. Their 794 default is "private" and might be further constrained via use of the 795 Cache-Control header field. 797 Resources made available via the "https" scheme have no shared 798 identity with the "http" scheme even if their resource identifiers 799 only differ by the single "s" in the scheme name. They are different 800 services governed by different authorities. However, some extensions 801 to HTTP that apply to entire host domains, such as the Cookie 802 protocol, do allow one service to effect communication with the other 803 services based on host domain matching. 805 The process for authoritative access to an "https" identified 806 resource is defined in [RFC2818]. 808 2.6.3. http and https URI Normalization and Comparison 810 Since the "http" and "https" schemes conform to the URI generic 811 syntax, such URIs are normalized and compared according to the 812 algorithm defined in [RFC3986], Section 6, using the defaults 813 described above for each scheme. 815 If the port is equal to the default port for a scheme, the normal 816 form is to elide the port subcomponent. Likewise, an empty path 817 component is equivalent to an absolute path of "/", so the normal 818 form is to provide a path of "/" instead. The scheme and host are 819 case-insensitive and normally provided in lowercase; all other 820 components are compared in a case-sensitive manner. Characters other 821 than those in the "reserved" set are equivalent to their percent- 822 encoded octets (see [RFC3986], Section 2.1): the normal form is to 823 not encode them. 825 For example, the following three URIs are equivalent: 827 http://example.com:80/~smith/home.html 828 http://EXAMPLE.com/%7Esmith/home.html 829 http://EXAMPLE.com:/%7esmith/home.html 831 [[TODO-not-here: This paragraph does not belong here. --roy]] If 832 path-abempty is the empty string (i.e., there is no slash "/" path 833 separator following the authority), then the "http" URI MUST be given 834 as "/" when used as a request-target (Section 4.1.2). If a proxy 835 receives a host name which is not a fully qualified domain name, it 836 MAY add its domain to the host name it received. If a proxy receives 837 a fully qualified domain name, the proxy MUST NOT change the host 838 name. 840 3. HTTP Message 842 All HTTP/1.1 messages consist of a start-line followed by a sequence 843 of characters in a format similar to the Internet Message Format 844 [RFC5322]: zero or more header fields (collectively referred to as 845 the "headers" or the "header section"), an empty line indicating the 846 end of the header section, and an optional message-body. 848 An HTTP message can either be a request from client to server or a 849 response from server to client. Syntactically, the two types of 850 message differ only in the start-line, which is either a Request-Line 851 (for requests) or a Status-Line (for responses), and in the algorithm 852 for determining the length of the message-body (Section 3.3). In 853 theory, a client could receive requests and a server could receive 854 responses, distinguishing them by their different start-line formats, 855 but in practice servers are implemented to only expect a request (a 856 response is interpreted as an unknown or invalid request method) and 857 clients are implemented to only expect a response. 859 HTTP-message = start-line 860 *( header-field CRLF ) 861 CRLF 862 [ message-body ] 863 start-line = Request-Line / Status-Line 865 Whitespace (WSP) MUST NOT be sent between the start-line and the 866 first header field. The presence of whitespace might be an attempt 867 to trick a noncompliant implementation of HTTP into ignoring that 868 field or processing the next line as a new request, either of which 869 might result in security issues when implementations within the 870 request chain interpret the same message differently. HTTP/1.1 871 servers MUST reject such a message with a 400 (Bad Request) response. 873 3.1. Message Parsing Robustness 875 In the interest of robustness, servers SHOULD ignore at least one 876 empty line received where a Request-Line is expected. In other 877 words, if the server is reading the protocol stream at the beginning 878 of a message and receives a CRLF first, it SHOULD ignore the CRLF. 880 Some old HTTP/1.0 client implementations generate an extra CRLF after 881 a POST request as a lame workaround for some early server 882 applications that failed to read message-body content that was not 883 terminated by a line-ending. An HTTP/1.1 client MUST NOT preface or 884 follow a request with an extra CRLF. If terminating the request 885 message-body with a line-ending is desired, then the client MUST 886 include the terminating CRLF octets as part of the message-body 887 length. 889 The normal procedure for parsing an HTTP message is to read the 890 start-line into a structure, read each header field into a hash table 891 by field name until the empty line, and then use the parsed data to 892 determine if a message-body is expected. If a message-body has been 893 indicated, then it is read as a stream until an amount of octets 894 equal to the message-body length is read or the connection is closed. 895 Care must be taken to parse an HTTP message as a sequence of octets 896 in an encoding that is a superset of US-ASCII. Attempting to parse 897 HTTP as a stream of Unicode characters in a character encoding like 898 UTF-16 might introduce security flaws due to the differing ways that 899 such parsers interpret invalid characters. 901 HTTP allows the set of defined header fields to be extended without 902 changing the protocol version (see Section 10.1). However, such 903 fields might not be recognized by a downstream recipient and might be 904 stripped by non-transparent intermediaries. Unrecognized header 905 fields MUST be forwarded by transparent proxies and SHOULD be ignored 906 by a recipient. 908 3.2. Header Fields 910 Each HTTP header field consists of a case-insensitive field name 911 followed by a colon (":"), optional whitespace, and the field value. 913 header-field = field-name ":" OWS [ field-value ] OWS 914 field-name = token 915 field-value = *( field-content / OWS ) 916 field-content = *( WSP / VCHAR / obs-text ) 918 No whitespace is allowed between the header field name and colon. 920 For security reasons, any request message received containing such 921 whitespace MUST be rejected with a response code of 400 (Bad 922 Request). A proxy MUST remove any such whitespace from a response 923 message before forwarding the message downstream. 925 A field value MAY be preceded by optional whitespace (OWS); a single 926 SP is preferred. The field value does not include any leading or 927 trailing white space: OWS occurring before the first non-whitespace 928 character of the field value or after the last non-whitespace 929 character of the field value is ignored and SHOULD be removed before 930 further processing (as this does not change the meaning of the header 931 field). 933 The order in which header fields with differing field names are 934 received is not significant. However, it is "good practice" to send 935 header fields that contain control data first, such as Host on 936 requests and Date on responses, so that implementations can decide 937 when not to handle a message as early as possible. A server MUST 938 wait until the entire header section is received before interpreting 939 a request message, since later header fields might include 940 conditionals, authentication credentials, or deliberately misleading 941 duplicate header fields that would impact request processing. 943 Multiple header fields with the same field name MUST NOT be sent in a 944 message unless the entire field value for that header field is 945 defined as a comma-separated list [i.e., #(values)]. Multiple header 946 fields with the same field name can be combined into one "field-name: 947 field-value" pair, without changing the semantics of the message, by 948 appending each subsequent field value to the combined field value in 949 order, separated by a comma. The order in which header fields with 950 the same field name are received is therefore significant to the 951 interpretation of the combined field value; a proxy MUST NOT change 952 the order of these field values when forwarding a message. 954 Note: The "Set-Cookie" header field as implemented in practice (as 955 opposed to how it is specified in [RFC2109]) can occur multiple 956 times, but does not use the list syntax, and thus cannot be 957 combined into a single line. (See Appendix A.2.3 of [Kri2001] for 958 details.) Also note that the Set-Cookie2 header field specified 959 in [RFC2965] does not share this problem. 961 Historically, HTTP header field values could be extended over 962 multiple lines by preceding each extra line with at least one space 963 or horizontal tab character (line folding). This specification 964 deprecates such line folding except within the message/http media 965 type (Section 10.3.1). HTTP/1.1 senders MUST NOT produce messages 966 that include line folding (i.e., that contain any field-content that 967 matches the obs-fold rule) unless the message is intended for 968 packaging within the message/http media type. HTTP/1.1 recipients 969 SHOULD accept line folding and replace any embedded obs-fold 970 whitespace with a single SP prior to interpreting the field value or 971 forwarding the message downstream. 973 Historically, HTTP has allowed field content with text in the ISO- 974 8859-1 [ISO-8859-1] character encoding and supported other character 975 sets only through use of [RFC2047] encoding. In practice, most HTTP 976 header field values use only a subset of the US-ASCII character 977 encoding [USASCII]. Newly defined header fields SHOULD limit their 978 field values to US-ASCII characters. Recipients SHOULD treat other 979 (obs-text) octets in field content as opaque data. 981 Comments can be included in some HTTP header fields by surrounding 982 the comment text with parentheses. Comments are only allowed in 983 fields containing "comment" as part of their field value definition. 985 comment = "(" *( ctext / quoted-cpair / comment ) ")" 986 ctext = OWS / %x21-27 / %x2A-5B / %x5D-7E / obs-text 987 ; OWS / / obs-text 989 The backslash character ("\") can be used as a single-character 990 quoting mechanism within comment constructs: 992 quoted-cpair = "\" ( WSP / VCHAR / obs-text ) 994 Producers SHOULD NOT escape characters that do not require escaping 995 (i.e., other than the backslash character "\" and the parentheses "(" 996 and ")"). 998 3.3. Message Body 1000 The message-body (if any) of an HTTP message is used to carry the 1001 payload body associated with the request or response. 1003 message-body = *OCTET 1005 The message-body differs from the payload body only when a transfer- 1006 coding has been applied, as indicated by the Transfer-Encoding header 1007 field (Section 9.7). When one or more transfer-codings are applied 1008 to a payload in order to form the message-body, the Transfer-Encoding 1009 header field MUST contain the list of transfer-codings applied. 1010 Transfer-Encoding is a property of the message, not of the payload, 1011 and thus MAY be added or removed by any implementation along the 1012 request/response chain under the constraints found in Section 6.2. 1014 The rules for when a message-body is allowed in a message differ for 1015 requests and responses. 1017 The presence of a message-body in a request is signaled by the 1018 inclusion of a Content-Length or Transfer-Encoding header field in 1019 the request's header fields, even if the request method does not 1020 define any use for a message-body. This allows the request message 1021 framing algorithm to be independent of method semantics. 1023 For response messages, whether or not a message-body is included with 1024 a message is dependent on both the request method and the response 1025 status code (Section 5.1.1). Responses to the HEAD request method 1026 never include a message-body because the associated response header 1027 fields (e.g., Transfer-Encoding, Content-Length, etc.) only indicate 1028 what their values would have been if the method had been GET. All 1029 1xx (Informational), 204 (No Content), and 304 (Not Modified) 1030 responses MUST NOT include a message-body. All other responses do 1031 include a message-body, although the body MAY be of zero length. 1033 The length of the message-body is determined by one of the following 1034 (in order of precedence): 1036 1. Any response to a HEAD request and any response with a status 1037 code of 100-199, 204, or 304 is always terminated by the first 1038 empty line after the header fields, regardless of the header 1039 fields present in the message, and thus cannot contain a message- 1040 body. 1042 2. If a Transfer-Encoding header field (Section 9.7) is present and 1043 the "chunked" transfer-coding (Section 6.2) is the final 1044 encoding, the message-body length is determined by reading and 1045 decoding the chunked data until the transfer-coding indicates the 1046 data is complete. 1048 If a Transfer-Encoding header field is present in a response and 1049 the "chunked" transfer-coding is not the final encoding, the 1050 message-body length is determined by reading the connection until 1051 it is closed by the server. If a Transfer-Encoding header field 1052 is present in a request and the "chunked" transfer-coding is not 1053 the final encoding, the message-body length cannot be determined 1054 reliably; the server MUST respond with the 400 (Bad Request) 1055 status code and then close the connection. 1057 If a message is received with both a Transfer-Encoding header 1058 field and a Content-Length header field, the Transfer-Encoding 1059 overrides the Content-Length. Such a message might indicate an 1060 attempt to perform request or response smuggling (bypass of 1061 security-related checks on message routing or content) and thus 1062 ought to be handled as an error. The provided Content-Length 1063 MUST be removed, prior to forwarding the message downstream, or 1064 replaced with the real message-body length after the transfer- 1065 coding is decoded. 1067 3. If a message is received without Transfer-Encoding and with 1068 either multiple Content-Length header fields or a single Content- 1069 Length header field with an invalid value, then the message 1070 framing is invalid and MUST be treated as an error to prevent 1071 request or response smuggling. If this is a request message, the 1072 server MUST respond with a 400 (Bad Request) status code and then 1073 close the connection. If this is a response message received by 1074 a proxy or gateway, the proxy or gateway MUST discard the 1075 received response, send a 502 (Bad Gateway) status code as its 1076 downstream response, and then close the connection. If this is a 1077 response message received by a user-agent, it SHOULD be treated 1078 as an error by discarding the message and closing the connection. 1080 4. If a valid Content-Length header field (Section 9.2) is present 1081 without Transfer-Encoding, its decimal value defines the message- 1082 body length in octets. If the actual number of octets sent in 1083 the message is less than the indicated Content-Length, the 1084 recipient MUST consider the message to be incomplete and treat 1085 the connection as no longer usable. If the actual number of 1086 octets sent in the message is more than the indicated Content- 1087 Length, the recipient MUST only process the message-body up to 1088 the field value's number of octets; the remainder of the message 1089 MUST either be discarded or treated as the next message in a 1090 pipeline. For the sake of robustness, a user-agent MAY attempt 1091 to detect and correct such an error in message framing if it is 1092 parsing the response to the last request on on a connection and 1093 the connection has been closed by the server. 1095 5. If this is a request message and none of the above are true, then 1096 the message-body length is zero (no message-body is present). 1098 6. Otherwise, this is a response message without a declared message- 1099 body length, so the message-body length is determined by the 1100 number of octets received prior to the server closing the 1101 connection. 1103 Since there is no way to distinguish a successfully completed, close- 1104 delimited message from a partially-received message interrupted by 1105 network failure, implementations SHOULD use encoding or length- 1106 delimited messages whenever possible. The close-delimiting feature 1107 exists primarily for backwards compatibility with HTTP/1.0. 1109 A server MAY reject a request that contains a message-body but not a 1110 Content-Length by responding with 411 (Length Required). 1112 Unless a transfer-coding other than "chunked" has been applied, a 1113 client that sends a request containing a message-body SHOULD use a 1114 valid Content-Length header field if the message-body length is known 1115 in advance, rather than the "chunked" encoding, since some existing 1116 services respond to "chunked" with a 411 (Length Required) status 1117 code even though they understand the chunked encoding. This is 1118 typically because such services are implemented via a gateway that 1119 requires a content-length in advance of being called and the server 1120 is unable or unwilling to buffer the entire request before 1121 processing. 1123 A client that sends a request containing a message-body MUST include 1124 a valid Content-Length header field if it does not know the server 1125 will handle HTTP/1.1 (or later) requests; such knowledge can be in 1126 the form of specific user configuration or by remembering the version 1127 of a prior received response. 1129 Request messages that are prematurely terminated, possibly due to a 1130 cancelled connection or a server-imposed time-out exception, MUST 1131 result in closure of the connection; sending an HTTP/1.1 error 1132 response prior to closing the connection is OPTIONAL. Response 1133 messages that are prematurely terminated, usually by closure of the 1134 connection prior to receiving the expected number of octets or by 1135 failure to decode a transfer-encoded message-body, MUST be recorded 1136 as incomplete. A user agent MUST NOT render an incomplete response 1137 message-body as if it were complete (i.e., some indication must be 1138 given to the user that an error occurred). Cache requirements for 1139 incomplete responses are defined in Section 2.1.1 of [Part6]. 1141 A server MUST read the entire request message-body or close the 1142 connection after sending its response, since otherwise the remaining 1143 data on a persistent connection would be misinterpreted as the next 1144 request. Likewise, a client MUST read the entire response message- 1145 body if it intends to reuse the same connection for a subsequent 1146 request. Pipelining multiple requests on a connection is described 1147 in Section 7.1.2.2. 1149 3.4. General Header Fields 1151 There are a few header fields which have general applicability for 1152 both request and response messages, but which do not apply to the 1153 payload being transferred. These header fields apply only to the 1154 message being transmitted. 1156 general-header = Cache-Control ; [Part6], Section 3.2 1157 / Connection ; Section 9.1 1158 / Date ; Section 9.3 1159 / Pragma ; [Part6], Section 3.4 1160 / Trailer ; Section 9.6 1161 / Transfer-Encoding ; Section 9.7 1162 / Upgrade ; Section 9.8 1163 / Via ; Section 9.9 1164 / Warning ; [Part6], Section 3.6 1165 / MIME-Version ; [Part3], Appendix A.1 1167 General-header field names can be extended reliably only in 1168 combination with a change in the protocol version. However, new or 1169 experimental header fields might be given the semantics of general 1170 header fields if all parties in the communication recognize them to 1171 be general-header fields. 1173 4. Request 1175 A request message from a client to a server includes, within the 1176 first line of that message, the method to be applied to the resource, 1177 the identifier of the resource, and the protocol version in use. 1179 Request = Request-Line ; Section 4.1 1180 *( header-field CRLF ) ; Section 3.2 1181 CRLF 1182 [ message-body ] ; Section 3.3 1184 4.1. Request-Line 1186 The Request-Line begins with a method token, followed by the request- 1187 target and the protocol version, and ending with CRLF. The elements 1188 are separated by SP characters. No CR or LF is allowed except in the 1189 final CRLF sequence. 1191 Request-Line = Method SP request-target SP HTTP-Version CRLF 1193 4.1.1. Method 1195 The Method token indicates the method to be performed on the resource 1196 identified by the request-target. The method is case-sensitive. 1198 Method = token 1200 4.1.2. request-target 1202 The request-target identifies the resource upon which to apply the 1203 request. 1205 request-target = "*" 1206 / absolute-URI 1207 / ( path-absolute [ "?" query ] ) 1208 / authority 1210 The four options for request-target are dependent on the nature of 1211 the request. 1213 The asterisk "*" ("asterisk form") means that the request does not 1214 apply to a particular resource, but to the server itself, and is only 1215 allowed when the method used does not necessarily apply to a 1216 resource. One example would be 1218 OPTIONS * HTTP/1.1 1220 The absolute-URI form is REQUIRED when the request is being made to a 1221 proxy. The proxy is requested to forward the request or service it 1222 from a valid cache, and return the response. Note that the proxy MAY 1223 forward the request on to another proxy or directly to the server 1224 specified by the absolute-URI. In order to avoid request loops, a 1225 proxy MUST be able to recognize all of its server names, including 1226 any aliases, local variations, and the numeric IP address. An 1227 example Request-Line would be: 1229 GET http://www.example.org/pub/WWW/TheProject.html HTTP/1.1 1231 To allow for transition to absolute-URIs in all requests in future 1232 versions of HTTP, all HTTP/1.1 servers MUST accept the absolute-URI 1233 form in requests, even though HTTP/1.1 clients will only generate 1234 them in requests to proxies. 1236 The authority form is only used by the CONNECT method (Section 7.9 of 1237 [Part2]). 1239 The most common form of request-target is that used to identify a 1240 resource on an origin server or gateway ("path-absolute form"). In 1241 this case the absolute path of the URI MUST be transmitted (see 1242 Section 2.6.1, path-absolute) as the request-target, and the network 1243 location of the URI (authority) MUST be transmitted in a Host header 1244 field. For example, a client wishing to retrieve the resource above 1245 directly from the origin server would create a TCP connection to port 1246 80 of the host "www.example.org" and send the lines: 1248 GET /pub/WWW/TheProject.html HTTP/1.1 1249 Host: www.example.org 1251 followed by the remainder of the Request. Note that the absolute 1252 path cannot be empty; if none is present in the original URI, it MUST 1253 be given as "/" (the server root). 1255 If a proxy receives a request without any path in the request-target 1256 and the method specified is capable of supporting the asterisk form 1257 of request-target, then the last proxy on the request chain MUST 1258 forward the request with "*" as the final request-target. 1260 For example, the request 1262 OPTIONS http://www.example.org:8001 HTTP/1.1 1264 would be forwarded by the proxy as 1266 OPTIONS * HTTP/1.1 1267 Host: www.example.org:8001 1269 after connecting to port 8001 of host "www.example.org". 1271 The request-target is transmitted in the format specified in 1272 Section 2.6.1. If the request-target is percent-encoded ([RFC3986], 1273 Section 2.1), the origin server MUST decode the request-target in 1274 order to properly interpret the request. Servers SHOULD respond to 1275 invalid request-targets with an appropriate status code. 1277 A transparent proxy MUST NOT rewrite the "path-absolute" part of the 1278 received request-target when forwarding it to the next inbound 1279 server, except as noted above to replace a null path-absolute with 1280 "/" or "*". 1282 Note: The "no rewrite" rule prevents the proxy from changing the 1283 meaning of the request when the origin server is improperly using 1284 a non-reserved URI character for a reserved purpose. Implementors 1285 need to be aware that some pre-HTTP/1.1 proxies have been known to 1286 rewrite the request-target. 1288 HTTP does not place a pre-defined limit on the length of a request- 1289 target. A server MUST be prepared to receive URIs of unbounded 1290 length and respond with the 414 (URI Too Long) status code if the 1291 received request-target would be longer than the server wishes to 1292 handle (see Section 8.4.15 of [Part2]). 1294 Various ad-hoc limitations on request-target length are found in 1295 practice. It is RECOMMENDED that all HTTP senders and recipients 1296 support request-target lengths of 8000 or more octets. 1298 Note: Fragments ([RFC3986], Section 3.5) are not part of the 1299 request-target and thus will not be transmitted in an HTTP 1300 request. 1302 4.2. The Resource Identified by a Request 1304 The exact resource identified by an Internet request is determined by 1305 examining both the request-target and the Host header field. 1307 An origin server that does not allow resources to differ by the 1308 requested host MAY ignore the Host header field value when 1309 determining the resource identified by an HTTP/1.1 request. (But see 1310 Appendix B.1.1 for other requirements on Host support in HTTP/1.1.) 1312 An origin server that does differentiate resources based on the host 1313 requested (sometimes referred to as virtual hosts or vanity host 1314 names) MUST use the following rules for determining the requested 1315 resource on an HTTP/1.1 request: 1317 1. If request-target is an absolute-URI, the host is part of the 1318 request-target. Any Host header field value in the request MUST 1319 be ignored. 1321 2. If the request-target is not an absolute-URI, and the request 1322 includes a Host header field, the host is determined by the Host 1323 header field value. 1325 3. If the host as determined by rule 1 or 2 is not a valid host on 1326 the server, the response MUST be a 400 (Bad Request) error 1327 message. 1329 Recipients of an HTTP/1.0 request that lacks a Host header field MAY 1330 attempt to use heuristics (e.g., examination of the URI path for 1331 something unique to a particular host) in order to determine what 1332 exact resource is being requested. 1334 4.3. Effective Request URI 1336 HTTP requests often do not carry the absolute URI ([RFC3986], Section 1337 4.3) for the target resource; instead, the URI needs to be inferred 1338 from the request-target, Host header field, and connection context. 1339 The result of this process is called the "effective request URI". 1340 The "target resource" is the resource identified by the effective 1341 request URI. 1343 If the request-target is an absolute-URI, then the effective request 1344 URI is the request-target. 1346 If the request-target uses the path-absolute form or the asterisk 1347 form, and the Host header field is present, then the effective 1348 request URI is constructed by concatenating 1350 o the scheme name: "http" if the request was received over an 1351 insecure TCP connection, or "https" when received over a SSL/ 1352 TLS-secured TCP connection, 1354 o the character sequence "://", 1356 o the authority component, as specified in the Host header field 1357 (Section 9.4), and 1359 o the request-target obtained from the Request-Line, unless the 1360 request-target is just the asterisk "*". 1362 If the request-target uses the path-absolute form or the asterisk 1363 form, and the Host header field is not present, then the effective 1364 request URI is undefined. 1366 Otherwise, when request-target uses the authority form, the effective 1367 request URI is undefined. 1369 Example 1: the effective request URI for the message 1371 GET /pub/WWW/TheProject.html HTTP/1.1 1372 Host: www.example.org:8080 1374 (received over an insecure TCP connection) is "http", plus "://", 1375 plus the authority component "www.example.org:8080", plus the 1376 request-target "/pub/WWW/TheProject.html", thus 1377 "http://www.example.org:8080/pub/WWW/TheProject.html". 1379 Example 2: the effective request URI for the message 1381 GET * HTTP/1.1 1382 Host: www.example.org 1384 (received over an SSL/TLS secured TCP connection) is "https", plus 1385 "://", plus the authority component "www.example.org", thus 1386 "https://www.example.org". 1388 Effective request URIs are compared using the rules described in 1389 Section 2.6.3, except that empty path components MUST NOT be treated 1390 as equivalent to an absolute path of "/". 1392 5. Response 1394 After receiving and interpreting a request message, a server responds 1395 with an HTTP response message. 1397 Response = Status-Line ; Section 5.1 1398 *( header-field CRLF ) ; Section 3.2 1399 CRLF 1400 [ message-body ] ; Section 3.3 1402 5.1. Status-Line 1404 The first line of a Response message is the Status-Line, consisting 1405 of the protocol version followed by a numeric status code and its 1406 associated textual phrase, with each element separated by SP 1407 characters. No CR or LF is allowed except in the final CRLF 1408 sequence. 1410 Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF 1412 5.1.1. Status Code and Reason Phrase 1414 The Status-Code element is a 3-digit integer result code of the 1415 attempt to understand and satisfy the request. These codes are fully 1416 defined in Section 8 of [Part2]. The Reason Phrase exists for the 1417 sole purpose of providing a textual description associated with the 1418 numeric status code, out of deference to earlier Internet application 1419 protocols that were more frequently used with interactive text 1420 clients. A client SHOULD ignore the content of the Reason Phrase. 1422 The first digit of the Status-Code defines the class of response. 1423 The last two digits do not have any categorization role. There are 5 1424 values for the first digit: 1426 o 1xx: Informational - Request received, continuing process 1428 o 2xx: Success - The action was successfully received, understood, 1429 and accepted 1431 o 3xx: Redirection - Further action must be taken in order to 1432 complete the request 1434 o 4xx: Client Error - The request contains bad syntax or cannot be 1435 fulfilled 1437 o 5xx: Server Error - The server failed to fulfill an apparently 1438 valid request 1440 Status-Code = 3DIGIT 1441 Reason-Phrase = *( WSP / VCHAR / obs-text ) 1443 6. Protocol Parameters 1445 6.1. Date/Time Formats: Full Date 1447 HTTP applications have historically allowed three different formats 1448 for date/time stamps. However, the preferred format is a fixed- 1449 length subset of that defined by [RFC1123]: 1451 Sun, 06 Nov 1994 08:49:37 GMT ; RFC 1123 1453 The other formats are described here only for compatibility with 1454 obsolete implementations. 1456 Sunday, 06-Nov-94 08:49:37 GMT ; obsolete RFC 850 format 1457 Sun Nov 6 08:49:37 1994 ; ANSI C's asctime() format 1459 HTTP/1.1 clients and servers that parse a date value MUST accept all 1460 three formats (for compatibility with HTTP/1.0), though they MUST 1461 only generate the RFC 1123 format for representing HTTP-date values 1462 in header fields. See Appendix A for further information. 1464 All HTTP date/time stamps MUST be represented in Greenwich Mean Time 1465 (GMT), without exception. For the purposes of HTTP, GMT is exactly 1466 equal to UTC (Coordinated Universal Time). This is indicated in the 1467 first two formats by the inclusion of "GMT" as the three-letter 1468 abbreviation for time zone, and MUST be assumed when reading the 1469 asctime format. HTTP-date is case sensitive and MUST NOT include 1470 additional whitespace beyond that specifically included as SP in the 1471 grammar. 1473 HTTP-date = rfc1123-date / obs-date 1475 Preferred format: 1477 rfc1123-date = day-name "," SP date1 SP time-of-day SP GMT 1478 ; fixed length subset of the format defined in 1479 ; Section 5.2.14 of [RFC1123] 1481 day-name = %x4D.6F.6E ; "Mon", case-sensitive 1482 / %x54.75.65 ; "Tue", case-sensitive 1483 / %x57.65.64 ; "Wed", case-sensitive 1484 / %x54.68.75 ; "Thu", case-sensitive 1485 / %x46.72.69 ; "Fri", case-sensitive 1486 / %x53.61.74 ; "Sat", case-sensitive 1487 / %x53.75.6E ; "Sun", case-sensitive 1489 date1 = day SP month SP year 1490 ; e.g., 02 Jun 1982 1492 day = 2DIGIT 1493 month = %x4A.61.6E ; "Jan", case-sensitive 1494 / %x46.65.62 ; "Feb", case-sensitive 1495 / %x4D.61.72 ; "Mar", case-sensitive 1496 / %x41.70.72 ; "Apr", case-sensitive 1497 / %x4D.61.79 ; "May", case-sensitive 1498 / %x4A.75.6E ; "Jun", case-sensitive 1499 / %x4A.75.6C ; "Jul", case-sensitive 1500 / %x41.75.67 ; "Aug", case-sensitive 1501 / %x53.65.70 ; "Sep", case-sensitive 1502 / %x4F.63.74 ; "Oct", case-sensitive 1503 / %x4E.6F.76 ; "Nov", case-sensitive 1504 / %x44.65.63 ; "Dec", case-sensitive 1505 year = 4DIGIT 1507 GMT = %x47.4D.54 ; "GMT", case-sensitive 1509 time-of-day = hour ":" minute ":" second 1510 ; 00:00:00 - 23:59:59 1512 hour = 2DIGIT 1513 minute = 2DIGIT 1514 second = 2DIGIT 1516 The semantics of day-name, day, month, year, and time-of-day are the 1517 same as those defined for the RFC 5322 constructs with the 1518 corresponding name ([RFC5322], Section 3.3). 1520 Obsolete formats: 1522 obs-date = rfc850-date / asctime-date 1523 rfc850-date = day-name-l "," SP date2 SP time-of-day SP GMT 1524 date2 = day "-" month "-" 2DIGIT 1525 ; day-month-year (e.g., 02-Jun-82) 1527 day-name-l = %x4D.6F.6E.64.61.79 ; "Monday", case-sensitive 1528 / %x54.75.65.73.64.61.79 ; "Tuesday", case-sensitive 1529 / %x57.65.64.6E.65.73.64.61.79 ; "Wednesday", case-sensitive 1530 / %x54.68.75.72.73.64.61.79 ; "Thursday", case-sensitive 1531 / %x46.72.69.64.61.79 ; "Friday", case-sensitive 1532 / %x53.61.74.75.72.64.61.79 ; "Saturday", case-sensitive 1533 / %x53.75.6E.64.61.79 ; "Sunday", case-sensitive 1535 asctime-date = day-name SP date3 SP time-of-day SP year 1536 date3 = month SP ( 2DIGIT / ( SP 1DIGIT )) 1537 ; month day (e.g., Jun 2) 1539 Note: Recipients of date values are encouraged to be robust in 1540 accepting date values that might have been sent by non-HTTP 1541 applications, as is sometimes the case when retrieving or posting 1542 messages via proxies/gateways to SMTP or NNTP. 1544 Note: HTTP requirements for the date/time stamp format apply only 1545 to their usage within the protocol stream. Clients and servers 1546 are not required to use these formats for user presentation, 1547 request logging, etc. 1549 6.2. Transfer Codings 1551 Transfer-coding values are used to indicate an encoding 1552 transformation that has been, can be, or might need to be applied to 1553 a payload body in order to ensure "safe transport" through the 1554 network. This differs from a content coding in that the transfer- 1555 coding is a property of the message rather than a property of the 1556 representation that is being transferred. 1558 transfer-coding = "chunked" ; Section 6.2.1 1559 / "compress" ; Section 6.2.2.1 1560 / "deflate" ; Section 6.2.2.2 1561 / "gzip" ; Section 6.2.2.3 1562 / transfer-extension 1563 transfer-extension = token *( OWS ";" OWS transfer-parameter ) 1565 Parameters are in the form of attribute/value pairs. 1567 transfer-parameter = attribute BWS "=" BWS value 1568 attribute = token 1569 value = word 1571 All transfer-coding values are case-insensitive. HTTP/1.1 uses 1572 transfer-coding values in the TE header field (Section 9.5) and in 1573 the Transfer-Encoding header field (Section 9.7). 1575 Transfer-codings are analogous to the Content-Transfer-Encoding 1576 values of MIME, which were designed to enable safe transport of 1577 binary data over a 7-bit transport service ([RFC2045], Section 6). 1578 However, safe transport has a different focus for an 8bit-clean 1579 transfer protocol. In HTTP, the only unsafe characteristic of 1580 message-bodies is the difficulty in determining the exact message 1581 body length (Section 3.3), or the desire to encrypt data over a 1582 shared transport. 1584 A server that receives a request message with a transfer-coding it 1585 does not understand SHOULD respond with 501 (Not Implemented) and 1586 then close the connection. A server MUST NOT send transfer-codings 1587 to an HTTP/1.0 client. 1589 6.2.1. Chunked Transfer Coding 1591 The chunked encoding modifies the body of a message in order to 1592 transfer it as a series of chunks, each with its own size indicator, 1593 followed by an OPTIONAL trailer containing header fields. This 1594 allows dynamically produced content to be transferred along with the 1595 information necessary for the recipient to verify that it has 1596 received the full message. 1598 Chunked-Body = *chunk 1599 last-chunk 1600 trailer-part 1601 CRLF 1603 chunk = chunk-size *WSP [ chunk-ext ] CRLF 1604 chunk-data CRLF 1605 chunk-size = 1*HEXDIG 1606 last-chunk = 1*("0") *WSP [ chunk-ext ] CRLF 1608 chunk-ext = *( ";" *WSP chunk-ext-name 1609 [ "=" chunk-ext-val ] *WSP ) 1610 chunk-ext-name = token 1611 chunk-ext-val = token / quoted-str-nf 1612 chunk-data = 1*OCTET ; a sequence of chunk-size octets 1613 trailer-part = *( header-field CRLF ) 1615 quoted-str-nf = DQUOTE *( qdtext-nf / quoted-pair ) DQUOTE 1616 ; like quoted-string, but disallowing line folding 1617 qdtext-nf = WSP / %x21 / %x23-5B / %x5D-7E / obs-text 1618 ; WSP / / obs-text 1620 The chunk-size field is a string of hex digits indicating the size of 1621 the chunk-data in octets. The chunked encoding is ended by any chunk 1622 whose size is zero, followed by the trailer, which is terminated by 1623 an empty line. 1625 The trailer allows the sender to include additional HTTP header 1626 fields at the end of the message. The Trailer header field can be 1627 used to indicate which header fields are included in a trailer (see 1628 Section 9.6). 1630 A server using chunked transfer-coding in a response MUST NOT use the 1631 trailer for any header fields unless at least one of the following is 1632 true: 1634 1. the request included a TE header field that indicates "trailers" 1635 is acceptable in the transfer-coding of the response, as 1636 described in Section 9.5; or, 1638 2. the trailer fields consist entirely of optional metadata, and the 1639 recipient could use the message (in a manner acceptable to the 1640 server where the field originated) without receiving it. In 1641 other words, the server that generated the header (often but not 1642 always the origin server) is willing to accept the possibility 1643 that the trailer fields might be silently discarded along the 1644 path to the client. 1646 This requirement prevents an interoperability failure when the 1647 message is being received by an HTTP/1.1 (or later) proxy and 1648 forwarded to an HTTP/1.0 recipient. It avoids a situation where 1649 compliance with the protocol would have necessitated a possibly 1650 infinite buffer on the proxy. 1652 A process for decoding the "chunked" transfer-coding can be 1653 represented in pseudo-code as: 1655 length := 0 1656 read chunk-size, chunk-ext (if any) and CRLF 1657 while (chunk-size > 0) { 1658 read chunk-data and CRLF 1659 append chunk-data to decoded-body 1660 length := length + chunk-size 1661 read chunk-size and CRLF 1662 } 1663 read header-field 1664 while (header-field not empty) { 1665 append header-field to existing header fields 1666 read header-field 1667 } 1668 Content-Length := length 1669 Remove "chunked" from Transfer-Encoding 1671 All HTTP/1.1 applications MUST be able to receive and decode the 1672 "chunked" transfer-coding and MUST ignore chunk-ext extensions they 1673 do not understand. 1675 Since "chunked" is the only transfer-coding required to be understood 1676 by HTTP/1.1 recipients, it plays a crucial role in delimiting 1677 messages on a persistent connection. Whenever a transfer-coding is 1678 applied to a payload body in a request, the final transfer-coding 1679 applied MUST be "chunked". If a transfer-coding is applied to a 1680 response payload body, then either the final transfer-coding applied 1681 MUST be "chunked" or the message MUST be terminated by closing the 1682 connection. When the "chunked" transfer-coding is used, it MUST be 1683 the last transfer-coding applied to form the message-body. The 1684 "chunked" transfer-coding MUST NOT be applied more than once in a 1685 message-body. 1687 6.2.2. Compression Codings 1689 The codings defined below can be used to compress the payload of a 1690 message. 1692 Note: Use of program names for the identification of encoding 1693 formats is not desirable and is discouraged for future encodings. 1694 Their use here is representative of historical practice, not good 1695 design. 1697 Note: For compatibility with previous implementations of HTTP, 1698 applications SHOULD consider "x-gzip" and "x-compress" to be 1699 equivalent to "gzip" and "compress" respectively. 1701 6.2.2.1. Compress Coding 1703 The "compress" format is produced by the common UNIX file compression 1704 program "compress". This format is an adaptive Lempel-Ziv-Welch 1705 coding (LZW). 1707 6.2.2.2. Deflate Coding 1709 The "deflate" format is defined as the "deflate" compression 1710 mechanism (described in [RFC1951]) used inside the "zlib" data format 1711 ([RFC1950]). 1713 Note: Some incorrect implementations send the "deflate" compressed 1714 data without the zlib wrapper. 1716 6.2.2.3. Gzip Coding 1718 The "gzip" format is produced by the file compression program "gzip" 1719 (GNU zip), as described in [RFC1952]. This format is a Lempel-Ziv 1720 coding (LZ77) with a 32 bit CRC. 1722 6.2.3. Transfer Coding Registry 1724 The HTTP Transfer Coding Registry defines the name space for the 1725 transfer coding names. 1727 Registrations MUST include the following fields: 1729 o Name 1731 o Description 1733 o Pointer to specification text 1735 Names of transfer codings MUST NOT overlap with names of content 1736 codings (Section 2.2 of [Part3]), unless the encoding transformation 1737 is identical (as it is the case for the compression codings defined 1738 in Section 6.2.2). 1740 Values to be added to this name space require a specification (see 1741 "Specification Required" in Section 4.1 of [RFC5226]), and MUST 1742 conform to the purpose of transfer coding defined in this section. 1744 The registry itself is maintained at 1745 . 1747 6.3. Product Tokens 1749 Product tokens are used to allow communicating applications to 1750 identify themselves by software name and version. Most fields using 1751 product tokens also allow sub-products which form a significant part 1752 of the application to be listed, separated by whitespace. By 1753 convention, the products are listed in order of their significance 1754 for identifying the application. 1756 product = token ["/" product-version] 1757 product-version = token 1759 Examples: 1761 User-Agent: CERN-LineMode/2.15 libwww/2.17b3 1762 Server: Apache/0.8.4 1764 Product tokens SHOULD be short and to the point. They MUST NOT be 1765 used for advertising or other non-essential information. Although 1766 any token character MAY appear in a product-version, this token 1767 SHOULD only be used for a version identifier (i.e., successive 1768 versions of the same product SHOULD only differ in the product- 1769 version portion of the product value). 1771 6.4. Quality Values 1773 Both transfer codings (TE request header field, Section 9.5) and 1774 content negotiation (Section 5 of [Part3]) use short "floating point" 1775 numbers to indicate the relative importance ("weight") of various 1776 negotiable parameters. A weight is normalized to a real number in 1777 the range 0 through 1, where 0 is the minimum and 1 the maximum 1778 value. If a parameter has a quality value of 0, then content with 1779 this parameter is "not acceptable" for the client. HTTP/1.1 1780 applications MUST NOT generate more than three digits after the 1781 decimal point. User configuration of these values SHOULD also be 1782 limited in this fashion. 1784 qvalue = ( "0" [ "." 0*3DIGIT ] ) 1785 / ( "1" [ "." 0*3("0") ] ) 1787 Note: "Quality values" is a misnomer, since these values merely 1788 represent relative degradation in desired quality. 1790 7. Connections 1791 7.1. Persistent Connections 1793 7.1.1. Purpose 1795 Prior to persistent connections, a separate TCP connection was 1796 established to fetch each URL, increasing the load on HTTP servers 1797 and causing congestion on the Internet. The use of inline images and 1798 other associated data often requires a client to make multiple 1799 requests of the same server in a short amount of time. Analysis of 1800 these performance problems and results from a prototype 1801 implementation are available [Pad1995] [Spe]. Implementation 1802 experience and measurements of actual HTTP/1.1 implementations show 1803 good results [Nie1997]. Alternatives have also been explored, for 1804 example, T/TCP [Tou1998]. 1806 Persistent HTTP connections have a number of advantages: 1808 o By opening and closing fewer TCP connections, CPU time is saved in 1809 routers and hosts (clients, servers, proxies, gateways, tunnels, 1810 or caches), and memory used for TCP protocol control blocks can be 1811 saved in hosts. 1813 o HTTP requests and responses can be pipelined on a connection. 1814 Pipelining allows a client to make multiple requests without 1815 waiting for each response, allowing a single TCP connection to be 1816 used much more efficiently, with much lower elapsed time. 1818 o Network congestion is reduced by reducing the number of packets 1819 caused by TCP opens, and by allowing TCP sufficient time to 1820 determine the congestion state of the network. 1822 o Latency on subsequent requests is reduced since there is no time 1823 spent in TCP's connection opening handshake. 1825 o HTTP can evolve more gracefully, since errors can be reported 1826 without the penalty of closing the TCP connection. Clients using 1827 future versions of HTTP might optimistically try a new feature, 1828 but if communicating with an older server, retry with old 1829 semantics after an error is reported. 1831 HTTP implementations SHOULD implement persistent connections. 1833 7.1.2. Overall Operation 1835 A significant difference between HTTP/1.1 and earlier versions of 1836 HTTP is that persistent connections are the default behavior of any 1837 HTTP connection. That is, unless otherwise indicated, the client 1838 SHOULD assume that the server will maintain a persistent connection, 1839 even after error responses from the server. 1841 Persistent connections provide a mechanism by which a client and a 1842 server can signal the close of a TCP connection. This signaling 1843 takes place using the Connection header field (Section 9.1). Once a 1844 close has been signaled, the client MUST NOT send any more requests 1845 on that connection. 1847 7.1.2.1. Negotiation 1849 An HTTP/1.1 server MAY assume that a HTTP/1.1 client intends to 1850 maintain a persistent connection unless a Connection header field 1851 including the connection-token "close" was sent in the request. If 1852 the server chooses to close the connection immediately after sending 1853 the response, it SHOULD send a Connection header field including the 1854 connection-token "close". 1856 An HTTP/1.1 client MAY expect a connection to remain open, but would 1857 decide to keep it open based on whether the response from a server 1858 contains a Connection header field with the connection-token close. 1859 In case the client does not want to maintain a connection for more 1860 than that request, it SHOULD send a Connection header field including 1861 the connection-token close. 1863 If either the client or the server sends the close token in the 1864 Connection header field, that request becomes the last one for the 1865 connection. 1867 Clients and servers SHOULD NOT assume that a persistent connection is 1868 maintained for HTTP versions less than 1.1 unless it is explicitly 1869 signaled. See Appendix B.2 for more information on backward 1870 compatibility with HTTP/1.0 clients. 1872 In order to remain persistent, all messages on the connection MUST 1873 have a self-defined message length (i.e., one not defined by closure 1874 of the connection), as described in Section 3.3. 1876 7.1.2.2. Pipelining 1878 A client that supports persistent connections MAY "pipeline" its 1879 requests (i.e., send multiple requests without waiting for each 1880 response). A server MUST send its responses to those requests in the 1881 same order that the requests were received. 1883 Clients which assume persistent connections and pipeline immediately 1884 after connection establishment SHOULD be prepared to retry their 1885 connection if the first pipelined attempt fails. If a client does 1886 such a retry, it MUST NOT pipeline before it knows the connection is 1887 persistent. Clients MUST also be prepared to resend their requests 1888 if the server closes the connection before sending all of the 1889 corresponding responses. 1891 Clients SHOULD NOT pipeline requests using non-idempotent methods or 1892 non-idempotent sequences of methods (see Section 7.1.2 of [Part2]). 1893 Otherwise, a premature termination of the transport connection could 1894 lead to indeterminate results. A client wishing to send a non- 1895 idempotent request SHOULD wait to send that request until it has 1896 received the response status line for the previous request. 1898 7.1.3. Proxy Servers 1900 It is especially important that proxies correctly implement the 1901 properties of the Connection header field as specified in 1902 Section 9.1. 1904 The proxy server MUST signal persistent connections separately with 1905 its clients and the origin servers (or other proxy servers) that it 1906 connects to. Each persistent connection applies to only one 1907 transport link. 1909 A proxy server MUST NOT establish a HTTP/1.1 persistent connection 1910 with an HTTP/1.0 client (but see Section 19.7.1 of [RFC2068] for 1911 information and discussion of the problems with the Keep-Alive header 1912 field implemented by many HTTP/1.0 clients). 1914 7.1.3.1. End-to-end and Hop-by-hop Header Fields 1916 For the purpose of defining the behavior of caches and non-caching 1917 proxies, we divide HTTP header fields into two categories: 1919 o End-to-end header fields, which are transmitted to the ultimate 1920 recipient of a request or response. End-to-end header fields in 1921 responses MUST be stored as part of a cache entry and MUST be 1922 transmitted in any response formed from a cache entry. 1924 o Hop-by-hop header fields, which are meaningful only for a single 1925 transport-level connection, and are not stored by caches or 1926 forwarded by proxies. 1928 The following HTTP/1.1 header fields are hop-by-hop header fields: 1930 o Connection 1932 o Keep-Alive 1933 o Proxy-Authenticate 1935 o Proxy-Authorization 1937 o TE 1939 o Trailer 1941 o Transfer-Encoding 1943 o Upgrade 1945 All other header fields defined by HTTP/1.1 are end-to-end header 1946 fields. 1948 Other hop-by-hop header fields MUST be listed in a Connection header 1949 field (Section 9.1). 1951 7.1.3.2. Non-modifiable Header Fields 1953 Some features of HTTP/1.1, such as Digest Authentication, depend on 1954 the value of certain end-to-end header fields. A transparent proxy 1955 SHOULD NOT modify an end-to-end header field unless the definition of 1956 that header field requires or specifically allows that. 1958 A transparent proxy MUST NOT modify any of the following fields in a 1959 request or response, and it MUST NOT add any of these fields if not 1960 already present: 1962 o Content-Location 1964 o Content-MD5 1966 o ETag 1968 o Last-Modified 1970 A transparent proxy MUST NOT modify any of the following fields in a 1971 response: 1973 o Expires 1975 but it MAY add any of these fields if not already present. If an 1976 Expires header field is added, it MUST be given a field-value 1977 identical to that of the Date header field in that response. 1979 A proxy MUST NOT modify or add any of the following fields in a 1980 message that contains the no-transform cache-control directive, or in 1981 any request: 1983 o Content-Encoding 1985 o Content-Range 1987 o Content-Type 1989 A non-transparent proxy MAY modify or add these fields to a message 1990 that does not include no-transform, but if it does so, it MUST add a 1991 Warning 214 (Transformation applied) if one does not already appear 1992 in the message (see Section 3.6 of [Part6]). 1994 Warning: Unnecessary modification of end-to-end header fields 1995 might cause authentication failures if stronger authentication 1996 mechanisms are introduced in later versions of HTTP. Such 1997 authentication mechanisms MAY rely on the values of header fields 1998 not listed here. 2000 A transparent proxy MUST preserve the message payload ([Part3]), 2001 though it MAY change the message-body through application or removal 2002 of a transfer-coding (Section 6.2). 2004 7.1.4. Practical Considerations 2006 Servers will usually have some time-out value beyond which they will 2007 no longer maintain an inactive connection. Proxy servers might make 2008 this a higher value since it is likely that the client will be making 2009 more connections through the same server. The use of persistent 2010 connections places no requirements on the length (or existence) of 2011 this time-out for either the client or the server. 2013 When a client or server wishes to time-out it SHOULD issue a graceful 2014 close on the transport connection. Clients and servers SHOULD both 2015 constantly watch for the other side of the transport close, and 2016 respond to it as appropriate. If a client or server does not detect 2017 the other side's close promptly it could cause unnecessary resource 2018 drain on the network. 2020 A client, server, or proxy MAY close the transport connection at any 2021 time. For example, a client might have started to send a new request 2022 at the same time that the server has decided to close the "idle" 2023 connection. From the server's point of view, the connection is being 2024 closed while it was idle, but from the client's point of view, a 2025 request is in progress. 2027 This means that clients, servers, and proxies MUST be able to recover 2028 from asynchronous close events. Client software SHOULD reopen the 2029 transport connection and retransmit the aborted sequence of requests 2030 without user interaction so long as the request sequence is 2031 idempotent (see Section 7.1.2 of [Part2]). Non-idempotent methods or 2032 sequences MUST NOT be automatically retried, although user agents MAY 2033 offer a human operator the choice of retrying the request(s). 2034 Confirmation by user-agent software with semantic understanding of 2035 the application MAY substitute for user confirmation. The automatic 2036 retry SHOULD NOT be repeated if the second sequence of requests 2037 fails. 2039 Servers SHOULD always respond to at least one request per connection, 2040 if at all possible. Servers SHOULD NOT close a connection in the 2041 middle of transmitting a response, unless a network or client failure 2042 is suspected. 2044 Clients (including proxies) SHOULD limit the number of simultaneous 2045 connections that they maintain to a given server (including proxies). 2047 Previous revisions of HTTP gave a specific number of connections as a 2048 ceiling, but this was found to be impractical for many applications. 2049 As a result, this specification does not mandate a particular maximum 2050 number of connections, but instead encourages clients to be 2051 conservative when opening multiple connections. 2053 In particular, while using multiple connections avoids the "head-of- 2054 line blocking" problem (whereby a request that takes significant 2055 server-side processing and/or has a large payload can block 2056 subsequent requests on the same connection), each connection used 2057 consumes server resources (sometimes significantly), and furthermore 2058 using multiple connections can cause undesirable side effects in 2059 congested networks. 2061 Note that servers might reject traffic that they deem abusive, 2062 including an excessive number of connections from a client. 2064 7.2. Message Transmission Requirements 2066 7.2.1. Persistent Connections and Flow Control 2068 HTTP/1.1 servers SHOULD maintain persistent connections and use TCP's 2069 flow control mechanisms to resolve temporary overloads, rather than 2070 terminating connections with the expectation that clients will retry. 2071 The latter technique can exacerbate network congestion. 2073 7.2.2. Monitoring Connections for Error Status Messages 2075 An HTTP/1.1 (or later) client sending a message-body SHOULD monitor 2076 the network connection for an error status code while it is 2077 transmitting the request. If the client sees an error status code, 2078 it SHOULD immediately cease transmitting the body. If the body is 2079 being sent using a "chunked" encoding (Section 6.2), a zero length 2080 chunk and empty trailer MAY be used to prematurely mark the end of 2081 the message. If the body was preceded by a Content-Length header 2082 field, the client MUST close the connection. 2084 7.2.3. Use of the 100 (Continue) Status 2086 The purpose of the 100 (Continue) status code (see Section 8.1.1 of 2087 [Part2]) is to allow a client that is sending a request message with 2088 a request body to determine if the origin server is willing to accept 2089 the request (based on the request header fields) before the client 2090 sends the request body. In some cases, it might either be 2091 inappropriate or highly inefficient for the client to send the body 2092 if the server will reject the message without looking at the body. 2094 Requirements for HTTP/1.1 clients: 2096 o If a client will wait for a 100 (Continue) response before sending 2097 the request body, it MUST send an Expect request-header field 2098 (Section 9.2 of [Part2]) with the "100-continue" expectation. 2100 o A client MUST NOT send an Expect request-header field (Section 9.2 2101 of [Part2]) with the "100-continue" expectation if it does not 2102 intend to send a request body. 2104 Because of the presence of older implementations, the protocol allows 2105 ambiguous situations in which a client might send "Expect: 100- 2106 continue" without receiving either a 417 (Expectation Failed) or a 2107 100 (Continue) status code. Therefore, when a client sends this 2108 header field to an origin server (possibly via a proxy) from which it 2109 has never seen a 100 (Continue) status code, the client SHOULD NOT 2110 wait for an indefinite period before sending the request body. 2112 Requirements for HTTP/1.1 origin servers: 2114 o Upon receiving a request which includes an Expect request-header 2115 field with the "100-continue" expectation, an origin server MUST 2116 either respond with 100 (Continue) status code and continue to 2117 read from the input stream, or respond with a final status code. 2118 The origin server MUST NOT wait for the request body before 2119 sending the 100 (Continue) response. If it responds with a final 2120 status code, it MAY close the transport connection or it MAY 2121 continue to read and discard the rest of the request. It MUST NOT 2122 perform the requested method if it returns a final status code. 2124 o An origin server SHOULD NOT send a 100 (Continue) response if the 2125 request message does not include an Expect request-header field 2126 with the "100-continue" expectation, and MUST NOT send a 100 2127 (Continue) response if such a request comes from an HTTP/1.0 (or 2128 earlier) client. There is an exception to this rule: for 2129 compatibility with [RFC2068], a server MAY send a 100 (Continue) 2130 status code in response to an HTTP/1.1 PUT or POST request that 2131 does not include an Expect request-header field with the "100- 2132 continue" expectation. This exception, the purpose of which is to 2133 minimize any client processing delays associated with an 2134 undeclared wait for 100 (Continue) status code, applies only to 2135 HTTP/1.1 requests, and not to requests with any other HTTP-version 2136 value. 2138 o An origin server MAY omit a 100 (Continue) response if it has 2139 already received some or all of the request body for the 2140 corresponding request. 2142 o An origin server that sends a 100 (Continue) response MUST 2143 ultimately send a final status code, once the request body is 2144 received and processed, unless it terminates the transport 2145 connection prematurely. 2147 o If an origin server receives a request that does not include an 2148 Expect request-header field with the "100-continue" expectation, 2149 the request includes a request body, and the server responds with 2150 a final status code before reading the entire request body from 2151 the transport connection, then the server SHOULD NOT close the 2152 transport connection until it has read the entire request, or 2153 until the client closes the connection. Otherwise, the client 2154 might not reliably receive the response message. However, this 2155 requirement is not be construed as preventing a server from 2156 defending itself against denial-of-service attacks, or from badly 2157 broken client implementations. 2159 Requirements for HTTP/1.1 proxies: 2161 o If a proxy receives a request that includes an Expect request- 2162 header field with the "100-continue" expectation, and the proxy 2163 either knows that the next-hop server complies with HTTP/1.1 or 2164 higher, or does not know the HTTP version of the next-hop server, 2165 it MUST forward the request, including the Expect header field. 2167 o If the proxy knows that the version of the next-hop server is 2168 HTTP/1.0 or lower, it MUST NOT forward the request, and it MUST 2169 respond with a 417 (Expectation Failed) status code. 2171 o Proxies SHOULD maintain a cache recording the HTTP version numbers 2172 received from recently-referenced next-hop servers. 2174 o A proxy MUST NOT forward a 100 (Continue) response if the request 2175 message was received from an HTTP/1.0 (or earlier) client and did 2176 not include an Expect request-header field with the "100-continue" 2177 expectation. This requirement overrides the general rule for 2178 forwarding of 1xx responses (see Section 8.1 of [Part2]). 2180 7.2.4. Client Behavior if Server Prematurely Closes Connection 2182 If an HTTP/1.1 client sends a request which includes a request body, 2183 but which does not include an Expect request-header field with the 2184 "100-continue" expectation, and if the client is not directly 2185 connected to an HTTP/1.1 origin server, and if the client sees the 2186 connection close before receiving a status line from the server, the 2187 client SHOULD retry the request. If the client does retry this 2188 request, it MAY use the following "binary exponential backoff" 2189 algorithm to be assured of obtaining a reliable response: 2191 1. Initiate a new connection to the server 2193 2. Transmit the request-header fields 2195 3. Initialize a variable R to the estimated round-trip time to the 2196 server (e.g., based on the time it took to establish the 2197 connection), or to a constant value of 5 seconds if the round- 2198 trip time is not available. 2200 4. Compute T = R * (2**N), where N is the number of previous retries 2201 of this request. 2203 5. Wait either for an error response from the server, or for T 2204 seconds (whichever comes first) 2206 6. If no error response is received, after T seconds transmit the 2207 body of the request. 2209 7. If client sees that the connection is closed prematurely, repeat 2210 from step 1 until the request is accepted, an error response is 2211 received, or the user becomes impatient and terminates the retry 2212 process. 2214 If at any point an error status code is received, the client 2216 o SHOULD NOT continue and 2217 o SHOULD close the connection if it has not completed sending the 2218 request message. 2220 8. Miscellaneous notes that might disappear 2222 8.1. Scheme aliases considered harmful 2224 [[TBD-aliases-harmful: describe why aliases like webcal are 2225 harmful.]] 2227 8.2. Use of HTTP for proxy communication 2229 [[TBD-proxy-other: Configured to use HTTP to proxy HTTP or other 2230 protocols.]] 2232 8.3. Interception of HTTP for access control 2234 [[TBD-intercept: Interception of HTTP traffic for initiating access 2235 control.]] 2237 8.4. Use of HTTP by other protocols 2239 [[TBD-profiles: Profiles of HTTP defined by other protocol. 2240 Extensions of HTTP like WebDAV.]] 2242 8.5. Use of HTTP by media type specification 2244 [[TBD-hypertext: Instructions on composing HTTP requests via 2245 hypertext formats.]] 2247 9. Header Field Definitions 2249 This section defines the syntax and semantics of HTTP/1.1 header 2250 fields related to message framing and transport protocols. 2252 9.1. Connection 2254 The "Connection" general-header field allows the sender to specify 2255 options that are desired for that particular connection and MUST NOT 2256 be communicated by proxies over further connections. 2258 The Connection header field's value has the following grammar: 2260 Connection = "Connection" ":" OWS Connection-v 2261 Connection-v = 1#connection-token 2262 connection-token = token 2264 HTTP/1.1 proxies MUST parse the Connection header field before a 2265 message is forwarded and, for each connection-token in this field, 2266 remove any header field(s) from the message with the same name as the 2267 connection-token. Connection options are signaled by the presence of 2268 a connection-token in the Connection header field, not by any 2269 corresponding additional header field(s), since the additional header 2270 field might not be sent if there are no parameters associated with 2271 that connection option. 2273 Message header fields listed in the Connection header field MUST NOT 2274 include end-to-end header fields, such as Cache-Control. 2276 HTTP/1.1 defines the "close" connection option for the sender to 2277 signal that the connection will be closed after completion of the 2278 response. For example, 2280 Connection: close 2282 in either the request or the response header fields indicates that 2283 the connection SHOULD NOT be considered "persistent" (Section 7.1) 2284 after the current request/response is complete. 2286 An HTTP/1.1 client that does not support persistent connections MUST 2287 include the "close" connection option in every request message. 2289 An HTTP/1.1 server that does not support persistent connections MUST 2290 include the "close" connection option in every response message that 2291 does not have a 1xx (Informational) status code. 2293 A system receiving an HTTP/1.0 (or lower-version) message that 2294 includes a Connection header field MUST, for each connection-token in 2295 this field, remove and ignore any header field(s) from the message 2296 with the same name as the connection-token. This protects against 2297 mistaken forwarding of such header fields by pre-HTTP/1.1 proxies. 2298 See Appendix B.2. 2300 9.2. Content-Length 2302 The "Content-Length" header field indicates the size of the message- 2303 body, in decimal number of octets, for any message other than a 2304 response to the HEAD method or a response with a status code of 304. 2305 In the case of responses to the HEAD method, it indicates the size of 2306 the payload body (not including any potential transfer-coding) that 2307 would have been sent had the request been a GET. In the case of the 2308 304 (Not Modified) response, it indicates the size of the payload 2309 body (not including any potential transfer-coding) that would have 2310 been sent in a 200 (OK) response. 2312 Content-Length = "Content-Length" ":" OWS 1*Content-Length-v 2313 Content-Length-v = 1*DIGIT 2315 An example is 2317 Content-Length: 3495 2319 Implementations SHOULD use this field to indicate the message-body 2320 length when no transfer-coding is being applied and the payload's 2321 body length can be determined prior to being transferred. 2322 Section 3.3 describes how recipients determine the length of a 2323 message-body. 2325 Any Content-Length greater than or equal to zero is a valid value. 2327 Note that the use of this field in HTTP is significantly different 2328 from the corresponding definition in MIME, where it is an optional 2329 field used within the "message/external-body" content-type. 2331 9.3. Date 2333 The "Date" general-header field represents the date and time at which 2334 the message was originated, having the same semantics as the 2335 Origination Date Field (orig-date) defined in Section 3.6.1 of 2336 [RFC5322]. The field value is an HTTP-date, as described in 2337 Section 6.1; it MUST be sent in rfc1123-date format. 2339 Date = "Date" ":" OWS Date-v 2340 Date-v = HTTP-date 2342 An example is 2344 Date: Tue, 15 Nov 1994 08:12:31 GMT 2346 Origin servers MUST include a Date header field in all responses, 2347 except in these cases: 2349 1. If the response status code is 100 (Continue) or 101 (Switching 2350 Protocols), the response MAY include a Date header field, at the 2351 server's option. 2353 2. If the response status code conveys a server error, e.g., 500 2354 (Internal Server Error) or 503 (Service Unavailable), and it is 2355 inconvenient or impossible to generate a valid Date. 2357 3. If the server does not have a clock that can provide a reasonable 2358 approximation of the current time, its responses MUST NOT include 2359 a Date header field. In this case, the rules in Section 9.3.1 2360 MUST be followed. 2362 A received message that does not have a Date header field MUST be 2363 assigned one by the recipient if the message will be cached by that 2364 recipient or gatewayed via a protocol which requires a Date. 2366 Clients can use the Date header field as well; in order to keep 2367 request messages small, they are advised not to include it when it 2368 doesn't convey any useful information (as it is usually the case for 2369 requests that do not contain a payload). 2371 The HTTP-date sent in a Date header field SHOULD NOT represent a date 2372 and time subsequent to the generation of the message. It SHOULD 2373 represent the best available approximation of the date and time of 2374 message generation, unless the implementation has no means of 2375 generating a reasonably accurate date and time. In theory, the date 2376 ought to represent the moment just before the payload is generated. 2377 In practice, the date can be generated at any time during the message 2378 origination without affecting its semantic value. 2380 9.3.1. Clockless Origin Server Operation 2382 Some origin server implementations might not have a clock available. 2383 An origin server without a clock MUST NOT assign Expires or Last- 2384 Modified values to a response, unless these values were associated 2385 with the resource by a system or user with a reliable clock. It MAY 2386 assign an Expires value that is known, at or before server 2387 configuration time, to be in the past (this allows "pre-expiration" 2388 of responses without storing separate Expires values for each 2389 resource). 2391 9.4. Host 2393 The "Host" request-header field specifies the Internet host and port 2394 number of the resource being requested, allowing the origin server or 2395 gateway to differentiate between internally-ambiguous URLs, such as 2396 the root "/" URL of a server for multiple host names on a single IP 2397 address. 2399 The Host field value MUST represent the naming authority of the 2400 origin server or gateway given by the original URL obtained from the 2401 user or referring resource (generally an http URI, as described in 2402 Section 2.6.1). 2404 Host = "Host" ":" OWS Host-v 2405 Host-v = uri-host [ ":" port ] ; Section 2.6.1 2407 A "host" without any trailing port information implies the default 2408 port for the service requested (e.g., "80" for an HTTP URL). For 2409 example, a request on the origin server for 2410 would properly include: 2412 GET /pub/WWW/ HTTP/1.1 2413 Host: www.example.org 2415 A client MUST include a Host header field in all HTTP/1.1 request 2416 messages. If the requested URI does not include an Internet host 2417 name for the service being requested, then the Host header field MUST 2418 be given with an empty value. An HTTP/1.1 proxy MUST ensure that any 2419 request message it forwards does contain an appropriate Host header 2420 field that identifies the service being requested by the proxy. All 2421 Internet-based HTTP/1.1 servers MUST respond with a 400 (Bad Request) 2422 status code to any HTTP/1.1 request message which lacks a Host header 2423 field. 2425 See Sections 4.2 and B.1.1 for other requirements relating to Host. 2427 9.5. TE 2429 The "TE" request-header field indicates what extension transfer- 2430 codings it is willing to accept in the response, and whether or not 2431 it is willing to accept trailer fields in a chunked transfer-coding. 2433 Its value consists of the keyword "trailers" and/or a comma-separated 2434 list of extension transfer-coding names with optional accept 2435 parameters (as described in Section 6.2). 2437 TE = "TE" ":" OWS TE-v 2438 TE-v = #t-codings 2439 t-codings = "trailers" / ( transfer-extension [ te-params ] ) 2440 te-params = OWS ";" OWS "q=" qvalue *( te-ext ) 2441 te-ext = OWS ";" OWS token [ "=" word ] 2443 The presence of the keyword "trailers" indicates that the client is 2444 willing to accept trailer fields in a chunked transfer-coding, as 2445 defined in Section 6.2.1. This keyword is reserved for use with 2446 transfer-coding values even though it does not itself represent a 2447 transfer-coding. 2449 Examples of its use are: 2451 TE: deflate 2452 TE: 2453 TE: trailers, deflate;q=0.5 2455 The TE header field only applies to the immediate connection. 2456 Therefore, the keyword MUST be supplied within a Connection header 2457 field (Section 9.1) whenever TE is present in an HTTP/1.1 message. 2459 A server tests whether a transfer-coding is acceptable, according to 2460 a TE field, using these rules: 2462 1. The "chunked" transfer-coding is always acceptable. If the 2463 keyword "trailers" is listed, the client indicates that it is 2464 willing to accept trailer fields in the chunked response on 2465 behalf of itself and any downstream clients. The implication is 2466 that, if given, the client is stating that either all downstream 2467 clients are willing to accept trailer fields in the forwarded 2468 response, or that it will attempt to buffer the response on 2469 behalf of downstream recipients. 2471 Note: HTTP/1.1 does not define any means to limit the size of a 2472 chunked response such that a client can be assured of buffering 2473 the entire response. 2475 2. If the transfer-coding being tested is one of the transfer- 2476 codings listed in the TE field, then it is acceptable unless it 2477 is accompanied by a qvalue of 0. (As defined in Section 6.4, a 2478 qvalue of 0 means "not acceptable".) 2480 3. If multiple transfer-codings are acceptable, then the acceptable 2481 transfer-coding with the highest non-zero qvalue is preferred. 2482 The "chunked" transfer-coding always has a qvalue of 1. 2484 If the TE field-value is empty or if no TE field is present, the only 2485 transfer-coding is "chunked". A message with no transfer-coding is 2486 always acceptable. 2488 9.6. Trailer 2490 The "Trailer" general-header field indicates that the given set of 2491 header fields is present in the trailer of a message encoded with 2492 chunked transfer-coding. 2494 Trailer = "Trailer" ":" OWS Trailer-v 2495 Trailer-v = 1#field-name 2497 An HTTP/1.1 message SHOULD include a Trailer header field in a 2498 message using chunked transfer-coding with a non-empty trailer. 2499 Doing so allows the recipient to know which header fields to expect 2500 in the trailer. 2502 If no Trailer header field is present, the trailer SHOULD NOT include 2503 any header fields. See Section 6.2.1 for restrictions on the use of 2504 trailer fields in a "chunked" transfer-coding. 2506 Message header fields listed in the Trailer header field MUST NOT 2507 include the following header fields: 2509 o Transfer-Encoding 2511 o Content-Length 2513 o Trailer 2515 9.7. Transfer-Encoding 2517 The "Transfer-Encoding" general-header field indicates what transfer- 2518 codings (if any) have been applied to the message body. It differs 2519 from Content-Encoding (Section 2.2 of [Part3]) in that transfer- 2520 codings are a property of the message (and therefore are removed by 2521 intermediaries), whereas content-codings are not. 2523 Transfer-Encoding = "Transfer-Encoding" ":" OWS 2524 Transfer-Encoding-v 2525 Transfer-Encoding-v = 1#transfer-coding 2527 Transfer-codings are defined in Section 6.2. An example is: 2529 Transfer-Encoding: chunked 2531 If multiple encodings have been applied to a representation, the 2532 transfer-codings MUST be listed in the order in which they were 2533 applied. Additional information about the encoding parameters MAY be 2534 provided by other header fields not defined by this specification. 2536 Many older HTTP/1.0 applications do not understand the Transfer- 2537 Encoding header field. 2539 9.8. Upgrade 2541 The "Upgrade" general-header field allows the client to specify what 2542 additional communication protocols it would like to use, if the 2543 server chooses to switch protocols. Additionally, the server MUST 2544 use the Upgrade header field within a 101 (Switching Protocols) 2545 response to indicate which protocol(s) are being switched to. 2547 Upgrade = "Upgrade" ":" OWS Upgrade-v 2548 Upgrade-v = 1#product 2550 For example, 2552 Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11 2554 The Upgrade header field is intended to provide a simple mechanism 2555 for transition from HTTP/1.1 to some other, incompatible protocol. 2556 It does so by allowing the client to advertise its desire to use 2557 another protocol, such as a later version of HTTP with a higher major 2558 version number, even though the current request has been made using 2559 HTTP/1.1. This eases the difficult transition between incompatible 2560 protocols by allowing the client to initiate a request in the more 2561 commonly supported protocol while indicating to the server that it 2562 would like to use a "better" protocol if available (where "better" is 2563 determined by the server, possibly according to the nature of the 2564 method and/or resource being requested). 2566 The Upgrade header field only applies to switching application-layer 2567 protocols upon the existing transport-layer connection. Upgrade 2568 cannot be used to insist on a protocol change; its acceptance and use 2569 by the server is optional. The capabilities and nature of the 2570 application-layer communication after the protocol change is entirely 2571 dependent upon the new protocol chosen, although the first action 2572 after changing the protocol MUST be a response to the initial HTTP 2573 request containing the Upgrade header field. 2575 The Upgrade header field only applies to the immediate connection. 2576 Therefore, the upgrade keyword MUST be supplied within a Connection 2577 header field (Section 9.1) whenever Upgrade is present in an HTTP/1.1 2578 message. 2580 The Upgrade header field cannot be used to indicate a switch to a 2581 protocol on a different connection. For that purpose, it is more 2582 appropriate to use a 301, 302, 303, or 305 redirection response. 2584 This specification only defines the protocol name "HTTP" for use by 2585 the family of Hypertext Transfer Protocols, as defined by the HTTP 2586 version rules of Section 2.5 and future updates to this 2587 specification. Additional tokens can be registered with IANA using 2588 the registration procedure defined below. 2590 9.8.1. Upgrade Token Registry 2592 The HTTP Upgrade Token Registry defines the name space for product 2593 tokens used to identify protocols in the Upgrade header field. Each 2594 registered token is associated with contact information and an 2595 optional set of specifications that details how the connection will 2596 be processed after it has been upgraded. 2598 Registrations are allowed on a First Come First Served basis as 2599 described in Section 4.1 of [RFC5226]. The specifications need not 2600 be IETF documents or be subject to IESG review. Registrations are 2601 subject to the following rules: 2603 1. A token, once registered, stays registered forever. 2605 2. The registration MUST name a responsible party for the 2606 registration. 2608 3. The registration MUST name a point of contact. 2610 4. The registration MAY name a set of specifications associated with 2611 that token. Such specifications need not be publicly available. 2613 5. The responsible party MAY change the registration at any time. 2614 The IANA will keep a record of all such changes, and make them 2615 available upon request. 2617 6. The responsible party for the first registration of a "product" 2618 token MUST approve later registrations of a "version" token 2619 together with that "product" token before they can be registered. 2621 7. If absolutely required, the IESG MAY reassign the responsibility 2622 for a token. This will normally only be used in the case when a 2623 responsible party cannot be contacted. 2625 9.9. Via 2627 The "Via" general-header field MUST be used by gateways and proxies 2628 to indicate the intermediate protocols and recipients between the 2629 user agent and the server on requests, and between the origin server 2630 and the client on responses. It is analogous to the "Received" field 2631 defined in Section 3.6.7 of [RFC5322] and is intended to be used for 2632 tracking message forwards, avoiding request loops, and identifying 2633 the protocol capabilities of all senders along the request/response 2634 chain. 2636 Via = "Via" ":" OWS Via-v 2637 Via-v = 1#( received-protocol RWS received-by 2638 [ RWS comment ] ) 2639 received-protocol = [ protocol-name "/" ] protocol-version 2640 protocol-name = token 2641 protocol-version = token 2642 received-by = ( uri-host [ ":" port ] ) / pseudonym 2643 pseudonym = token 2645 The received-protocol indicates the protocol version of the message 2646 received by the server or client along each segment of the request/ 2647 response chain. The received-protocol version is appended to the Via 2648 field value when the message is forwarded so that information about 2649 the protocol capabilities of upstream applications remains visible to 2650 all recipients. 2652 The protocol-name is optional if and only if it would be "HTTP". The 2653 received-by field is normally the host and optional port number of a 2654 recipient server or client that subsequently forwarded the message. 2655 However, if the real host is considered to be sensitive information, 2656 it MAY be replaced by a pseudonym. If the port is not given, it MAY 2657 be assumed to be the default port of the received-protocol. 2659 Multiple Via field values represent each proxy or gateway that has 2660 forwarded the message. Each recipient MUST append its information 2661 such that the end result is ordered according to the sequence of 2662 forwarding applications. 2664 Comments MAY be used in the Via header field to identify the software 2665 of the recipient proxy or gateway, analogous to the User-Agent and 2666 Server header fields. However, all comments in the Via field are 2667 optional and MAY be removed by any recipient prior to forwarding the 2668 message. 2670 For example, a request message could be sent from an HTTP/1.0 user 2671 agent to an internal proxy code-named "fred", which uses HTTP/1.1 to 2672 forward the request to a public proxy at p.example.net, which 2673 completes the request by forwarding it to the origin server at 2674 www.example.com. The request received by www.example.com would then 2675 have the following Via header field: 2677 Via: 1.0 fred, 1.1 p.example.net (Apache/1.1) 2679 Proxies and gateways used as a portal through a network firewall 2680 SHOULD NOT, by default, forward the names and ports of hosts within 2681 the firewall region. This information SHOULD only be propagated if 2682 explicitly enabled. If not enabled, the received-by host of any host 2683 behind the firewall SHOULD be replaced by an appropriate pseudonym 2684 for that host. 2686 For organizations that have strong privacy requirements for hiding 2687 internal structures, a proxy MAY combine an ordered subsequence of 2688 Via header field entries with identical received-protocol values into 2689 a single such entry. For example, 2691 Via: 1.0 ricky, 1.1 ethel, 1.1 fred, 1.0 lucy 2693 could be collapsed to 2695 Via: 1.0 ricky, 1.1 mertz, 1.0 lucy 2697 Applications SHOULD NOT combine multiple entries unless they are all 2698 under the same organizational control and the hosts have already been 2699 replaced by pseudonyms. Applications MUST NOT combine entries which 2700 have different received-protocol values. 2702 10. IANA Considerations 2704 10.1. Header Field Registration 2706 The Message Header Field Registry located at shall be 2708 updated with the permanent registrations below (see [RFC3864]): 2710 +-------------------+----------+----------+-------------+ 2711 | Header Field Name | Protocol | Status | Reference | 2712 +-------------------+----------+----------+-------------+ 2713 | Connection | http | standard | Section 9.1 | 2714 | Content-Length | http | standard | Section 9.2 | 2715 | Date | http | standard | Section 9.3 | 2716 | Host | http | standard | Section 9.4 | 2717 | TE | http | standard | Section 9.5 | 2718 | Trailer | http | standard | Section 9.6 | 2719 | Transfer-Encoding | http | standard | Section 9.7 | 2720 | Upgrade | http | standard | Section 9.8 | 2721 | Via | http | standard | Section 9.9 | 2722 +-------------------+----------+----------+-------------+ 2724 The change controller is: "IETF (iesg@ietf.org) - Internet 2725 Engineering Task Force". 2727 10.2. URI Scheme Registration 2729 The entries for the "http" and "https" URI Schemes in the registry 2730 located at shall 2731 be updated to point to Sections 2.6.1 and 2.6.2 of this document (see 2732 [RFC4395]). 2734 10.3. Internet Media Type Registrations 2736 This document serves as the specification for the Internet media 2737 types "message/http" and "application/http". The following is to be 2738 registered with IANA (see [RFC4288]). 2740 10.3.1. Internet Media Type message/http 2742 The message/http type can be used to enclose a single HTTP request or 2743 response message, provided that it obeys the MIME restrictions for 2744 all "message" types regarding line length and encodings. 2746 Type name: message 2748 Subtype name: http 2750 Required parameters: none 2752 Optional parameters: version, msgtype 2754 version: The HTTP-Version number of the enclosed message (e.g., 2755 "1.1"). If not present, the version can be determined from the 2756 first line of the body. 2758 msgtype: The message type -- "request" or "response". If not 2759 present, the type can be determined from the first line of the 2760 body. 2762 Encoding considerations: only "7bit", "8bit", or "binary" are 2763 permitted 2765 Security considerations: none 2767 Interoperability considerations: none 2769 Published specification: This specification (see Section 10.3.1). 2771 Applications that use this media type: 2773 Additional information: 2775 Magic number(s): none 2777 File extension(s): none 2779 Macintosh file type code(s): none 2781 Person and email address to contact for further information: See 2782 Authors Section. 2784 Intended usage: COMMON 2786 Restrictions on usage: none 2788 Author/Change controller: IESG 2790 10.3.2. Internet Media Type application/http 2792 The application/http type can be used to enclose a pipeline of one or 2793 more HTTP request or response messages (not intermixed). 2795 Type name: application 2797 Subtype name: http 2799 Required parameters: none 2801 Optional parameters: version, msgtype 2803 version: The HTTP-Version number of the enclosed messages (e.g., 2804 "1.1"). If not present, the version can be determined from the 2805 first line of the body. 2807 msgtype: The message type -- "request" or "response". If not 2808 present, the type can be determined from the first line of the 2809 body. 2811 Encoding considerations: HTTP messages enclosed by this type are in 2812 "binary" format; use of an appropriate Content-Transfer-Encoding 2813 is required when transmitted via E-mail. 2815 Security considerations: none 2817 Interoperability considerations: none 2819 Published specification: This specification (see Section 10.3.2). 2821 Applications that use this media type: 2823 Additional information: 2825 Magic number(s): none 2827 File extension(s): none 2829 Macintosh file type code(s): none 2831 Person and email address to contact for further information: See 2832 Authors Section. 2834 Intended usage: COMMON 2835 Restrictions on usage: none 2837 Author/Change controller: IESG 2839 10.4. Transfer Coding Registry 2841 The registration procedure for HTTP Transfer Codings is now defined 2842 by Section 6.2.3 of this document. 2844 The HTTP Transfer Codings Registry located at 2845 shall be updated 2846 with the registrations below: 2848 +----------+--------------------------------------+-----------------+ 2849 | Name | Description | Reference | 2850 +----------+--------------------------------------+-----------------+ 2851 | chunked | Transfer in a series of chunks | Section 6.2.1 | 2852 | compress | UNIX "compress" program method | Section 6.2.2.1 | 2853 | deflate | "deflate" compression mechanism | Section 6.2.2.2 | 2854 | | ([RFC1951]) used inside the "zlib" | | 2855 | | data format ([RFC1950]) | | 2856 | gzip | Same as GNU zip [RFC1952] | Section 6.2.2.3 | 2857 +----------+--------------------------------------+-----------------+ 2859 10.5. Upgrade Token Registration 2861 The registration procedure for HTTP Upgrade Tokens -- previously 2862 defined in Section 7.2 of [RFC2817] -- is now defined by 2863 Section 9.8.1 of this document. 2865 The HTTP Status Code Registry located at 2866 shall be 2867 updated with the registration below: 2869 +-------+---------------------------+-------------------------------+ 2870 | Value | Description | Reference | 2871 +-------+---------------------------+-------------------------------+ 2872 | HTTP | Hypertext Transfer | Section 2.5 of this | 2873 | | Protocol | specification | 2874 +-------+---------------------------+-------------------------------+ 2876 11. Security Considerations 2878 This section is meant to inform application developers, information 2879 providers, and users of the security limitations in HTTP/1.1 as 2880 described by this document. The discussion does not include 2881 definitive solutions to the problems revealed, though it does make 2882 some suggestions for reducing security risks. 2884 11.1. Personal Information 2886 HTTP clients are often privy to large amounts of personal information 2887 (e.g., the user's name, location, mail address, passwords, encryption 2888 keys, etc.), and SHOULD be very careful to prevent unintentional 2889 leakage of this information. We very strongly recommend that a 2890 convenient interface be provided for the user to control 2891 dissemination of such information, and that designers and 2892 implementors be particularly careful in this area. History shows 2893 that errors in this area often create serious security and/or privacy 2894 problems and generate highly adverse publicity for the implementor's 2895 company. 2897 11.2. Abuse of Server Log Information 2899 A server is in the position to save personal data about a user's 2900 requests which might identify their reading patterns or subjects of 2901 interest. This information is clearly confidential in nature and its 2902 handling can be constrained by law in certain countries. People 2903 using HTTP to provide data are responsible for ensuring that such 2904 material is not distributed without the permission of any individuals 2905 that are identifiable by the published results. 2907 11.3. Attacks Based On File and Path Names 2909 Implementations of HTTP origin servers SHOULD be careful to restrict 2910 the documents returned by HTTP requests to be only those that were 2911 intended by the server administrators. If an HTTP server translates 2912 HTTP URIs directly into file system calls, the server MUST take 2913 special care not to serve files that were not intended to be 2914 delivered to HTTP clients. For example, UNIX, Microsoft Windows, and 2915 other operating systems use ".." as a path component to indicate a 2916 directory level above the current one. On such a system, an HTTP 2917 server MUST disallow any such construct in the request-target if it 2918 would otherwise allow access to a resource outside those intended to 2919 be accessible via the HTTP server. Similarly, files intended for 2920 reference only internally to the server (such as access control 2921 files, configuration files, and script code) MUST be protected from 2922 inappropriate retrieval, since they might contain sensitive 2923 information. Experience has shown that minor bugs in such HTTP 2924 server implementations have turned into security risks. 2926 11.4. DNS Spoofing 2928 Clients using HTTP rely heavily on the Domain Name Service, and are 2929 thus generally prone to security attacks based on the deliberate mis- 2930 association of IP addresses and DNS names. Clients need to be 2931 cautious in assuming the continuing validity of an IP number/DNS name 2932 association. 2934 In particular, HTTP clients SHOULD rely on their name resolver for 2935 confirmation of an IP number/DNS name association, rather than 2936 caching the result of previous host name lookups. Many platforms 2937 already can cache host name lookups locally when appropriate, and 2938 they SHOULD be configured to do so. It is proper for these lookups 2939 to be cached, however, only when the TTL (Time To Live) information 2940 reported by the name server makes it likely that the cached 2941 information will remain useful. 2943 If HTTP clients cache the results of host name lookups in order to 2944 achieve a performance improvement, they MUST observe the TTL 2945 information reported by DNS. 2947 If HTTP clients do not observe this rule, they could be spoofed when 2948 a previously-accessed server's IP address changes. As network 2949 renumbering is expected to become increasingly common [RFC1900], the 2950 possibility of this form of attack will grow. Observing this 2951 requirement thus reduces this potential security vulnerability. 2953 This requirement also improves the load-balancing behavior of clients 2954 for replicated servers using the same DNS name and reduces the 2955 likelihood of a user's experiencing failure in accessing sites which 2956 use that strategy. 2958 11.5. Proxies and Caching 2960 By their very nature, HTTP proxies are men-in-the-middle, and 2961 represent an opportunity for man-in-the-middle attacks. Compromise 2962 of the systems on which the proxies run can result in serious 2963 security and privacy problems. Proxies have access to security- 2964 related information, personal information about individual users and 2965 organizations, and proprietary information belonging to users and 2966 content providers. A compromised proxy, or a proxy implemented or 2967 configured without regard to security and privacy considerations, 2968 might be used in the commission of a wide range of potential attacks. 2970 Proxy operators need to protect the systems on which proxies run as 2971 they would protect any system that contains or transports sensitive 2972 information. In particular, log information gathered at proxies 2973 often contains highly sensitive personal information, and/or 2974 information about organizations. Log information needs to be 2975 carefully guarded, and appropriate guidelines for use need to be 2976 developed and followed. (Section 11.2). 2978 Proxy implementors need to consider the privacy and security 2979 implications of their design and coding decisions, and of the 2980 configuration options they provide to proxy operators (especially the 2981 default configuration). 2983 Users of a proxy need to be aware that proxies are no trustworthier 2984 than the people who run them; HTTP itself cannot solve this problem. 2986 The judicious use of cryptography, when appropriate, might suffice to 2987 protect against a broad range of security and privacy attacks. Such 2988 cryptography is beyond the scope of the HTTP/1.1 specification. 2990 11.6. Denial of Service Attacks on Proxies 2992 They exist. They are hard to defend against. Research continues. 2993 Beware. 2995 12. Acknowledgments 2997 HTTP has evolved considerably over the years. It has benefited from 2998 a large and active developer community--the many people who have 2999 participated on the www-talk mailing list--and it is that community 3000 which has been most responsible for the success of HTTP and of the 3001 World-Wide Web in general. Marc Andreessen, Robert Cailliau, Daniel 3002 W. Connolly, Bob Denny, John Franks, Jean-Francois Groff, Phillip M. 3003 Hallam-Baker, Hakon W. Lie, Ari Luotonen, Rob McCool, Lou Montulli, 3004 Dave Raggett, Tony Sanders, and Marc VanHeyningen deserve special 3005 recognition for their efforts in defining early aspects of the 3006 protocol. 3008 This document has benefited greatly from the comments of all those 3009 participating in the HTTP-WG. In addition to those already 3010 mentioned, the following individuals have contributed to this 3011 specification: 3013 Gary Adams, Harald Tveit Alvestrand, Keith Ball, Brian Behlendorf, 3014 Paul Burchard, Maurizio Codogno, Josh Cohen, Mike Cowlishaw, Roman 3015 Czyborra, Michael A. Dolan, Daniel DuBois, David J. Fiander, Alan 3016 Freier, Marc Hedlund, Greg Herlihy, Koen Holtman, Alex Hopmann, Bob 3017 Jernigan, Shel Kaphan, Rohit Khare, John Klensin, Martijn Koster, 3018 Alexei Kosut, David M. Kristol, Daniel LaLiberte, Ben Laurie, Paul J. 3019 Leach, Albert Lunde, John C. Mallery, Jean-Philippe Martin-Flatin, 3020 Mitra, David Morris, Gavin Nicol, Ross Patterson, Bill Perry, Jeffrey 3021 Perry, Scott Powers, Owen Rees, Luigi Rizzo, David Robinson, Marc 3022 Salomon, Rich Salz, Allan M. Schiffman, Jim Seidman, Chuck Shotton, 3023 Eric W. Sink, Simon E. Spero, Richard N. Taylor, Robert S. Thau, Bill 3024 (BearHeart) Weinman, Francois Yergeau, Mary Ellen Zurko. 3026 Thanks to the "cave men" of Palo Alto. You know who you are. 3028 Jim Gettys (the editor of [RFC2616]) wishes particularly to thank Roy 3029 Fielding, the editor of [RFC2068], along with John Klensin, Jeff 3030 Mogul, Paul Leach, Dave Kristol, Koen Holtman, John Franks, Josh 3031 Cohen, Alex Hopmann, Scott Lawrence, and Larry Masinter for their 3032 help. And thanks go particularly to Jeff Mogul and Scott Lawrence 3033 for performing the "MUST/MAY/SHOULD" audit. 3035 The Apache Group, Anselm Baird-Smith, author of Jigsaw, and Henrik 3036 Frystyk implemented RFC 2068 early, and we wish to thank them for the 3037 discovery of many of the problems that this document attempts to 3038 rectify. 3040 This specification makes heavy use of the augmented BNF and generic 3041 constructs defined by David H. Crocker for [RFC5234]. Similarly, it 3042 reuses many of the definitions provided by Nathaniel Borenstein and 3043 Ned Freed for MIME [RFC2045]. We hope that their inclusion in this 3044 specification will help reduce past confusion over the relationship 3045 between HTTP and Internet mail message formats. 3047 13. References 3049 13.1. Normative References 3051 [ISO-8859-1] International Organization for Standardization, 3052 "Information technology -- 8-bit single-byte coded 3053 graphic character sets -- Part 1: Latin alphabet No. 3054 1", ISO/IEC 8859-1:1998, 1998. 3056 [Part2] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., 3057 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., 3058 Ed., and J. Reschke, Ed., "HTTP/1.1, part 2: Message 3059 Semantics", draft-ietf-httpbis-p2-semantics-12 (work in 3060 progress), October 2010. 3062 [Part3] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., 3063 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., 3064 Ed., and J. Reschke, Ed., "HTTP/1.1, part 3: Message 3065 Payload and Content Negotiation", 3066 draft-ietf-httpbis-p3-payload-12 (work in progress), 3067 October 2010. 3069 [Part6] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., 3070 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., 3071 Ed., Nottingham, M., Ed., and J. Reschke, Ed., 3072 "HTTP/1.1, part 6: Caching", 3073 draft-ietf-httpbis-p6-cache-12 (work in progress), 3074 October 2010. 3076 [RFC1950] Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data 3077 Format Specification version 3.3", RFC 1950, May 1996. 3079 RFC 1950 is an Informational RFC, thus it might be less 3080 stable than this specification. On the other hand, 3081 this downward reference was present since the 3082 publication of RFC 2068 in 1997 ([RFC2068]), therefore 3083 it is unlikely to cause problems in practice. See also 3084 [BCP97]. 3086 [RFC1951] Deutsch, P., "DEFLATE Compressed Data Format 3087 Specification version 1.3", RFC 1951, May 1996. 3089 RFC 1951 is an Informational RFC, thus it might be less 3090 stable than this specification. On the other hand, 3091 this downward reference was present since the 3092 publication of RFC 2068 in 1997 ([RFC2068]), therefore 3093 it is unlikely to cause problems in practice. See also 3094 [BCP97]. 3096 [RFC1952] Deutsch, P., Gailly, J-L., Adler, M., Deutsch, L., and 3097 G. Randers-Pehrson, "GZIP file format specification 3098 version 4.3", RFC 1952, May 1996. 3100 RFC 1952 is an Informational RFC, thus it might be less 3101 stable than this specification. On the other hand, 3102 this downward reference was present since the 3103 publication of RFC 2068 in 1997 ([RFC2068]), therefore 3104 it is unlikely to cause problems in practice. See also 3105 [BCP97]. 3107 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3108 Requirement Levels", BCP 14, RFC 2119, March 1997. 3110 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, 3111 "Uniform Resource Identifier (URI): Generic Syntax", 3112 STD 66, RFC 3986, January 2005. 3114 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for 3115 Syntax Specifications: ABNF", STD 68, RFC 5234, 3116 January 2008. 3118 [USASCII] American National Standards Institute, "Coded Character 3119 Set -- 7-bit American Standard Code for Information 3120 Interchange", ANSI X3.4, 1986. 3122 13.2. Informative References 3124 [BCP97] Klensin, J. and S. Hartman, "Handling Normative 3125 References to Standards-Track Documents", BCP 97, 3126 RFC 4897, June 2007. 3128 [Kri2001] Kristol, D., "HTTP Cookies: Standards, Privacy, and 3129 Politics", ACM Transactions on Internet Technology Vol. 3130 1, #2, November 2001, 3131 . 3133 [Nie1997] Frystyk, H., Gettys, J., Prud'hommeaux, E., Lie, H., 3134 and C. Lilley, "Network Performance Effects of 3135 HTTP/1.1, CSS1, and PNG", ACM Proceedings of the ACM 3136 SIGCOMM '97 conference on Applications, technologies, 3137 architectures, and protocols for computer communication 3138 SIGCOMM '97, September 1997, 3139 . 3141 [Pad1995] Padmanabhan, V. and J. Mogul, "Improving HTTP Latency", 3142 Computer Networks and ISDN Systems v. 28, pp. 25-35, 3143 December 1995, 3144 . 3146 [RFC1123] Braden, R., "Requirements for Internet Hosts - 3147 Application and Support", STD 3, RFC 1123, 3148 October 1989. 3150 [RFC1900] Carpenter, B. and Y. Rekhter, "Renumbering Needs Work", 3151 RFC 1900, February 1996. 3153 [RFC1945] Berners-Lee, T., Fielding, R., and H. Nielsen, 3154 "Hypertext Transfer Protocol -- HTTP/1.0", RFC 1945, 3155 May 1996. 3157 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet 3158 Mail Extensions (MIME) Part One: Format of Internet 3159 Message Bodies", RFC 2045, November 1996. 3161 [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail 3162 Extensions) Part Three: Message Header Extensions for 3163 Non-ASCII Text", RFC 2047, November 1996. 3165 [RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and 3166 T. Berners-Lee, "Hypertext Transfer Protocol -- 3167 HTTP/1.1", RFC 2068, January 1997. 3169 [RFC2109] Kristol, D. and L. Montulli, "HTTP State Management 3170 Mechanism", RFC 2109, February 1997. 3172 [RFC2145] Mogul, J., Fielding, R., Gettys, J., and H. Nielsen, 3173 "Use and Interpretation of HTTP Version Numbers", 3174 RFC 2145, May 1997. 3176 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 3177 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 3178 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 3180 [RFC2817] Khare, R. and S. Lawrence, "Upgrading to TLS Within 3181 HTTP/1.1", RFC 2817, May 2000. 3183 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 3185 [RFC2965] Kristol, D. and L. Montulli, "HTTP State Management 3186 Mechanism", RFC 2965, October 2000. 3188 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration 3189 Procedures for Message Header Fields", BCP 90, 3190 RFC 3864, September 2004. 3192 [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications 3193 and Registration Procedures", BCP 13, RFC 4288, 3194 December 2005. 3196 [RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines 3197 and Registration Procedures for New URI Schemes", 3198 BCP 115, RFC 4395, February 2006. 3200 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing 3201 an IANA Considerations Section in RFCs", BCP 26, 3202 RFC 5226, May 2008. 3204 [RFC5322] Resnick, P., "Internet Message Format", RFC 5322, 3205 October 2008. 3207 [Spe] Spero, S., "Analysis of HTTP Performance Problems", 3208 . 3210 [Tou1998] Touch, J., Heidemann, J., and K. Obraczka, "Analysis of 3211 HTTP Performance", ISI Research Report ISI/RR-98-463, 3212 Aug 1998, . 3214 (original report dated Aug. 1996) 3216 Appendix A. Tolerant Applications 3218 Although this document specifies the requirements for the generation 3219 of HTTP/1.1 messages, not all applications will be correct in their 3220 implementation. We therefore recommend that operational applications 3221 be tolerant of deviations whenever those deviations can be 3222 interpreted unambiguously. 3224 Clients SHOULD be tolerant in parsing the Status-Line and servers 3225 SHOULD be tolerant when parsing the Request-Line. In particular, 3226 they SHOULD accept any amount of WSP characters between fields, even 3227 though only a single SP is required. 3229 The line terminator for header fields is the sequence CRLF. However, 3230 we recommend that applications, when parsing such headers fields, 3231 recognize a single LF as a line terminator and ignore the leading CR. 3233 The character set of a representation SHOULD be labeled as the lowest 3234 common denominator of the character codes used within that 3235 representation, with the exception that not labeling the 3236 representation is preferred over labeling the representation with the 3237 labels US-ASCII or ISO-8859-1. See [Part3]. 3239 Additional rules for requirements on parsing and encoding of dates 3240 and other potential problems with date encodings include: 3242 o HTTP/1.1 clients and caches SHOULD assume that an RFC-850 date 3243 which appears to be more than 50 years in the future is in fact in 3244 the past (this helps solve the "year 2000" problem). 3246 o Although all date formats are specified to be case-sensitive, 3247 recipients SHOULD match day, week and timezone names case- 3248 insensitively. 3250 o An HTTP/1.1 implementation MAY internally represent a parsed 3251 Expires date as earlier than the proper value, but MUST NOT 3252 internally represent a parsed Expires date as later than the 3253 proper value. 3255 o All expiration-related calculations MUST be done in GMT. The 3256 local time zone MUST NOT influence the calculation or comparison 3257 of an age or expiration time. 3259 o If an HTTP header field incorrectly carries a date value with a 3260 time zone other than GMT, it MUST be converted into GMT using the 3261 most conservative possible conversion. 3263 Appendix B. Compatibility with Previous Versions 3265 HTTP has been in use by the World-Wide Web global information 3266 initiative since 1990. The first version of HTTP, later referred to 3267 as HTTP/0.9, was a simple protocol for hypertext data transfer across 3268 the Internet with only a single method and no metadata. HTTP/1.0, as 3269 defined by [RFC1945], added a range of request methods and MIME-like 3270 messaging that could include metadata about the data transferred and 3271 modifiers on the request/response semantics. However, HTTP/1.0 did 3272 not sufficiently take into consideration the effects of hierarchical 3273 proxies, caching, the need for persistent connections, or name-based 3274 virtual hosts. The proliferation of incompletely-implemented 3275 applications calling themselves "HTTP/1.0" further necessitated a 3276 protocol version change in order for two communicating applications 3277 to determine each other's true capabilities. 3279 HTTP/1.1 remains compatible with HTTP/1.0 by including more stringent 3280 requirements that enable reliable implementations, adding only those 3281 new features that will either be safely ignored by an HTTP/1.0 3282 recipient or only sent when communicating with a party advertising 3283 compliance with HTTP/1.1. 3285 It is beyond the scope of a protocol specification to mandate 3286 compliance with previous versions. HTTP/1.1 was deliberately 3287 designed, however, to make supporting previous versions easy. It is 3288 worth noting that, at the time of composing this specification, we 3289 would expect general-purpose HTTP/1.1 servers to: 3291 o understand any valid request in the format of HTTP/1.0 and 1.1; 3293 o respond appropriately with a message in the same major version 3294 used by the client. 3296 And we would expect HTTP/1.1 clients to: 3298 o understand any valid response in the format of HTTP/1.0 or 1.1. 3300 For most implementations of HTTP/1.0, each connection is established 3301 by the client prior to the request and closed by the server after 3302 sending the response. Some implementations implement the Keep-Alive 3303 version of persistent connections described in Section 19.7.1 of 3304 [RFC2068]. 3306 B.1. Changes from HTTP/1.0 3308 This section summarizes major differences between versions HTTP/1.0 3309 and HTTP/1.1. 3311 B.1.1. Changes to Simplify Multi-homed Web Servers and Conserve IP 3312 Addresses 3314 The requirements that clients and servers support the Host request- 3315 header field (Section 9.4), report an error if it is missing from an 3316 HTTP/1.1 request, and accept absolute URIs (Section 4.1.2) are among 3317 the most important changes defined by this specification. 3319 Older HTTP/1.0 clients assumed a one-to-one relationship of IP 3320 addresses and servers; there was no other established mechanism for 3321 distinguishing the intended server of a request than the IP address 3322 to which that request was directed. The changes outlined above will 3323 allow the Internet, once older HTTP clients are no longer common, to 3324 support multiple Web sites from a single IP address, greatly 3325 simplifying large operational Web servers, where allocation of many 3326 IP addresses to a single host has created serious problems. The 3327 Internet will also be able to recover the IP addresses that have been 3328 allocated for the sole purpose of allowing special-purpose domain 3329 names to be used in root-level HTTP URLs. Given the rate of growth 3330 of the Web, and the number of servers already deployed, it is 3331 extremely important that all implementations of HTTP (including 3332 updates to existing HTTP/1.0 applications) correctly implement these 3333 requirements: 3335 o Both clients and servers MUST support the Host request-header 3336 field. 3338 o A client that sends an HTTP/1.1 request MUST send a Host header 3339 field. 3341 o Servers MUST report a 400 (Bad Request) error if an HTTP/1.1 3342 request does not include a Host request-header field. 3344 o Servers MUST accept absolute URIs. 3346 B.2. Compatibility with HTTP/1.0 Persistent Connections 3348 Some clients and servers might wish to be compatible with some 3349 previous implementations of persistent connections in HTTP/1.0 3350 clients and servers. Persistent connections in HTTP/1.0 are 3351 explicitly negotiated as they are not the default behavior. HTTP/1.0 3352 experimental implementations of persistent connections are faulty, 3353 and the new facilities in HTTP/1.1 are designed to rectify these 3354 problems. The problem was that some existing HTTP/1.0 clients might 3355 send Keep-Alive to a proxy server that doesn't understand Connection, 3356 which would then erroneously forward it to the next inbound server, 3357 which would establish the Keep-Alive connection and result in a hung 3358 HTTP/1.0 proxy waiting for the close on the response. The result is 3359 that HTTP/1.0 clients must be prevented from using Keep-Alive when 3360 talking to proxies. 3362 However, talking to proxies is the most important use of persistent 3363 connections, so that prohibition is clearly unacceptable. Therefore, 3364 we need some other mechanism for indicating a persistent connection 3365 is desired, which is safe to use even when talking to an old proxy 3366 that ignores Connection. Persistent connections are the default for 3367 HTTP/1.1 messages; we introduce a new keyword (Connection: close) for 3368 declaring non-persistence. See Section 9.1. 3370 The original HTTP/1.0 form of persistent connections (the Connection: 3371 Keep-Alive and Keep-Alive header field) is documented in Section 3372 19.7.1 of [RFC2068]. 3374 B.3. Changes from RFC 2616 3376 Empty list elements in list productions have been deprecated. 3377 (Section 1.2.1) 3379 Rules about implicit linear whitespace between certain grammar 3380 productions have been removed; now it's only allowed when 3381 specifically pointed out in the ABNF. The NUL character is no longer 3382 allowed in comment and quoted-string text. The quoted-pair rule no 3383 longer allows escaping control characters other than HTAB. Non-ASCII 3384 content in header fields and reason phrase has been obsoleted and 3385 made opaque (the TEXT rule was removed) (Section 1.2.2) 3387 Clarify that HTTP-Version is case sensitive. (Section 2.5) 3389 Require that invalid whitespace around field-names be rejected. 3390 (Section 3.2) 3392 Require recipients to handle bogus Content-Length header fields as 3393 errors. (Section 3.3) 3395 Remove reference to non-existent identity transfer-coding value 3396 tokens. (Sections 3.3 and 6.2) 3398 Update use of abs_path production from RFC 1808 to the path-absolute 3399 + query components of RFC 3986. (Section 4.1.2) 3401 Clarification that the chunk length does not include the count of the 3402 octets in the chunk header and trailer. Furthermore disallowed line 3403 folding in chunk extensions. (Section 6.2.1) 3405 Remove hard limit of two connections per server. (Section 7.1.4) 3406 Clarify exactly when close connection options must be sent. 3407 (Section 9.1) 3409 Appendix C. Collected ABNF 3411 BWS = OWS 3413 Cache-Control = 3414 Chunked-Body = *chunk last-chunk trailer-part CRLF 3415 Connection = "Connection:" OWS Connection-v 3416 Connection-v = *( "," OWS ) connection-token *( OWS "," [ OWS 3417 connection-token ] ) 3418 Content-Length = "Content-Length:" OWS 1*Content-Length-v 3419 Content-Length-v = 1*DIGIT 3421 Date = "Date:" OWS Date-v 3422 Date-v = HTTP-date 3424 GMT = %x47.4D.54 ; GMT 3426 HTTP-Prot-Name = %x48.54.54.50 ; HTTP 3427 HTTP-Version = HTTP-Prot-Name "/" 1*DIGIT "." 1*DIGIT 3428 HTTP-date = rfc1123-date / obs-date 3429 HTTP-message = start-line *( header-field CRLF ) CRLF [ message-body 3430 ] 3431 Host = "Host:" OWS Host-v 3432 Host-v = uri-host [ ":" port ] 3434 MIME-Version = 3435 Method = token 3437 OWS = *( [ obs-fold ] WSP ) 3439 Pragma = 3441 RWS = 1*( [ obs-fold ] WSP ) 3442 Reason-Phrase = *( WSP / VCHAR / obs-text ) 3443 Request = Request-Line *( header-field CRLF ) CRLF [ message-body ] 3444 Request-Line = Method SP request-target SP HTTP-Version CRLF 3445 Response = Status-Line *( header-field CRLF ) CRLF [ message-body ] 3447 Status-Code = 3DIGIT 3448 Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF 3450 TE = "TE:" OWS TE-v 3451 TE-v = [ ( "," / t-codings ) *( OWS "," [ OWS t-codings ] ) ] 3452 Trailer = "Trailer:" OWS Trailer-v 3453 Trailer-v = *( "," OWS ) field-name *( OWS "," [ OWS field-name ] ) 3454 Transfer-Encoding = "Transfer-Encoding:" OWS Transfer-Encoding-v 3455 Transfer-Encoding-v = *( "," OWS ) transfer-coding *( OWS "," [ OWS 3456 transfer-coding ] ) 3458 URI-reference = 3459 Upgrade = "Upgrade:" OWS Upgrade-v 3460 Upgrade-v = *( "," OWS ) product *( OWS "," [ OWS product ] ) 3462 Via = "Via:" OWS Via-v 3463 Via-v = *( "," OWS ) received-protocol RWS received-by [ RWS comment 3464 ] *( OWS "," [ OWS received-protocol RWS received-by [ RWS comment ] 3465 ] ) 3467 Warning = 3469 absolute-URI = 3470 asctime-date = day-name SP date3 SP time-of-day SP year 3471 attribute = token 3472 authority = 3474 chunk = chunk-size *WSP [ chunk-ext ] CRLF chunk-data CRLF 3475 chunk-data = 1*OCTET 3476 chunk-ext = *( ";" *WSP chunk-ext-name [ "=" chunk-ext-val ] *WSP ) 3477 chunk-ext-name = token 3478 chunk-ext-val = token / quoted-str-nf 3479 chunk-size = 1*HEXDIG 3480 comment = "(" *( ctext / quoted-cpair / comment ) ")" 3481 connection-token = token 3482 ctext = OWS / %x21-27 ; '!'-''' 3483 / %x2A-5B ; '*'-'[' 3484 / %x5D-7E ; ']'-'~' 3485 / obs-text 3487 date1 = day SP month SP year 3488 date2 = day "-" month "-" 2DIGIT 3489 date3 = month SP ( 2DIGIT / ( SP DIGIT ) ) 3490 day = 2DIGIT 3491 day-name = %x4D.6F.6E ; Mon 3492 / %x54.75.65 ; Tue 3493 / %x57.65.64 ; Wed 3494 / %x54.68.75 ; Thu 3495 / %x46.72.69 ; Fri 3496 / %x53.61.74 ; Sat 3497 / %x53.75.6E ; Sun 3499 day-name-l = %x4D.6F.6E.64.61.79 ; Monday 3500 / %x54.75.65.73.64.61.79 ; Tuesday 3501 / %x57.65.64.6E.65.73.64.61.79 ; Wednesday 3502 / %x54.68.75.72.73.64.61.79 ; Thursday 3503 / %x46.72.69.64.61.79 ; Friday 3504 / %x53.61.74.75.72.64.61.79 ; Saturday 3505 / %x53.75.6E.64.61.79 ; Sunday 3507 field-content = *( WSP / VCHAR / obs-text ) 3508 field-name = token 3509 field-value = *( field-content / OWS ) 3511 general-header = Cache-Control / Connection / Date / Pragma / Trailer 3512 / Transfer-Encoding / Upgrade / Via / Warning / MIME-Version 3514 header-field = field-name ":" OWS [ field-value ] OWS 3515 hour = 2DIGIT 3516 http-URI = "http://" authority path-abempty [ "?" query ] 3517 https-URI = "https://" authority path-abempty [ "?" query ] 3519 last-chunk = 1*"0" *WSP [ chunk-ext ] CRLF 3521 message-body = *OCTET 3522 minute = 2DIGIT 3523 month = %x4A.61.6E ; Jan 3524 / %x46.65.62 ; Feb 3525 / %x4D.61.72 ; Mar 3526 / %x41.70.72 ; Apr 3527 / %x4D.61.79 ; May 3528 / %x4A.75.6E ; Jun 3529 / %x4A.75.6C ; Jul 3530 / %x41.75.67 ; Aug 3531 / %x53.65.70 ; Sep 3532 / %x4F.63.74 ; Oct 3533 / %x4E.6F.76 ; Nov 3534 / %x44.65.63 ; Dec 3536 obs-date = rfc850-date / asctime-date 3537 obs-fold = CRLF 3538 obs-text = %x80-FF 3540 partial-URI = relative-part [ "?" query ] 3541 path-abempty = 3542 path-absolute = 3543 port = 3544 product = token [ "/" product-version ] 3545 product-version = token 3546 protocol-name = token 3547 protocol-version = token 3548 pseudonym = token 3550 qdtext = OWS / "!" / %x23-5B ; '#'-'[' 3551 / %x5D-7E ; ']'-'~' 3552 / obs-text 3553 qdtext-nf = WSP / "!" / %x23-5B ; '#'-'[' 3554 / %x5D-7E ; ']'-'~' 3555 / obs-text 3556 query = 3557 quoted-cpair = "\" ( WSP / VCHAR / obs-text ) 3558 quoted-pair = "\" ( WSP / VCHAR / obs-text ) 3559 quoted-str-nf = DQUOTE *( qdtext-nf / quoted-pair ) DQUOTE 3560 quoted-string = DQUOTE *( qdtext / quoted-pair ) DQUOTE 3561 qvalue = ( "0" [ "." *3DIGIT ] ) / ( "1" [ "." *3"0" ] ) 3563 received-by = ( uri-host [ ":" port ] ) / pseudonym 3564 received-protocol = [ protocol-name "/" ] protocol-version 3565 relative-part = 3566 request-header = 3567 request-target = "*" / absolute-URI / ( path-absolute [ "?" query ] ) 3568 / authority 3569 response-header = 3570 rfc1123-date = day-name "," SP date1 SP time-of-day SP GMT 3571 rfc850-date = day-name-l "," SP date2 SP time-of-day SP GMT 3573 second = 2DIGIT 3574 special = "(" / ")" / "<" / ">" / "@" / "," / ";" / ":" / "\" / 3575 DQUOTE / "/" / "[" / "]" / "?" / "=" / "{" / "}" 3576 start-line = Request-Line / Status-Line 3578 t-codings = "trailers" / ( transfer-extension [ te-params ] ) 3579 tchar = "!" / "#" / "$" / "%" / "&" / "'" / "*" / "+" / "-" / "." / 3580 "^" / "_" / "`" / "|" / "~" / DIGIT / ALPHA 3581 te-ext = OWS ";" OWS token [ "=" word ] 3582 te-params = OWS ";" OWS "q=" qvalue *te-ext 3583 time-of-day = hour ":" minute ":" second 3584 token = 1*tchar 3585 trailer-part = *( header-field CRLF ) 3586 transfer-coding = "chunked" / "compress" / "deflate" / "gzip" / 3587 transfer-extension 3588 transfer-extension = token *( OWS ";" OWS transfer-parameter ) 3589 transfer-parameter = attribute BWS "=" BWS value 3591 uri-host = 3593 value = word 3594 word = token / quoted-string 3596 year = 4DIGIT 3598 ABNF diagnostics: 3600 ; Chunked-Body defined but not used 3601 ; Content-Length defined but not used 3602 ; HTTP-message defined but not used 3603 ; Host defined but not used 3604 ; Request defined but not used 3605 ; Response defined but not used 3606 ; TE defined but not used 3607 ; URI-reference defined but not used 3608 ; general-header defined but not used 3609 ; http-URI defined but not used 3610 ; https-URI defined but not used 3611 ; partial-URI defined but not used 3612 ; request-header defined but not used 3613 ; response-header defined but not used 3614 ; special defined but not used 3616 Appendix D. Change Log (to be removed by RFC Editor before publication) 3618 D.1. Since RFC 2616 3620 Extracted relevant partitions from [RFC2616]. 3622 D.2. Since draft-ietf-httpbis-p1-messaging-00 3624 Closed issues: 3626 o : "HTTP Version 3627 should be case sensitive" 3628 () 3630 o : "'unsafe' 3631 characters" () 3633 o : "Chunk Size 3634 Definition" () 3636 o : "Message Length" 3637 () 3639 o : "Media Type 3640 Registrations" () 3642 o : "URI includes 3643 query" () 3645 o : "No close on 3646 1xx responses" () 3648 o : "Remove 3649 'identity' token references" 3650 () 3652 o : "Import query 3653 BNF" 3655 o : "qdtext BNF" 3657 o : "Normative and 3658 Informative references" 3660 o : "RFC2606 3661 Compliance" 3663 o : "RFC977 3664 reference" 3666 o : "RFC1700 3667 references" 3669 o : "inconsistency 3670 in date format explanation" 3672 o : "Date reference 3673 typo" 3675 o : "Informative 3676 references" 3678 o : "ISO-8859-1 3679 Reference" 3681 o : "Normative up- 3682 to-date references" 3684 Other changes: 3686 o Update media type registrations to use RFC4288 template. 3688 o Use names of RFC4234 core rules DQUOTE and WSP, fix broken ABNF 3689 for chunk-data (work in progress on 3690 ) 3692 D.3. Since draft-ietf-httpbis-p1-messaging-01 3694 Closed issues: 3696 o : "Bodies on GET 3697 (and other) requests" 3699 o : "Updating to 3700 RFC4288" 3702 o : "Status Code 3703 and Reason Phrase" 3705 o : "rel_path not 3706 used" 3708 Ongoing work on ABNF conversion 3709 (): 3711 o Get rid of duplicate BNF rule names ("host" -> "uri-host", 3712 "trailer" -> "trailer-part"). 3714 o Avoid underscore character in rule names ("http_URL" -> "http- 3715 URL", "abs_path" -> "path-absolute"). 3717 o Add rules for terms imported from URI spec ("absoluteURI", 3718 "authority", "path-absolute", "port", "query", "relativeURI", 3719 "host) -- these will have to be updated when switching over to 3720 RFC3986. 3722 o Synchronize core rules with RFC5234. 3724 o Get rid of prose rules that span multiple lines. 3726 o Get rid of unused rules LOALPHA and UPALPHA. 3728 o Move "Product Tokens" section (back) into Part 1, as "token" is 3729 used in the definition of the Upgrade header field. 3731 o Add explicit references to BNF syntax and rules imported from 3732 other parts of the specification. 3734 o Rewrite prose rule "token" in terms of "tchar", rewrite prose rule 3735 "TEXT". 3737 D.4. Since draft-ietf-httpbis-p1-messaging-02 3739 Closed issues: 3741 o : "HTTP-date vs. 3742 rfc1123-date" 3744 o : "WS in quoted- 3745 pair" 3747 Ongoing work on IANA Message Header Field Registration 3748 (): 3750 o Reference RFC 3984, and update header field registrations for 3751 headers defined in this document. 3753 Ongoing work on ABNF conversion 3754 (): 3756 o Replace string literals when the string really is case-sensitive 3757 (HTTP-Version). 3759 D.5. Since draft-ietf-httpbis-p1-messaging-03 3761 Closed issues: 3763 o : "Connection 3764 closing" 3766 o : "Move 3767 registrations and registry information to IANA Considerations" 3769 o : "need new URL 3770 for PAD1995 reference" 3772 o : "IANA 3773 Considerations: update HTTP URI scheme registration" 3775 o : "Cite HTTPS 3776 URI scheme definition" 3778 o : "List-type 3779 headers vs Set-Cookie" 3781 Ongoing work on ABNF conversion 3782 (): 3784 o Replace string literals when the string really is case-sensitive 3785 (HTTP-Date). 3787 o Replace HEX by HEXDIG for future consistence with RFC 5234's core 3788 rules. 3790 D.6. Since draft-ietf-httpbis-p1-messaging-04 3792 Closed issues: 3794 o : "Out-of-date 3795 reference for URIs" 3797 o : "RFC 2822 is 3798 updated by RFC 5322" 3800 Ongoing work on ABNF conversion 3801 (): 3803 o Use "/" instead of "|" for alternatives. 3805 o Get rid of RFC822 dependency; use RFC5234 plus extensions instead. 3807 o Only reference RFC 5234's core rules. 3809 o Introduce new ABNF rules for "bad" whitespace ("BWS"), optional 3810 whitespace ("OWS") and required whitespace ("RWS"). 3812 o Rewrite ABNFs to spell out whitespace rules, factor out header 3813 field value format definitions. 3815 D.7. Since draft-ietf-httpbis-p1-messaging-05 3817 Closed issues: 3819 o : "Header LWS" 3821 o : "Sort 1.3 3822 Terminology" 3824 o : "RFC2047 3825 encoded words" 3827 o : "Character 3828 Encodings in TEXT" 3830 o : "Line Folding" 3831 o : "OPTIONS * and 3832 proxies" 3834 o : "Reason-Phrase 3835 BNF" 3837 o : "Use of TEXT" 3839 o : "Join 3840 "Differences Between HTTP Entities and RFC 2045 Entities"?" 3842 o : "RFC822 3843 reference left in discussion of date formats" 3845 Final work on ABNF conversion 3846 (): 3848 o Rewrite definition of list rules, deprecate empty list elements. 3850 o Add appendix containing collected and expanded ABNF. 3852 Other changes: 3854 o Rewrite introduction; add mostly new Architecture Section. 3856 o Move definition of quality values from Part 3 into Part 1; make TE 3857 request header field grammar independent of accept-params (defined 3858 in Part 3). 3860 D.8. Since draft-ietf-httpbis-p1-messaging-06 3862 Closed issues: 3864 o : "base for 3865 numeric protocol elements" 3867 o : "comment ABNF" 3869 Partly resolved issues: 3871 o : "205 Bodies" 3872 (took out language that implied that there might be methods for 3873 which a request body MUST NOT be included) 3875 o : "editorial 3876 improvements around HTTP-date" 3878 D.9. Since draft-ietf-httpbis-p1-messaging-07 3880 Closed issues: 3882 o : "Repeating 3883 single-value headers" 3885 o : "increase 3886 connection limit" 3888 o : "IP addresses 3889 in URLs" 3891 o : "take over 3892 HTTP Upgrade Token Registry" 3894 o : "CR and LF in 3895 chunk extension values" 3897 o : "HTTP/0.9 3898 support" 3900 o : "pick IANA 3901 policy (RFC5226) for Transfer Coding / Content Coding" 3903 o : "move 3904 definitions of gzip/deflate/compress to part 1" 3906 o : "disallow 3907 control characters in quoted-pair" 3909 Partly resolved issues: 3911 o : "update IANA 3912 requirements wrt Transfer-Coding values" (add the IANA 3913 Considerations subsection) 3915 D.10. Since draft-ietf-httpbis-p1-messaging-08 3917 Closed issues: 3919 o : "header 3920 parsing, treatment of leading and trailing OWS" 3922 Partly resolved issues: 3924 o : "Placement of 3925 13.5.1 and 13.5.2" 3927 o : "use of term 3928 "word" when talking about header structure" 3930 D.11. Since draft-ietf-httpbis-p1-messaging-09 3932 Closed issues: 3934 o : "Clarification 3935 of the term 'deflate'" 3937 o : "OPTIONS * and 3938 proxies" 3940 o : "MIME-Version 3941 not listed in P1, general header fields" 3943 o : "IANA registry 3944 for content/transfer encodings" 3946 o : "Case- 3947 sensitivity of HTTP-date" 3949 o : "use of term 3950 "word" when talking about header structure" 3952 Partly resolved issues: 3954 o : "Term for the 3955 requested resource's URI" 3957 D.12. Since draft-ietf-httpbis-p1-messaging-10 3959 Closed issues: 3961 o : "Connection 3962 Closing" 3964 o : "Delimiting 3965 messages with multipart/byteranges" 3967 o : "Handling 3968 multiple Content-Length headers" 3970 o : "Clarify 3971 entity / representation / variant terminology" 3973 o : "consider 3974 removing the 'changes from 2068' sections" 3976 Partly resolved issues: 3978 o : "HTTP(s) URI 3979 scheme definitions" 3981 D.13. Since draft-ietf-httpbis-p1-messaging-11 3983 Closed issues: 3985 o : "Trailer 3986 requirements" 3988 o : "Text about 3989 clock requirement for caches belongs in p6" 3991 o : "effective 3992 request URI: handling of missing host in HTTP/1.0" 3994 o : "confusing 3995 Date requirements for clients" 3997 Partly resolved issues: 3999 o : "Handling 4000 multiple Content-Length headers" 4002 Index 4004 A 4005 absolute-URI form (of request-target) 27 4006 application/http Media Type 61 4007 asterisk form (of request-target) 27 4008 authority form (of request-target) 27 4010 B 4011 browser 10 4013 C 4014 cache 13 4015 cacheable 14 4016 chunked (Coding Format) 35 4017 client 10 4018 Coding Format 4019 chunked 35 4020 compress 38 4021 deflate 38 4022 gzip 38 4023 compress (Coding Format) 38 4024 connection 10 4025 Connection header 49 4026 Content-Length header 50 4028 D 4029 Date header 51 4030 deflate (Coding Format) 38 4031 downstream 12 4033 E 4034 effective request URI 29 4036 G 4037 gateway 13 4038 Grammar 4039 absolute-URI 16 4040 ALPHA 7 4041 asctime-date 34 4042 attribute 34 4043 authority 16 4044 BWS 9 4045 chunk 35 4046 chunk-data 35 4047 chunk-ext 35 4048 chunk-ext-name 35 4049 chunk-ext-val 35 4050 chunk-size 35 4051 Chunked-Body 35 4052 comment 22 4053 Connection 49 4054 connection-token 49 4055 Connection-v 49 4056 Content-Length 50 4057 Content-Length-v 50 4058 CR 7 4059 CRLF 7 4060 ctext 22 4061 CTL 7 4062 Date 51 4063 Date-v 51 4064 date1 33 4065 date2 34 4066 date3 34 4067 day 33 4068 day-name 33 4069 day-name-l 33 4070 DIGIT 7 4071 DQUOTE 7 4072 extension-code 32 4073 extension-method 26 4074 field-content 20 4075 field-name 20 4076 field-value 20 4077 general-header 26 4078 GMT 33 4079 header-field 20 4080 HEXDIG 7 4081 Host 52 4082 Host-v 52 4083 hour 33 4084 HTTP-date 32 4085 HTTP-message 19 4086 HTTP-Prot-Name 15 4087 http-URI 16 4088 HTTP-Version 15 4089 https-URI 18 4090 last-chunk 35 4091 LF 7 4092 message-body 22 4093 Method 26 4094 minute 33 4095 month 33 4096 obs-date 33 4097 obs-text 10 4098 OCTET 7 4099 OWS 9 4100 path-absolute 16 4101 port 16 4102 product 39 4103 product-version 39 4104 protocol-name 57 4105 protocol-version 57 4106 pseudonym 57 4107 qdtext 10 4108 qdtext-nf 35 4109 query 16 4110 quoted-cpair 22 4111 quoted-pair 10 4112 quoted-str-nf 35 4113 quoted-string 10 4114 qvalue 39 4115 Reason-Phrase 32 4116 received-by 57 4117 received-protocol 57 4118 Request 26 4119 Request-Line 26 4120 request-target 27 4121 Response 31 4122 rfc850-date 34 4123 rfc1123-date 33 4124 RWS 9 4125 second 33 4126 SP 7 4127 special 9 4128 Status-Code 32 4129 Status-Line 31 4130 t-codings 53 4131 tchar 9 4132 TE 53 4133 te-ext 53 4134 te-params 53 4135 TE-v 53 4136 time-of-day 33 4137 token 9 4138 Trailer 54 4139 trailer-part 35 4140 Trailer-v 54 4141 transfer-coding 34 4142 Transfer-Encoding 55 4143 Transfer-Encoding-v 55 4144 transfer-extension 34 4145 transfer-parameter 34 4146 Upgrade 55 4147 Upgrade-v 55 4148 uri-host 16 4149 URI-reference 16 4150 value 34 4151 VCHAR 7 4152 Via 57 4153 Via-v 57 4154 word 9 4155 WSP 7 4156 year 33 4157 gzip (Coding Format) 38 4159 H 4160 header field 19 4161 header section 19 4162 Headers 4163 Connection 49 4164 Content-Length 50 4165 Date 51 4166 Host 52 4167 TE 53 4168 Trailer 54 4169 Transfer-Encoding 55 4170 Upgrade 55 4171 Via 57 4172 headers 19 4173 Host header 52 4174 http URI scheme 16 4175 https URI scheme 18 4177 I 4178 inbound 12 4179 intermediary 12 4181 M 4182 Media Type 4183 application/http 61 4184 message/http 59 4185 message 11 4186 message/http Media Type 59 4188 O 4189 origin server 10 4190 outbound 12 4192 P 4193 path-absolute form (of request-target) 27 4194 proxy 12 4196 R 4197 request 11 4198 resource 16 4199 response 11 4200 reverse proxy 13 4202 S 4203 server 10 4204 spider 10 4206 T 4207 target resource 29 4208 TE header 53 4209 Trailer header 54 4210 Transfer-Encoding header 55 4211 tunnel 13 4213 U 4214 Upgrade header 55 4215 upstream 12 4216 URI scheme 4217 http 16 4218 https 18 4219 user agent 10 4221 V 4222 Via header 57 4224 Authors' Addresses 4226 Roy T. Fielding (editor) 4227 Day Software 4228 23 Corporate Plaza DR, Suite 280 4229 Newport Beach, CA 92660 4230 USA 4232 Phone: +1-949-706-5300 4233 Fax: +1-949-706-5305 4234 EMail: fielding@gbiv.com 4235 URI: http://roy.gbiv.com/ 4237 Jim Gettys 4238 Alcatel-Lucent Bell Labs 4239 21 Oak Knoll Road 4240 Carlisle, MA 01741 4241 USA 4243 EMail: jg@freedesktop.org 4244 URI: http://gettys.wordpress.com/ 4246 Jeffrey C. Mogul 4247 Hewlett-Packard Company 4248 HP Labs, Large Scale Systems Group 4249 1501 Page Mill Road, MS 1177 4250 Palo Alto, CA 94304 4251 USA 4253 EMail: JeffMogul@acm.org 4254 Henrik Frystyk Nielsen 4255 Microsoft Corporation 4256 1 Microsoft Way 4257 Redmond, WA 98052 4258 USA 4260 EMail: henrikn@microsoft.com 4262 Larry Masinter 4263 Adobe Systems, Incorporated 4264 345 Park Ave 4265 San Jose, CA 95110 4266 USA 4268 EMail: LMM@acm.org 4269 URI: http://larry.masinter.net/ 4271 Paul J. Leach 4272 Microsoft Corporation 4273 1 Microsoft Way 4274 Redmond, WA 98052 4276 EMail: paulle@microsoft.com 4278 Tim Berners-Lee 4279 World Wide Web Consortium 4280 MIT Computer Science and Artificial Intelligence Laboratory 4281 The Stata Center, Building 32 4282 32 Vassar Street 4283 Cambridge, MA 02139 4284 USA 4286 EMail: timbl@w3.org 4287 URI: http://www.w3.org/People/Berners-Lee/ 4288 Yves Lafon (editor) 4289 World Wide Web Consortium 4290 W3C / ERCIM 4291 2004, rte des Lucioles 4292 Sophia-Antipolis, AM 06902 4293 France 4295 EMail: ylafon@w3.org 4296 URI: http://www.raubacapeu.net/people/yves/ 4298 Julian F. Reschke (editor) 4299 greenbytes GmbH 4300 Hafenweg 16 4301 Muenster, NW 48155 4302 Germany 4304 Phone: +49 251 2807760 4305 Fax: +49 251 2807761 4306 EMail: julian.reschke@greenbytes.de 4307 URI: http://greenbytes.de/tech/webdav/