idnits 2.17.1 draft-ietf-httpbis-p1-messaging-15.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 obsoletes RFC2145, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC2817, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC2817, updated by this document, for RFC5378 checks: 1998-11-18) -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 11, 2011) is 4673 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 3322, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO-8859-1' == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p2-semantics-15 == Outdated reference: A later version (-20) exists of draft-ietf-httpbis-p3-payload-15 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p6-cache-15 ** 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 2145 (Obsoleted by RFC 7230) -- Obsolete informational reference (is this intentional?): RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) -- Obsolete informational reference (is this intentional?): RFC 2818 (Obsoleted by RFC 9110) -- Obsolete informational reference (is this intentional?): RFC 2965 (Obsoleted by RFC 6265) -- Obsolete informational reference (is this intentional?): RFC 4288 (Obsoleted by RFC 6838) -- Obsolete informational reference (is this intentional?): RFC 4395 (Obsoleted by RFC 7595) -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 3 errors (**), 0 flaws (~~), 5 warnings (==), 15 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 Adobe 4 Obsoletes: 2145,2616 (if approved) J. Gettys 5 Updates: 2817 (if approved) Alcatel-Lucent 6 Intended status: Standards Track J. Mogul 7 Expires: January 12, 2012 HP 8 H. Frystyk 9 Microsoft 10 L. Masinter 11 Adobe 12 P. Leach 13 Microsoft 14 T. Berners-Lee 15 W3C/MIT 16 Y. Lafon, Ed. 17 W3C 18 J. Reschke, Ed. 19 greenbytes 20 July 11, 2011 22 HTTP/1.1, part 1: URIs, Connections, and Message Parsing 23 draft-ietf-httpbis-p1-messaging-15 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), which is archived at 42 . 44 The current issues list is at 45 and related 46 documents (including fancy diffs) can be found at 47 . 49 The changes in this draft are summarized in Appendix D.16. 51 Status of This Memo 53 This Internet-Draft is submitted in full conformance with the 54 provisions of BCP 78 and BCP 79. 56 Internet-Drafts are working documents of the Internet Engineering 57 Task Force (IETF). Note that other groups may also distribute 58 working documents as Internet-Drafts. The list of current Internet- 59 Drafts is at http://datatracker.ietf.org/drafts/current/. 61 Internet-Drafts are draft documents valid for a maximum of six months 62 and may be updated, replaced, or obsoleted by other documents at any 63 time. It is inappropriate to use Internet-Drafts as reference 64 material or to cite them other than as "work in progress." 66 This Internet-Draft will expire on January 12, 2012. 68 Copyright Notice 70 Copyright (c) 2011 IETF Trust and the persons identified as the 71 document authors. All rights reserved. 73 This document is subject to BCP 78 and the IETF Trust's Legal 74 Provisions Relating to IETF Documents 75 (http://trustee.ietf.org/license-info) in effect on the date of 76 publication of this document. Please review these documents 77 carefully, as they describe your rights and restrictions with respect 78 to this document. Code Components extracted from this document must 79 include Simplified BSD License text as described in Section 4.e of 80 the Trust Legal Provisions and are provided without warranty as 81 described in the Simplified BSD License. 83 This document may contain material from IETF Documents or IETF 84 Contributions published or made publicly available before November 85 10, 2008. The person(s) controlling the copyright in some of this 86 material may not have granted the IETF Trust the right to allow 87 modifications of such material outside the IETF Standards Process. 88 Without obtaining an adequate license from the person(s) controlling 89 the copyright in such materials, this document may not be modified 90 outside the IETF Standards Process, and derivative works of it may 91 not be created outside the IETF Standards Process, except to format 92 it for publication as an RFC or to translate it into languages other 93 than English. 95 Table of Contents 96 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6 97 1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 7 98 1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 7 99 1.2.1. ABNF Extension: #rule . . . . . . . . . . . . . . . . 7 100 1.2.2. Basic Rules . . . . . . . . . . . . . . . . . . . . . 8 101 2. HTTP-related architecture . . . . . . . . . . . . . . . . . . 10 102 2.1. Client/Server Messaging . . . . . . . . . . . . . . . . . 10 103 2.2. Message Orientation and Buffering . . . . . . . . . . . . 12 104 2.3. Connections and Transport Independence . . . . . . . . . . 12 105 2.4. Intermediaries . . . . . . . . . . . . . . . . . . . . . . 13 106 2.5. Caches . . . . . . . . . . . . . . . . . . . . . . . . . . 15 107 2.6. Protocol Versioning . . . . . . . . . . . . . . . . . . . 15 108 2.7. Uniform Resource Identifiers . . . . . . . . . . . . . . . 18 109 2.7.1. http URI scheme . . . . . . . . . . . . . . . . . . . 18 110 2.7.2. https URI scheme . . . . . . . . . . . . . . . . . . . 20 111 2.7.3. http and https URI Normalization and Comparison . . . 20 112 3. Message Format . . . . . . . . . . . . . . . . . . . . . . . . 21 113 3.1. Message Parsing Robustness . . . . . . . . . . . . . . . . 22 114 3.2. Header Fields . . . . . . . . . . . . . . . . . . . . . . 22 115 3.3. Message Body . . . . . . . . . . . . . . . . . . . . . . . 25 116 3.4. General Header Fields . . . . . . . . . . . . . . . . . . 28 117 4. Request . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 118 4.1. Request-Line . . . . . . . . . . . . . . . . . . . . . . . 29 119 4.1.1. Method . . . . . . . . . . . . . . . . . . . . . . . . 29 120 4.1.2. request-target . . . . . . . . . . . . . . . . . . . . 29 121 4.2. The Resource Identified by a Request . . . . . . . . . . . 31 122 4.3. Effective Request URI . . . . . . . . . . . . . . . . . . 32 123 5. Response . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 124 5.1. Status-Line . . . . . . . . . . . . . . . . . . . . . . . 33 125 5.1.1. Status Code and Reason Phrase . . . . . . . . . . . . 34 126 6. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 34 127 6.1. Date/Time Formats: Full Date . . . . . . . . . . . . . . . 34 128 6.2. Transfer Codings . . . . . . . . . . . . . . . . . . . . . 37 129 6.2.1. Chunked Transfer Coding . . . . . . . . . . . . . . . 38 130 6.2.2. Compression Codings . . . . . . . . . . . . . . . . . 40 131 6.2.3. Transfer Coding Registry . . . . . . . . . . . . . . . 41 132 6.3. Product Tokens . . . . . . . . . . . . . . . . . . . . . . 42 133 6.4. Quality Values . . . . . . . . . . . . . . . . . . . . . . 42 134 7. Connections . . . . . . . . . . . . . . . . . . . . . . . . . 42 135 7.1. Persistent Connections . . . . . . . . . . . . . . . . . . 43 136 7.1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . 43 137 7.1.2. Overall Operation . . . . . . . . . . . . . . . . . . 43 138 7.1.3. Proxy Servers . . . . . . . . . . . . . . . . . . . . 45 139 7.1.4. Practical Considerations . . . . . . . . . . . . . . . 47 140 7.2. Message Transmission Requirements . . . . . . . . . . . . 48 141 7.2.1. Persistent Connections and Flow Control . . . . . . . 48 142 7.2.2. Monitoring Connections for Error Status Messages . . . 49 143 7.2.3. Use of the 100 (Continue) Status . . . . . . . . . . . 49 144 7.2.4. Client Behavior if Server Prematurely Closes 145 Connection . . . . . . . . . . . . . . . . . . . . . . 51 146 8. Miscellaneous notes that might disappear . . . . . . . . . . . 52 147 8.1. Scheme aliases considered harmful . . . . . . . . . . . . 52 148 8.2. Use of HTTP for proxy communication . . . . . . . . . . . 52 149 8.3. Interception of HTTP for access control . . . . . . . . . 52 150 8.4. Use of HTTP by other protocols . . . . . . . . . . . . . . 52 151 8.5. Use of HTTP by media type specification . . . . . . . . . 52 152 9. Header Field Definitions . . . . . . . . . . . . . . . . . . . 52 153 9.1. Connection . . . . . . . . . . . . . . . . . . . . . . . . 52 154 9.2. Content-Length . . . . . . . . . . . . . . . . . . . . . . 54 155 9.3. Date . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 156 9.3.1. Clockless Origin Server Operation . . . . . . . . . . 55 157 9.4. Host . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 158 9.5. TE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 159 9.6. Trailer . . . . . . . . . . . . . . . . . . . . . . . . . 58 160 9.7. Transfer-Encoding . . . . . . . . . . . . . . . . . . . . 58 161 9.8. Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . 59 162 9.8.1. Upgrade Token Registry . . . . . . . . . . . . . . . . 60 163 9.9. Via . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 164 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 62 165 10.1. Header Field Registration . . . . . . . . . . . . . . . . 62 166 10.2. URI Scheme Registration . . . . . . . . . . . . . . . . . 63 167 10.3. Internet Media Type Registrations . . . . . . . . . . . . 63 168 10.3.1. Internet Media Type message/http . . . . . . . . . . . 63 169 10.3.2. Internet Media Type application/http . . . . . . . . . 64 170 10.4. Transfer Coding Registry . . . . . . . . . . . . . . . . . 65 171 10.5. Upgrade Token Registration . . . . . . . . . . . . . . . . 66 172 11. Security Considerations . . . . . . . . . . . . . . . . . . . 66 173 11.1. Personal Information . . . . . . . . . . . . . . . . . . . 66 174 11.2. Abuse of Server Log Information . . . . . . . . . . . . . 67 175 11.3. Attacks Based On File and Path Names . . . . . . . . . . . 67 176 11.4. DNS Spoofing . . . . . . . . . . . . . . . . . . . . . . . 67 177 11.5. Proxies and Caching . . . . . . . . . . . . . . . . . . . 68 178 11.6. Protocol Element Size Overflows . . . . . . . . . . . . . 69 179 11.7. Denial of Service Attacks on Proxies . . . . . . . . . . . 69 180 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 69 181 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 70 182 13.1. Normative References . . . . . . . . . . . . . . . . . . . 70 183 13.2. Informative References . . . . . . . . . . . . . . . . . . 72 184 Appendix A. Tolerant Applications . . . . . . . . . . . . . . . . 74 185 Appendix B. HTTP Version History . . . . . . . . . . . . . . . . 75 186 B.1. Changes from HTTP/1.0 . . . . . . . . . . . . . . . . . . 76 187 B.1.1. Multi-homed Web Servers . . . . . . . . . . . . . . . 76 188 B.1.2. Keep-Alive Connections . . . . . . . . . . . . . . . . 76 189 B.2. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 77 190 Appendix C. Collected ABNF . . . . . . . . . . . . . . . . . . . 78 191 Appendix D. Change Log (to be removed by RFC Editor before 192 publication) . . . . . . . . . . . . . . . . . . . . 82 193 D.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 82 194 D.2. Since draft-ietf-httpbis-p1-messaging-00 . . . . . . . . . 82 195 D.3. Since draft-ietf-httpbis-p1-messaging-01 . . . . . . . . . 84 196 D.4. Since draft-ietf-httpbis-p1-messaging-02 . . . . . . . . . 85 197 D.5. Since draft-ietf-httpbis-p1-messaging-03 . . . . . . . . . 85 198 D.6. Since draft-ietf-httpbis-p1-messaging-04 . . . . . . . . . 86 199 D.7. Since draft-ietf-httpbis-p1-messaging-05 . . . . . . . . . 86 200 D.8. Since draft-ietf-httpbis-p1-messaging-06 . . . . . . . . . 87 201 D.9. Since draft-ietf-httpbis-p1-messaging-07 . . . . . . . . . 88 202 D.10. Since draft-ietf-httpbis-p1-messaging-08 . . . . . . . . . 88 203 D.11. Since draft-ietf-httpbis-p1-messaging-09 . . . . . . . . . 89 204 D.12. Since draft-ietf-httpbis-p1-messaging-10 . . . . . . . . . 89 205 D.13. Since draft-ietf-httpbis-p1-messaging-11 . . . . . . . . . 90 206 D.14. Since draft-ietf-httpbis-p1-messaging-12 . . . . . . . . . 90 207 D.15. Since draft-ietf-httpbis-p1-messaging-13 . . . . . . . . . 91 208 D.16. Since draft-ietf-httpbis-p1-messaging-14 . . . . . . . . . 91 209 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 211 1. Introduction 213 The Hypertext Transfer Protocol (HTTP) is an application-level 214 request/response protocol that uses extensible semantics and MIME- 215 like message payloads for flexible interaction with network-based 216 hypertext information systems. HTTP relies upon the Uniform Resource 217 Identifier (URI) standard [RFC3986] to indicate the target resource 218 and relationships between resources. Messages are passed in a format 219 similar to that used by Internet mail [RFC5322] and the Multipurpose 220 Internet Mail Extensions (MIME) [RFC2045] (see Appendix A of [Part3] 221 for the differences between HTTP and MIME messages). 223 HTTP is a generic interface protocol for information systems. It is 224 designed to hide the details of how a service is implemented by 225 presenting a uniform interface to clients that is independent of the 226 types of resources provided. Likewise, servers do not need to be 227 aware of each client's purpose: an HTTP request can be considered in 228 isolation rather than being associated with a specific type of client 229 or a predetermined sequence of application steps. The result is a 230 protocol that can be used effectively in many different contexts and 231 for which implementations can evolve independently over time. 233 HTTP is also designed for use as an intermediation protocol for 234 translating communication to and from non-HTTP information systems. 235 HTTP proxies and gateways can provide access to alternative 236 information services by translating their diverse protocols into a 237 hypertext format that can be viewed and manipulated by clients in the 238 same way as HTTP services. 240 One consequence of HTTP flexibility is that the protocol cannot be 241 defined in terms of what occurs behind the interface. Instead, we 242 are limited to defining the syntax of communication, the intent of 243 received communication, and the expected behavior of recipients. If 244 the communication is considered in isolation, then successful actions 245 ought to be reflected in corresponding changes to the observable 246 interface provided by servers. However, since multiple clients might 247 act in parallel and perhaps at cross-purposes, we cannot require that 248 such changes be observable beyond the scope of a single response. 250 This document is Part 1 of the seven-part specification of HTTP, 251 defining the protocol referred to as "HTTP/1.1", obsoleting [RFC2616] 252 and [RFC2145]. Part 1 describes the architectural elements that are 253 used or referred to in HTTP, defines the "http" and "https" URI 254 schemes, describes overall network operation and connection 255 management, and defines HTTP message framing and forwarding 256 requirements. Our goal is to define all of the mechanisms necessary 257 for HTTP message handling that are independent of message semantics, 258 thereby defining the complete set of requirements for message parsers 259 and message-forwarding intermediaries. 261 1.1. Requirements 263 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 264 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 265 document are to be interpreted as described in [RFC2119]. 267 An implementation is not compliant if it fails to satisfy one or more 268 of the "MUST" or "REQUIRED" level requirements for the protocols it 269 implements. An implementation that satisfies all the "MUST" or 270 "REQUIRED" level and all the "SHOULD" level requirements for its 271 protocols is said to be "unconditionally compliant"; one that 272 satisfies all the "MUST" level requirements but not all the "SHOULD" 273 level requirements for its protocols is said to be "conditionally 274 compliant". 276 1.2. Syntax Notation 278 This specification uses the Augmented Backus-Naur Form (ABNF) 279 notation of [RFC5234]. 281 The following core rules are included by reference, as defined in 282 [RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF 283 (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote), 284 HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any 8-bit 285 sequence of data), SP (space), VCHAR (any visible [USASCII] 286 character), and WSP (whitespace). 288 As a syntactic convention, ABNF rule names prefixed with "obs-" 289 denote "obsolete" grammar rules that appear for historical reasons. 291 1.2.1. ABNF Extension: #rule 293 The #rule extension to the ABNF rules of [RFC5234] is used to improve 294 readability. 296 A construct "#" is defined, similar to "*", for defining comma- 297 delimited lists of elements. The full form is "#element" 298 indicating at least and at most elements, each separated by a 299 single comma (",") and optional whitespace (OWS, Section 1.2.2). 301 Thus, 303 1#element => element *( OWS "," OWS element ) 305 and: 307 #element => [ 1#element ] 309 and for n >= 1 and m > 1: 311 #element => element *( OWS "," OWS element ) 313 For compatibility with legacy list rules, recipients SHOULD accept 314 empty list elements. In other words, consumers would follow the list 315 productions: 317 #element => [ ( "," / element ) *( OWS "," [ OWS element ] ) ] 319 1#element => *( "," OWS ) element *( OWS "," [ OWS element ] ) 321 Note that empty elements do not contribute to the count of elements 322 present, though. 324 For example, given these ABNF productions: 326 example-list = 1#example-list-elmt 327 example-list-elmt = token ; see Section 1.2.2 329 Then these are valid values for example-list (not including the 330 double quotes, which are present for delimitation only): 332 "foo,bar" 333 " foo ,bar," 334 " foo , ,bar,charlie " 335 "foo ,bar, charlie " 337 But these values would be invalid, as at least one non-empty element 338 is required: 340 "" 341 "," 342 ", ," 344 Appendix C shows the collected ABNF, with the list rules expanded as 345 explained above. 347 1.2.2. Basic Rules 349 HTTP/1.1 defines the sequence CR LF as the end-of-line marker for all 350 protocol elements other than the message-body (see Appendix A for 351 tolerant applications). 353 This specification uses three rules to denote the use of linear 354 whitespace: OWS (optional whitespace), RWS (required whitespace), and 355 BWS ("bad" whitespace). 357 The OWS rule is used where zero or more linear whitespace octets 358 might appear. OWS SHOULD either not be produced or be produced as a 359 single SP. Multiple OWS octets that occur within field-content 360 SHOULD be replaced with a single SP before interpreting the field 361 value or forwarding the message downstream. 363 RWS is used when at least one linear whitespace octet is required to 364 separate field tokens. RWS SHOULD be produced as a single SP. 365 Multiple RWS octets that occur within field-content SHOULD be 366 replaced with a single SP before interpreting the field value or 367 forwarding the message downstream. 369 BWS is used where the grammar allows optional whitespace for 370 historical reasons but senders SHOULD NOT produce it in messages. 371 HTTP/1.1 recipients MUST accept such bad optional whitespace and 372 remove it before interpreting the field value or forwarding the 373 message downstream. 375 OWS = *( [ obs-fold ] WSP ) 376 ; "optional" whitespace 377 RWS = 1*( [ obs-fold ] WSP ) 378 ; "required" whitespace 379 BWS = OWS 380 ; "bad" whitespace 381 obs-fold = CRLF 382 ; see Section 3.2 384 Many HTTP/1.1 header field values consist of words (token or quoted- 385 string) separated by whitespace or special characters. These special 386 characters MUST be in a quoted string to be used within a parameter 387 value (as defined in Section 6.2). 389 word = token / quoted-string 391 token = 1*tchar 393 tchar = "!" / "#" / "$" / "%" / "&" / "'" / "*" 394 / "+" / "-" / "." / "^" / "_" / "`" / "|" / "~" 395 / DIGIT / ALPHA 396 ; any VCHAR, except special 398 special = "(" / ")" / "<" / ">" / "@" / "," 399 / ";" / ":" / "\" / DQUOTE / "/" / "[" 400 / "]" / "?" / "=" / "{" / "}" 402 A string of text is parsed as a single word if it is quoted using 403 double-quote marks. 405 quoted-string = DQUOTE *( qdtext / quoted-pair ) DQUOTE 406 qdtext = OWS / %x21 / %x23-5B / %x5D-7E / obs-text 407 ; OWS / / obs-text 408 obs-text = %x80-FF 410 The backslash octet ("\") can be used as a single-octet quoting 411 mechanism within quoted-string constructs: 413 quoted-pair = "\" ( WSP / VCHAR / obs-text ) 415 Senders SHOULD NOT escape octets that do not require escaping (i.e., 416 other than DQUOTE and the backslash octet). 418 2. HTTP-related architecture 420 HTTP was created for the World Wide Web architecture and has evolved 421 over time to support the scalability needs of a worldwide hypertext 422 system. Much of that architecture is reflected in the terminology 423 and syntax productions used to define HTTP. 425 2.1. Client/Server Messaging 427 HTTP is a stateless request/response protocol that operates by 428 exchanging messages across a reliable transport or session-layer 429 "connection". An HTTP "client" is a program that establishes a 430 connection to a server for the purpose of sending one or more HTTP 431 requests. An HTTP "server" is a program that accepts connections in 432 order to service HTTP requests by sending HTTP responses. 434 Note that the terms client and server refer only to the roles that 435 these programs perform for a particular connection. The same program 436 might act as a client on some connections and a server on others. We 437 use the term "user agent" to refer to the program that initiates a 438 request, such as a WWW browser, editor, or spider (web-traversing 439 robot), and the term "origin server" to refer to the program that can 440 originate authoritative responses to a request. For general 441 requirements, we use the term "sender" to refer to whichever 442 component sent a given message and the term "recipient" to refer to 443 any component that receives the message. 445 Most HTTP communication consists of a retrieval request (GET) for a 446 representation of some resource identified by a URI. In the simplest 447 case, this might be accomplished via a single bidirectional 448 connection (===) between the user agent (UA) and the origin server 449 (O). 451 request > 452 UA ======================================= O 453 < response 455 A client sends an HTTP request to the server in the form of a request 456 message (Section 4), beginning with a method, URI, and protocol 457 version, followed by MIME-like header fields containing request 458 modifiers, client information, and payload metadata, an empty line to 459 indicate the end of the header section, and finally the payload body 460 (if any). 462 A server responds to the client's request by sending an HTTP response 463 message (Section 5), beginning with a status line that includes the 464 protocol version, a success or error code, and textual reason phrase, 465 followed by MIME-like header fields containing server information, 466 resource metadata, and payload metadata, an empty line to indicate 467 the end of the header section, and finally the payload body (if any). 469 The following example illustrates a typical message exchange for a 470 GET request on the URI "http://www.example.com/hello.txt": 472 client request: 474 GET /hello.txt HTTP/1.1 475 User-Agent: curl/7.16.3 libcurl/7.16.3 OpenSSL/0.9.7l zlib/1.2.3 476 Host: www.example.com 477 Accept: */* 479 server response: 481 HTTP/1.1 200 OK 482 Date: Mon, 27 Jul 2009 12:28:53 GMT 483 Server: Apache 484 Last-Modified: Wed, 22 Jul 2009 19:15:56 GMT 485 ETag: "34aa387-d-1568eb00" 486 Accept-Ranges: bytes 487 Content-Length: 14 488 Vary: Accept-Encoding 489 Content-Type: text/plain 491 Hello World! 493 2.2. Message Orientation and Buffering 495 Fundamentally, HTTP is a message-based protocol. Although message 496 bodies can be chunked (Section 6.2.1) and implementations often make 497 parts of a message available progressively, this is not required, and 498 some widely-used implementations only make a message available when 499 it is complete. Furthermore, while most proxies will progressively 500 stream messages, some amount of buffering will take place, and some 501 proxies might buffer messages to perform transformations, check 502 content or provide other services. 504 Therefore, extensions to and uses of HTTP cannot rely on the 505 availability of a partial message, or assume that messages will not 506 be buffered. There are strategies that can be used to test for 507 buffering in a given connection, but it should be understood that 508 behaviors can differ across connections, and between requests and 509 responses. 511 Recipients MUST consider every message in a connection in isolation; 512 because HTTP is a stateless protocol, it cannot be assumed that two 513 requests on the same connection are from the same client or share any 514 other common attributes. In particular, intermediaries might mix 515 requests from different clients into a single server connection. 516 Note that some existing HTTP extensions (e.g., [RFC4559]) violate 517 this requirement, thereby potentially causing interoperability and 518 security problems. 520 2.3. Connections and Transport Independence 522 HTTP messaging is independent of the underlying transport or session- 523 layer connection protocol(s). HTTP only presumes a reliable 524 transport with in-order delivery of requests and the corresponding 525 in-order delivery of responses. The mapping of HTTP request and 526 response structures onto the data units of the underlying transport 527 protocol is outside the scope of this specification. 529 The specific connection protocols to be used for an interaction are 530 determined by client configuration and the target resource's URI. 531 For example, the "http" URI scheme (Section 2.7.1) indicates a 532 default connection of TCP over IP, with a default TCP port of 80, but 533 the client might be configured to use a proxy via some other 534 connection port or protocol instead of using the defaults. 536 A connection might be used for multiple HTTP request/response 537 exchanges, as defined in Section 7.1. 539 2.4. Intermediaries 541 HTTP enables the use of intermediaries to satisfy requests through a 542 chain of connections. There are three common forms of HTTP 543 intermediary: proxy, gateway, and tunnel. In some cases, a single 544 intermediary might act as an origin server, proxy, gateway, or 545 tunnel, switching behavior based on the nature of each request. 547 > > > > 548 UA =========== A =========== B =========== C =========== O 549 < < < < 551 The figure above shows three intermediaries (A, B, and C) between the 552 user agent and origin server. A request or response message that 553 travels the whole chain will pass through four separate connections. 554 Some HTTP communication options might apply only to the connection 555 with the nearest, non-tunnel neighbor, only to the end-points of the 556 chain, or to all connections along the chain. Although the diagram 557 is linear, each participant might be engaged in multiple, 558 simultaneous communications. For example, B might be receiving 559 requests from many clients other than A, and/or forwarding requests 560 to servers other than C, at the same time that it is handling A's 561 request. 563 We use the terms "upstream" and "downstream" to describe various 564 requirements in relation to the directional flow of a message: all 565 messages flow from upstream to downstream. Likewise, we use the 566 terms inbound and outbound to refer to directions in relation to the 567 request path: "inbound" means toward the origin server and "outbound" 568 means toward the user agent. 570 A "proxy" is a message forwarding agent that is selected by the 571 client, usually via local configuration rules, to receive requests 572 for some type(s) of absolute URI and attempt to satisfy those 573 requests via translation through the HTTP interface. Some 574 translations are minimal, such as for proxy requests for "http" URIs, 575 whereas other requests might require translation to and from entirely 576 different application-layer protocols. Proxies are often used to 577 group an organization's HTTP requests through a common intermediary 578 for the sake of security, annotation services, or shared caching. 580 An HTTP-to-HTTP proxy is called a "transforming proxy" if it is 581 designed or configured to modify request or response messages in a 582 semantically meaningful way (i.e., modifications, beyond those 583 required by normal HTTP processing, that change the message in a way 584 that would be significant to the original sender or potentially 585 significant to downstream recipients). For example, a transforming 586 proxy might be acting as a shared annotation server (modifying 587 responses to include references to a local annotation database), a 588 malware filter, a format transcoder, or an intranet-to-Internet 589 privacy filter. Such transformations are presumed to be desired by 590 the client (or client organization) that selected the proxy and are 591 beyond the scope of this specification. However, when a proxy is not 592 intended to transform a given message, we use the term "non- 593 transforming proxy" to target requirements that preserve HTTP message 594 semantics. See Section 8.2.4 of [Part2] and Section 3.6 of [Part6] 595 for status and warning codes related to transformations. 597 A "gateway" (a.k.a., "reverse proxy") is a receiving agent that acts 598 as a layer above some other server(s) and translates the received 599 requests to the underlying server's protocol. Gateways are often 600 used to encapsulate legacy or untrusted information services, to 601 improve server performance through "accelerator" caching, and to 602 enable partitioning or load-balancing of HTTP services across 603 multiple machines. 605 A gateway behaves as an origin server on its outbound connection and 606 as a user agent on its inbound connection. All HTTP requirements 607 applicable to an origin server also apply to the outbound 608 communication of a gateway. A gateway communicates with inbound 609 servers using any protocol that it desires, including private 610 extensions to HTTP that are outside the scope of this specification. 611 However, an HTTP-to-HTTP gateway that wishes to interoperate with 612 third-party HTTP servers MUST comply with HTTP user agent 613 requirements on the gateway's inbound connection and MUST implement 614 the Connection (Section 9.1) and Via (Section 9.9) header fields for 615 both connections. 617 A "tunnel" acts as a blind relay between two connections without 618 changing the messages. Once active, a tunnel is not considered a 619 party to the HTTP communication, though the tunnel might have been 620 initiated by an HTTP request. A tunnel ceases to exist when both 621 ends of the relayed connection are closed. Tunnels are used to 622 extend a virtual connection through an intermediary, such as when 623 transport-layer security is used to establish private communication 624 through a shared firewall proxy. 626 In addition, there may exist network intermediaries that are not 627 considered part of the HTTP communication but nevertheless act as 628 filters or redirecting agents (usually violating HTTP semantics, 629 causing security problems, and otherwise making a mess of things). 630 Such a network intermediary, often referred to as an "interception 631 proxy" [RFC3040], "transparent proxy" [RFC1919], or "captive portal", 632 differs from an HTTP proxy because it has not been selected by the 633 client. Instead, the network intermediary redirects outgoing TCP 634 port 80 packets (and occasionally other common port traffic) to an 635 internal HTTP server. Interception proxies are commonly found on 636 public network access points, as a means of enforcing account 637 subscription prior to allowing use of non-local Internet services, 638 and within corporate firewalls to enforce network usage policies. 639 They are indistinguishable from a man-in-the-middle attack. 641 2.5. Caches 643 A "cache" is a local store of previous response messages and the 644 subsystem that controls its message storage, retrieval, and deletion. 645 A cache stores cacheable responses in order to reduce the response 646 time and network bandwidth consumption on future, equivalent 647 requests. Any client or server MAY employ a cache, though a cache 648 cannot be used by a server while it is acting as a tunnel. 650 The effect of a cache is that the request/response chain is shortened 651 if one of the participants along the chain has a cached response 652 applicable to that request. The following illustrates the resulting 653 chain if B has a cached copy of an earlier response from O (via C) 654 for a request which has not been cached by UA or A. 656 > > 657 UA =========== A =========== B - - - - - - C - - - - - - O 658 < < 660 A response is "cacheable" if a cache is allowed to store a copy of 661 the response message for use in answering subsequent requests. Even 662 when a response is cacheable, there might be additional constraints 663 placed by the client or by the origin server on when that cached 664 response can be used for a particular request. HTTP requirements for 665 cache behavior and cacheable responses are defined in Section 2 of 666 [Part6]. 668 There are a wide variety of architectures and configurations of 669 caches and proxies deployed across the World Wide Web and inside 670 large organizations. These systems include national hierarchies of 671 proxy caches to save transoceanic bandwidth, systems that broadcast 672 or multicast cache entries, organizations that distribute subsets of 673 cached data via optical media, and so on. 675 2.6. Protocol Versioning 677 HTTP uses a "." numbering scheme to indicate versions 678 of the protocol. This specification defines version "1.1". The 679 protocol version as a whole indicates the sender's compliance with 680 the set of requirements laid out in that version's corresponding 681 specification of HTTP. 683 The version of an HTTP message is indicated by an HTTP-Version field 684 in the first line of the message. HTTP-Version is case-sensitive. 686 HTTP-Version = HTTP-Prot-Name "/" DIGIT "." DIGIT 687 HTTP-Prot-Name = %x48.54.54.50 ; "HTTP", case-sensitive 689 The HTTP version number consists of two decimal digits separated by a 690 "." (period or decimal point). The first digit ("major version") 691 indicates the HTTP messaging syntax, whereas the second digit ("minor 692 version") indicates the highest minor version to which the sender is 693 at least conditionally compliant and able to understand for future 694 communication. The minor version advertises the sender's 695 communication capabilities even when the sender is only using a 696 backwards-compatible subset of the protocol, thereby letting the 697 recipient know that more advanced features can be used in response 698 (by servers) or in future requests (by clients). 700 When an HTTP/1.1 message is sent to an HTTP/1.0 recipient [RFC1945] 701 or a recipient whose version is unknown, the HTTP/1.1 message is 702 constructed such that it can be interpreted as a valid HTTP/1.0 703 message if all of the newer features are ignored. This specification 704 places recipient-version requirements on some new features so that a 705 compliant sender will only use compatible features until it has 706 determined, through configuration or the receipt of a message, that 707 the recipient supports HTTP/1.1. 709 The interpretation of an HTTP header field does not change between 710 minor versions of the same major version, though the default behavior 711 of a recipient in the absence of such a field can change. Unless 712 specified otherwise, header fields defined in HTTP/1.1 are defined 713 for all versions of HTTP/1.x. In particular, the Host and Connection 714 header fields ought to be implemented by all HTTP/1.x implementations 715 whether or not they advertise compliance with HTTP/1.1. 717 New header fields can be defined such that, when they are understood 718 by a recipient, they might override or enhance the interpretation of 719 previously defined header fields. When an implementation receives an 720 unrecognized header field, the recipient MUST ignore that header 721 field for local processing regardless of the message's HTTP version. 722 An unrecognized header field received by a proxy MUST be forwarded 723 downstream unless the header field's field-name is listed in the 724 message's Connection header-field (see Section 9.1). These 725 requirements allow HTTP's functionality to be enhanced without 726 requiring prior update of all compliant intermediaries. 728 Intermediaries that process HTTP messages (i.e., all intermediaries 729 other than those acting as a tunnel) MUST send their own HTTP-Version 730 in forwarded messages. In other words, they MUST NOT blindly forward 731 the first line of an HTTP message without ensuring that the protocol 732 version matches what the intermediary understands, and is at least 733 conditionally compliant to, for both the receiving and sending of 734 messages. Forwarding an HTTP message without rewriting the HTTP- 735 Version might result in communication errors when downstream 736 recipients use the message sender's version to determine what 737 features are safe to use for later communication with that sender. 739 An HTTP client SHOULD send a request version equal to the highest 740 version for which the client is at least conditionally compliant and 741 whose major version is no higher than the highest version supported 742 by the server, if this is known. An HTTP client MUST NOT send a 743 version for which it is not at least conditionally compliant. 745 An HTTP client MAY send a lower request version if it is known that 746 the server incorrectly implements the HTTP specification, but only 747 after the client has attempted at least one normal request and 748 determined from the response status or header fields (e.g., Server) 749 that the server improperly handles higher request versions. 751 An HTTP server SHOULD send a response version equal to the highest 752 version for which the server is at least conditionally compliant and 753 whose major version is less than or equal to the one received in the 754 request. An HTTP server MUST NOT send a version for which it is not 755 at least conditionally compliant. A server MAY send a 505 (HTTP 756 Version Not Supported) response if it cannot send a response using 757 the major version used in the client's request. 759 An HTTP server MAY send an HTTP/1.0 response to an HTTP/1.0 request 760 if it is known or suspected that the client incorrectly implements 761 the HTTP specification and is incapable of correctly processing later 762 version responses, such as when a client fails to parse the version 763 number correctly or when an intermediary is known to blindly forward 764 the HTTP-Version even when it doesn't comply with the given minor 765 version of the protocol. Such protocol downgrades SHOULD NOT be 766 performed unless triggered by specific client attributes, such as 767 when one or more of the request header fields (e.g., User-Agent) 768 uniquely match the values sent by a client known to be in error. 770 The intention of HTTP's versioning design is that the major number 771 will only be incremented if an incompatible message syntax is 772 introduced, and that the minor number will only be incremented when 773 changes made to the protocol have the effect of adding to the message 774 semantics or implying additional capabilities of the sender. 775 However, the minor version was not incremented for the changes 776 introduced between [RFC2068] and [RFC2616], and this revision is 777 specifically avoiding any such changes to the protocol. 779 2.7. Uniform Resource Identifiers 781 Uniform Resource Identifiers (URIs) [RFC3986] are used throughout 782 HTTP as the means for identifying resources. URI references are used 783 to target requests, indicate redirects, and define relationships. 784 HTTP does not limit what a resource might be; it merely defines an 785 interface that can be used to interact with a resource via HTTP. 786 More information on the scope of URIs and resources can be found in 787 [RFC3986]. 789 This specification adopts the definitions of "URI-reference", 790 "absolute-URI", "relative-part", "port", "host", "path-abempty", 791 "path-absolute", "query", and "authority" from the URI generic syntax 792 [RFC3986]. In addition, we define a partial-URI rule for protocol 793 elements that allow a relative URI but not a fragment. 795 URI-reference = 796 absolute-URI = 797 relative-part = 798 authority = 799 path-abempty = 800 path-absolute = 801 port = 802 query = 803 uri-host = 805 partial-URI = relative-part [ "?" query ] 807 Each protocol element in HTTP that allows a URI reference will 808 indicate in its ABNF production whether the element allows any form 809 of reference (URI-reference), only a URI in absolute form (absolute- 810 URI), only the path and optional query components, or some 811 combination of the above. Unless otherwise indicated, URI references 812 are parsed relative to the effective request URI, which defines the 813 default base URI for references in both the request and its 814 corresponding response. 816 2.7.1. http URI scheme 818 The "http" URI scheme is hereby defined for the purpose of minting 819 identifiers according to their association with the hierarchical 820 namespace governed by a potential HTTP origin server listening for 821 TCP connections on a given port. 823 http-URI = "http:" "//" authority path-abempty [ "?" query ] 825 The HTTP origin server is identified by the generic syntax's 826 authority component, which includes a host identifier and optional 827 TCP port ([RFC3986], Section 3.2.2). The remainder of the URI, 828 consisting of both the hierarchical path component and optional query 829 component, serves as an identifier for a potential resource within 830 that origin server's name space. 832 If the host identifier is provided as an IP literal or IPv4 address, 833 then the origin server is any listener on the indicated TCP port at 834 that IP address. If host is a registered name, then that name is 835 considered an indirect identifier and the recipient might use a name 836 resolution service, such as DNS, to find the address of a listener 837 for that host. The host MUST NOT be empty; if an "http" URI is 838 received with an empty host, then it MUST be rejected as invalid. If 839 the port subcomponent is empty or not given, then TCP port 80 is 840 assumed (the default reserved port for WWW services). 842 Regardless of the form of host identifier, access to that host is not 843 implied by the mere presence of its name or address. The host might 844 or might not exist and, even when it does exist, might or might not 845 be running an HTTP server or listening to the indicated port. The 846 "http" URI scheme makes use of the delegated nature of Internet names 847 and addresses to establish a naming authority (whatever entity has 848 the ability to place an HTTP server at that Internet name or address) 849 and allows that authority to determine which names are valid and how 850 they might be used. 852 When an "http" URI is used within a context that calls for access to 853 the indicated resource, a client MAY attempt access by resolving the 854 host to an IP address, establishing a TCP connection to that address 855 on the indicated port, and sending an HTTP request message to the 856 server containing the URI's identifying data as described in 857 Section 4. If the server responds to that request with a non-interim 858 HTTP response message, as described in Section 5, then that response 859 is considered an authoritative answer to the client's request. 861 Although HTTP is independent of the transport protocol, the "http" 862 scheme is specific to TCP-based services because the name delegation 863 process depends on TCP for establishing authority. An HTTP service 864 based on some other underlying connection protocol would presumably 865 be identified using a different URI scheme, just as the "https" 866 scheme (below) is used for servers that require an SSL/TLS transport 867 layer on a connection. Other protocols might also be used to provide 868 access to "http" identified resources -- it is only the authoritative 869 interface used for mapping the namespace that is specific to TCP. 871 The URI generic syntax for authority also includes a deprecated 872 userinfo subcomponent ([RFC3986], Section 3.2.1) for including user 873 authentication information in the URI. Some implementations make use 874 of the userinfo component for internal configuration of 875 authentication information, such as within command invocation 876 options, configuration files, or bookmark lists, even though such 877 usage might expose a user identifier or password. Senders MUST NOT 878 include a userinfo subcomponent (and its "@" delimiter) when 879 transmitting an "http" URI in a message. Recipients of HTTP messages 880 that contain a URI reference SHOULD parse for the existence of 881 userinfo and treat its presence as an error, likely indicating that 882 the deprecated subcomponent is being used to obscure the authority 883 for the sake of phishing attacks. 885 2.7.2. https URI scheme 887 The "https" URI scheme is hereby defined for the purpose of minting 888 identifiers according to their association with the hierarchical 889 namespace governed by a potential HTTP origin server listening for 890 SSL/TLS-secured connections on a given TCP port. 892 All of the requirements listed above for the "http" scheme are also 893 requirements for the "https" scheme, except that a default TCP port 894 of 443 is assumed if the port subcomponent is empty or not given, and 895 the TCP connection MUST be secured for privacy through the use of 896 strong encryption prior to sending the first HTTP request. 898 https-URI = "https:" "//" authority path-abempty [ "?" query ] 900 Unlike the "http" scheme, responses to "https" identified requests 901 are never "public" and thus MUST NOT be reused for shared caching. 902 They can, however, be reused in a private cache if the message is 903 cacheable by default in HTTP or specifically indicated as such by the 904 Cache-Control header field (Section 3.2 of [Part6]). 906 Resources made available via the "https" scheme have no shared 907 identity with the "http" scheme even if their resource identifiers 908 indicate the same authority (the same host listening to the same TCP 909 port). They are distinct name spaces and are considered to be 910 distinct origin servers. However, an extension to HTTP that is 911 defined to apply to entire host domains, such as the Cookie protocol 912 [RFC6265], can allow information set by one service to impact 913 communication with other services within a matching group of host 914 domains. 916 The process for authoritative access to an "https" identified 917 resource is defined in [RFC2818]. 919 2.7.3. http and https URI Normalization and Comparison 921 Since the "http" and "https" schemes conform to the URI generic 922 syntax, such URIs are normalized and compared according to the 923 algorithm defined in [RFC3986], Section 6, using the defaults 924 described above for each scheme. 926 If the port is equal to the default port for a scheme, the normal 927 form is to elide the port subcomponent. Likewise, an empty path 928 component is equivalent to an absolute path of "/", so the normal 929 form is to provide a path of "/" instead. The scheme and host are 930 case-insensitive and normally provided in lowercase; all other 931 components are compared in a case-sensitive manner. Characters other 932 than those in the "reserved" set are equivalent to their percent- 933 encoded octets (see [RFC3986], Section 2.1): the normal form is to 934 not encode them. 936 For example, the following three URIs are equivalent: 938 http://example.com:80/~smith/home.html 939 http://EXAMPLE.com/%7Esmith/home.html 940 http://EXAMPLE.com:/%7esmith/home.html 942 3. Message Format 944 All HTTP/1.1 messages consist of a start-line followed by a sequence 945 of octets in a format similar to the Internet Message Format 946 [RFC5322]: zero or more header fields (collectively referred to as 947 the "headers" or the "header section"), an empty line indicating the 948 end of the header section, and an optional message-body. 950 An HTTP message can either be a request from client to server or a 951 response from server to client. Syntactically, the two types of 952 message differ only in the start-line, which is either a Request-Line 953 (for requests) or a Status-Line (for responses), and in the algorithm 954 for determining the length of the message-body (Section 3.3). In 955 theory, a client could receive requests and a server could receive 956 responses, distinguishing them by their different start-line formats, 957 but in practice servers are implemented to only expect a request (a 958 response is interpreted as an unknown or invalid request method) and 959 clients are implemented to only expect a response. 961 HTTP-message = start-line 962 *( header-field CRLF ) 963 CRLF 964 [ message-body ] 965 start-line = Request-Line / Status-Line 967 Implementations MUST NOT send whitespace between the start-line and 968 the first header field. The presence of such whitespace in a request 969 might be an attempt to trick a server into ignoring that field or 970 processing the line after it as a new request, either of which might 971 result in a security vulnerability if other implementations within 972 the request chain interpret the same message differently. Likewise, 973 the presence of such whitespace in a response might be ignored by 974 some clients or cause others to cease parsing. 976 3.1. Message Parsing Robustness 978 In the interest of robustness, servers SHOULD ignore at least one 979 empty line received where a Request-Line is expected. In other 980 words, if the server is reading the protocol stream at the beginning 981 of a message and receives a CRLF first, it SHOULD ignore the CRLF. 983 Some old HTTP/1.0 client implementations send an extra CRLF after a 984 POST request as a lame workaround for some early server applications 985 that failed to read message-body content that was not terminated by a 986 line-ending. An HTTP/1.1 client MUST NOT preface or follow a request 987 with an extra CRLF. If terminating the request message-body with a 988 line-ending is desired, then the client MUST include the terminating 989 CRLF octets as part of the message-body length. 991 When a server listening only for HTTP request messages, or processing 992 what appears from the start-line to be an HTTP request message, 993 receives a sequence of octets that does not match the HTTP-message 994 grammar aside from the robustness exceptions listed above, the server 995 MUST respond with an HTTP/1.1 400 (Bad Request) response. 997 The normal procedure for parsing an HTTP message is to read the 998 start-line into a structure, read each header field into a hash table 999 by field name until the empty line, and then use the parsed data to 1000 determine if a message-body is expected. If a message-body has been 1001 indicated, then it is read as a stream until an amount of octets 1002 equal to the message-body length is read or the connection is closed. 1003 Care must be taken to parse an HTTP message as a sequence of octets 1004 in an encoding that is a superset of US-ASCII. Attempting to parse 1005 HTTP as a stream of Unicode characters in a character encoding like 1006 UTF-16 might introduce security flaws due to the differing ways that 1007 such parsers interpret invalid characters. 1009 HTTP allows the set of defined header fields to be extended without 1010 changing the protocol version (see Section 10.1). Unrecognized 1011 header fields MUST be forwarded by a proxy unless the proxy is 1012 specifically configured to block or otherwise transform such fields. 1013 Unrecognized header fields SHOULD be ignored by other recipients. 1015 3.2. Header Fields 1017 Each HTTP header field consists of a case-insensitive field name 1018 followed by a colon (":"), optional whitespace, and the field value. 1020 header-field = field-name ":" OWS [ field-value ] OWS 1021 field-name = token 1022 field-value = *( field-content / OWS ) 1023 field-content = *( WSP / VCHAR / obs-text ) 1025 No whitespace is allowed between the header field name and colon. 1026 For security reasons, any request message received containing such 1027 whitespace MUST be rejected with a response code of 400 (Bad 1028 Request). A proxy MUST remove any such whitespace from a response 1029 message before forwarding the message downstream. 1031 A field value MAY be preceded by optional whitespace (OWS); a single 1032 SP is preferred. The field value does not include any leading or 1033 trailing white space: OWS occurring before the first non-whitespace 1034 octet of the field value or after the last non-whitespace octet of 1035 the field value is ignored and SHOULD be removed before further 1036 processing (as this does not change the meaning of the header field). 1038 The order in which header fields with differing field names are 1039 received is not significant. However, it is "good practice" to send 1040 header fields that contain control data first, such as Host on 1041 requests and Date on responses, so that implementations can decide 1042 when not to handle a message as early as possible. A server MUST 1043 wait until the entire header section is received before interpreting 1044 a request message, since later header fields might include 1045 conditionals, authentication credentials, or deliberately misleading 1046 duplicate header fields that would impact request processing. 1048 Multiple header fields with the same field name MUST NOT be sent in a 1049 message unless the entire field value for that header field is 1050 defined as a comma-separated list [i.e., #(values)]. Multiple header 1051 fields with the same field name can be combined into one "field-name: 1052 field-value" pair, without changing the semantics of the message, by 1053 appending each subsequent field value to the combined field value in 1054 order, separated by a comma. The order in which header fields with 1055 the same field name are received is therefore significant to the 1056 interpretation of the combined field value; a proxy MUST NOT change 1057 the order of these field values when forwarding a message. 1059 Note: The "Set-Cookie" header field as implemented in practice can 1060 occur multiple times, but does not use the list syntax, and thus 1061 cannot be combined into a single line ([RFC6265]). (See Appendix 1062 A.2.3 of [Kri2001] for details.) Also note that the Set-Cookie2 1063 header field specified in [RFC2965] does not share this problem. 1065 Historically, HTTP header field values could be extended over 1066 multiple lines by preceding each extra line with at least one space 1067 or horizontal tab octet (line folding). This specification 1068 deprecates such line folding except within the message/http media 1069 type (Section 10.3.1). HTTP/1.1 senders MUST NOT produce messages 1070 that include line folding (i.e., that contain any field-content that 1071 matches the obs-fold rule) unless the message is intended for 1072 packaging within the message/http media type. HTTP/1.1 recipients 1073 SHOULD accept line folding and replace any embedded obs-fold 1074 whitespace with a single SP prior to interpreting the field value or 1075 forwarding the message downstream. 1077 Historically, HTTP has allowed field content with text in the ISO- 1078 8859-1 [ISO-8859-1] character encoding and supported other character 1079 sets only through use of [RFC2047] encoding. In practice, most HTTP 1080 header field values use only a subset of the US-ASCII character 1081 encoding [USASCII]. Newly defined header fields SHOULD limit their 1082 field values to US-ASCII octets. Recipients SHOULD treat other (obs- 1083 text) octets in field content as opaque data. 1085 Comments can be included in some HTTP header fields by surrounding 1086 the comment text with parentheses. Comments are only allowed in 1087 fields containing "comment" as part of their field value definition. 1089 comment = "(" *( ctext / quoted-cpair / comment ) ")" 1090 ctext = OWS / %x21-27 / %x2A-5B / %x5D-7E / obs-text 1091 ; OWS / / obs-text 1093 The backslash octet ("\") can be used as a single-octet quoting 1094 mechanism within comment constructs: 1096 quoted-cpair = "\" ( WSP / VCHAR / obs-text ) 1098 Senders SHOULD NOT escape octets that do not require escaping (i.e., 1099 other than the backslash octet "\" and the parentheses "(" and ")"). 1101 HTTP does not place a pre-defined limit on the length of header 1102 fields, either in isolation or as a set. A server MUST be prepared 1103 to receive request header fields of unbounded length and respond with 1104 a 4xx status code if the received header field(s) would be longer 1105 than the server wishes to handle. 1107 A client that receives response headers that are longer than it 1108 wishes to handle can only treat it as a server error. 1110 Various ad-hoc limitations on header length are found in practice. 1111 It is RECOMMENDED that all HTTP senders and recipients support 1112 messages whose combined header fields have 4000 or more octets. 1114 3.3. Message Body 1116 The message-body (if any) of an HTTP message is used to carry the 1117 payload body associated with the request or response. 1119 message-body = *OCTET 1121 The message-body differs from the payload body only when a transfer- 1122 coding has been applied, as indicated by the Transfer-Encoding header 1123 field (Section 9.7). If more than one Transfer-Encoding header field 1124 is present in a message, the multiple field-values MUST be combined 1125 into one field-value, according to the algorithm defined in 1126 Section 3.2, before determining the message-body length. 1128 When one or more transfer-codings are applied to a payload in order 1129 to form the message-body, the Transfer-Encoding header field MUST 1130 contain the list of transfer-codings applied. Transfer-Encoding is a 1131 property of the message, not of the payload, and thus MAY be added or 1132 removed by any implementation along the request/response chain under 1133 the constraints found in Section 6.2. 1135 If a message is received that has multiple Content-Length header 1136 fields (Section 9.2) with field-values consisting of the same decimal 1137 value, or a single Content-Length header field with a field value 1138 containing a list of identical decimal values (e.g., "Content-Length: 1139 42, 42"), indicating that duplicate Content-Length header fields have 1140 been generated or combined by an upstream message processor, then the 1141 recipient MUST either reject the message as invalid or replace the 1142 duplicated field-values with a single valid Content-Length field 1143 containing that decimal value prior to determining the message-body 1144 length. 1146 The rules for when a message-body is allowed in a message differ for 1147 requests and responses. 1149 The presence of a message-body in a request is signaled by the 1150 inclusion of a Content-Length or Transfer-Encoding header field in 1151 the request's header fields, even if the request method does not 1152 define any use for a message-body. This allows the request message 1153 framing algorithm to be independent of method semantics. 1155 For response messages, whether or not a message-body is included with 1156 a message is dependent on both the request method and the response 1157 status code (Section 5.1.1). Responses to the HEAD request method 1158 never include a message-body because the associated response header 1159 fields (e.g., Transfer-Encoding, Content-Length, etc.) only indicate 1160 what their values would have been if the request method had been GET. 1161 All 1xx (Informational), 204 (No Content), and 304 (Not Modified) 1162 responses MUST NOT include a message-body. All other responses do 1163 include a message-body, although the body MAY be of zero length. 1165 The length of the message-body is determined by one of the following 1166 (in order of precedence): 1168 1. Any response to a HEAD request and any response with a status 1169 code of 100-199, 204, or 304 is always terminated by the first 1170 empty line after the header fields, regardless of the header 1171 fields present in the message, and thus cannot contain a message- 1172 body. 1174 2. If a Transfer-Encoding header field is present and the "chunked" 1175 transfer-coding (Section 6.2) is the final encoding, the message- 1176 body length is determined by reading and decoding the chunked 1177 data until the transfer-coding indicates the data is complete. 1179 If a Transfer-Encoding header field is present in a response and 1180 the "chunked" transfer-coding is not the final encoding, the 1181 message-body length is determined by reading the connection until 1182 it is closed by the server. If a Transfer-Encoding header field 1183 is present in a request and the "chunked" transfer-coding is not 1184 the final encoding, the message-body length cannot be determined 1185 reliably; the server MUST respond with the 400 (Bad Request) 1186 status code and then close the connection. 1188 If a message is received with both a Transfer-Encoding header 1189 field and a Content-Length header field, the Transfer-Encoding 1190 overrides the Content-Length. Such a message might indicate an 1191 attempt to perform request or response smuggling (bypass of 1192 security-related checks on message routing or content) and thus 1193 ought to be handled as an error. The provided Content-Length 1194 MUST be removed, prior to forwarding the message downstream, or 1195 replaced with the real message-body length after the transfer- 1196 coding is decoded. 1198 3. If a message is received without Transfer-Encoding and with 1199 either multiple Content-Length header fields having differing 1200 field-values or a single Content-Length header field having an 1201 invalid value, then the message framing is invalid and MUST be 1202 treated as an error to prevent request or response smuggling. If 1203 this is a request message, the server MUST respond with a 400 1204 (Bad Request) status code and then close the connection. If this 1205 is a response message received by a proxy, the proxy MUST discard 1206 the received response, send a 502 (Bad Gateway) status code as 1207 its downstream response, and then close the connection. If this 1208 is a response message received by a user-agent, it MUST be 1209 treated as an error by discarding the message and closing the 1210 connection. 1212 4. If a valid Content-Length header field is present without 1213 Transfer-Encoding, its decimal value defines the message-body 1214 length in octets. If the actual number of octets sent in the 1215 message is less than the indicated Content-Length, the recipient 1216 MUST consider the message to be incomplete and treat the 1217 connection as no longer usable. If the actual number of octets 1218 sent in the message is more than the indicated Content-Length, 1219 the recipient MUST only process the message-body up to the field 1220 value's number of octets; the remainder of the message MUST 1221 either be discarded or treated as the next message in a pipeline. 1222 For the sake of robustness, a user-agent MAY attempt to detect 1223 and correct such an error in message framing if it is parsing the 1224 response to the last request on on a connection and the 1225 connection has been closed by the server. 1227 5. If this is a request message and none of the above are true, then 1228 the message-body length is zero (no message-body is present). 1230 6. Otherwise, this is a response message without a declared message- 1231 body length, so the message-body length is determined by the 1232 number of octets received prior to the server closing the 1233 connection. 1235 Since there is no way to distinguish a successfully completed, close- 1236 delimited message from a partially-received message interrupted by 1237 network failure, implementations SHOULD use encoding or length- 1238 delimited messages whenever possible. The close-delimiting feature 1239 exists primarily for backwards compatibility with HTTP/1.0. 1241 A server MAY reject a request that contains a message-body but not a 1242 Content-Length by responding with 411 (Length Required). 1244 Unless a transfer-coding other than "chunked" has been applied, a 1245 client that sends a request containing a message-body SHOULD use a 1246 valid Content-Length header field if the message-body length is known 1247 in advance, rather than the "chunked" encoding, since some existing 1248 services respond to "chunked" with a 411 (Length Required) status 1249 code even though they understand the chunked encoding. This is 1250 typically because such services are implemented via a gateway that 1251 requires a content-length in advance of being called and the server 1252 is unable or unwilling to buffer the entire request before 1253 processing. 1255 A client that sends a request containing a message-body MUST include 1256 a valid Content-Length header field if it does not know the server 1257 will handle HTTP/1.1 (or later) requests; such knowledge can be in 1258 the form of specific user configuration or by remembering the version 1259 of a prior received response. 1261 Request messages that are prematurely terminated, possibly due to a 1262 cancelled connection or a server-imposed time-out exception, MUST 1263 result in closure of the connection; sending an HTTP/1.1 error 1264 response prior to closing the connection is OPTIONAL. Response 1265 messages that are prematurely terminated, usually by closure of the 1266 connection prior to receiving the expected number of octets or by 1267 failure to decode a transfer-encoded message-body, MUST be recorded 1268 as incomplete. A user agent MUST NOT render an incomplete response 1269 message-body as if it were complete (i.e., some indication must be 1270 given to the user that an error occurred). Cache requirements for 1271 incomplete responses are defined in Section 2.1.1 of [Part6]. 1273 A server MUST read the entire request message-body or close the 1274 connection after sending its response, since otherwise the remaining 1275 data on a persistent connection would be misinterpreted as the next 1276 request. Likewise, a client MUST read the entire response message- 1277 body if it intends to reuse the same connection for a subsequent 1278 request. Pipelining multiple requests on a connection is described 1279 in Section 7.1.2.2. 1281 3.4. General Header Fields 1283 There are a few header fields which have general applicability for 1284 both request and response messages, but which do not apply to the 1285 payload being transferred. These header fields apply only to the 1286 message being transmitted. 1288 +-------------------+---------------+ 1289 | Header Field Name | Defined in... | 1290 +-------------------+---------------+ 1291 | Connection | Section 9.1 | 1292 | Date | Section 9.3 | 1293 | Trailer | Section 9.6 | 1294 | Transfer-Encoding | Section 9.7 | 1295 | Upgrade | Section 9.8 | 1296 | Via | Section 9.9 | 1297 +-------------------+---------------+ 1299 4. Request 1301 A request message from a client to a server begins with a Request- 1302 Line, followed by zero or more header fields, an empty line 1303 signifying the end of the header block, and an optional message body. 1305 Request = Request-Line ; Section 4.1 1306 *( header-field CRLF ) ; Section 3.2 1307 CRLF 1308 [ message-body ] ; Section 3.3 1310 4.1. Request-Line 1312 The Request-Line begins with a method token, followed by a single 1313 space (SP), the request-target, another single space (SP), the 1314 protocol version, and ending with CRLF. 1316 Request-Line = Method SP request-target SP HTTP-Version CRLF 1318 4.1.1. Method 1320 The Method token indicates the request method to be performed on the 1321 target resource. The request method is case-sensitive. 1323 Method = token 1325 4.1.2. request-target 1327 The request-target identifies the target resource upon which to apply 1328 the request. In most cases, the user agent is provided a URI 1329 reference from which it determines an absolute URI for identifying 1330 the target resource. When a request to the resource is initiated, 1331 all or part of that URI is used to construct the HTTP request-target. 1333 request-target = "*" 1334 / absolute-URI 1335 / ( path-absolute [ "?" query ] ) 1336 / authority 1338 The four options for request-target are dependent on the nature of 1339 the request. 1341 The asterisk "*" form of request-target, which MUST NOT be used with 1342 any request method other than OPTIONS, means that the request applies 1343 to the server as a whole (the listening process) rather than to a 1344 specific named resource at that server. For example, 1346 OPTIONS * HTTP/1.1 1348 The "absolute-URI" form is REQUIRED when the request is being made to 1349 a proxy. The proxy is requested to either forward the request or 1350 service it from a valid cache, and then return the response. Note 1351 that the proxy MAY forward the request on to another proxy or 1352 directly to the server specified by the absolute-URI. In order to 1353 avoid request loops, a proxy that forwards requests to other proxies 1354 MUST be able to recognize and exclude all of its own server names, 1355 including any aliases, local variations, and the numeric IP address. 1356 An example Request-Line would be: 1358 GET http://www.example.org/pub/WWW/TheProject.html HTTP/1.1 1360 To allow for transition to absolute-URIs in all requests in future 1361 versions of HTTP, all HTTP/1.1 servers MUST accept the absolute-URI 1362 form in requests, even though HTTP/1.1 clients will only generate 1363 them in requests to proxies. 1365 If a proxy receives a host name that is not a fully qualified domain 1366 name, it MAY add its domain to the host name it received. If a proxy 1367 receives a fully qualified domain name, the proxy MUST NOT change the 1368 host name. 1370 The "authority form" is only used by the CONNECT request method 1371 (Section 7.9 of [Part2]). 1373 The most common form of request-target is that used when making a 1374 request to an origin server ("origin form"). In this case, the 1375 absolute path and query components of the URI MUST be transmitted as 1376 the request-target, and the authority component MUST be transmitted 1377 in a Host header field. For example, a client wishing to retrieve a 1378 representation of the resource, as identified above, directly from 1379 the origin server would open (or reuse) a TCP connection to port 80 1380 of the host "www.example.org" and send the lines: 1382 GET /pub/WWW/TheProject.html HTTP/1.1 1383 Host: www.example.org 1385 followed by the remainder of the Request. Note that the origin form 1386 of request-target always starts with an absolute path; if the target 1387 resource's URI path is empty, then an absolute path of "/" MUST be 1388 provided in the request-target. 1390 If a proxy receives an OPTIONS request with an absolute-URI form of 1391 request-target in which the URI has an empty path and no query 1392 component, then the last proxy on the request chain MUST use a 1393 request-target of "*" when it forwards the request to the indicated 1394 origin server. 1396 For example, the request 1398 OPTIONS http://www.example.org:8001 HTTP/1.1 1400 would be forwarded by the final proxy as 1402 OPTIONS * HTTP/1.1 1403 Host: www.example.org:8001 1405 after connecting to port 8001 of host "www.example.org". 1407 The request-target is transmitted in the format specified in 1408 Section 2.7.1. If the request-target is percent-encoded ([RFC3986], 1409 Section 2.1), the origin server MUST decode the request-target in 1410 order to properly interpret the request. Servers SHOULD respond to 1411 invalid request-targets with an appropriate status code. 1413 A non-transforming proxy MUST NOT rewrite the "path-absolute" part of 1414 the received request-target when forwarding it to the next inbound 1415 server, except as noted above to replace a null path-absolute with 1416 "/" or "*". 1418 Note: The "no rewrite" rule prevents the proxy from changing the 1419 meaning of the request when the origin server is improperly using 1420 a non-reserved URI character for a reserved purpose. Implementors 1421 need to be aware that some pre-HTTP/1.1 proxies have been known to 1422 rewrite the request-target. 1424 HTTP does not place a pre-defined limit on the length of a request- 1425 target. A server MUST be prepared to receive URIs of unbounded 1426 length and respond with the 414 (URI Too Long) status code if the 1427 received request-target would be longer than the server wishes to 1428 handle (see Section 8.4.15 of [Part2]). 1430 Various ad-hoc limitations on request-target length are found in 1431 practice. It is RECOMMENDED that all HTTP senders and recipients 1432 support request-target lengths of 8000 or more octets. 1434 Note: Fragments ([RFC3986], Section 3.5) are not part of the 1435 request-target and thus will not be transmitted in an HTTP 1436 request. 1438 4.2. The Resource Identified by a Request 1440 The exact resource identified by an Internet request is determined by 1441 examining both the request-target and the Host header field. 1443 An origin server that does not allow resources to differ by the 1444 requested host MAY ignore the Host header field value when 1445 determining the resource identified by an HTTP/1.1 request. (But see 1446 Appendix B.1.1 for other requirements on Host support in HTTP/1.1.) 1447 An origin server that does differentiate resources based on the host 1448 requested (sometimes referred to as virtual hosts or vanity host 1449 names) MUST use the following rules for determining the requested 1450 resource on an HTTP/1.1 request: 1452 1. If request-target is an absolute-URI, the host is part of the 1453 request-target. Any Host header field value in the request MUST 1454 be ignored. 1456 2. If the request-target is not an absolute-URI, and the request 1457 includes a Host header field, the host is determined by the Host 1458 header field value. 1460 3. If the host as determined by rule 1 or 2 is not a valid host on 1461 the server, the response MUST be a 400 (Bad Request) error 1462 message. 1464 Recipients of an HTTP/1.0 request that lacks a Host header field MAY 1465 attempt to use heuristics (e.g., examination of the URI path for 1466 something unique to a particular host) in order to determine what 1467 exact resource is being requested. 1469 4.3. Effective Request URI 1471 HTTP requests often do not carry the absolute URI ([RFC3986], Section 1472 4.3) for the target resource; instead, the URI needs to be inferred 1473 from the request-target, Host header field, and connection context. 1474 The result of this process is called the "effective request URI". 1475 The "target resource" is the resource identified by the effective 1476 request URI. 1478 If the request-target is an absolute-URI, then the effective request 1479 URI is the request-target. 1481 If the request-target uses the path-absolute form or the asterisk 1482 form, and the Host header field is present, then the effective 1483 request URI is constructed by concatenating 1485 o the scheme name: "http" if the request was received over an 1486 insecure TCP connection, or "https" when received over a SSL/ 1487 TLS-secured TCP connection, 1489 o the octet sequence "://", 1491 o the authority component, as specified in the Host header field 1492 (Section 9.4), and 1494 o the request-target obtained from the Request-Line, unless the 1495 request-target is just the asterisk "*". 1497 If the request-target uses the path-absolute form or the asterisk 1498 form, and the Host header field is not present, then the effective 1499 request URI is undefined. 1501 Otherwise, when request-target uses the authority form, the effective 1502 request URI is undefined. 1504 Example 1: the effective request URI for the message 1506 GET /pub/WWW/TheProject.html HTTP/1.1 1507 Host: www.example.org:8080 1509 (received over an insecure TCP connection) is "http", plus "://", 1510 plus the authority component "www.example.org:8080", plus the 1511 request-target "/pub/WWW/TheProject.html", thus 1512 "http://www.example.org:8080/pub/WWW/TheProject.html". 1514 Example 2: the effective request URI for the message 1516 GET * HTTP/1.1 1517 Host: www.example.org 1519 (received over an SSL/TLS secured TCP connection) is "https", plus 1520 "://", plus the authority component "www.example.org", thus 1521 "https://www.example.org". 1523 Effective request URIs are compared using the rules described in 1524 Section 2.7.3, except that empty path components MUST NOT be treated 1525 as equivalent to an absolute path of "/". 1527 5. Response 1529 After receiving and interpreting a request message, a server responds 1530 with an HTTP response message. 1532 Response = Status-Line ; Section 5.1 1533 *( header-field CRLF ) ; Section 3.2 1534 CRLF 1535 [ message-body ] ; Section 3.3 1537 5.1. Status-Line 1539 The first line of a Response message is the Status-Line, consisting 1540 of the protocol version, a space (SP), the status code, another 1541 space, a possibly-empty textual phrase describing the status code, 1542 and ending with CRLF. 1544 Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF 1546 5.1.1. Status Code and Reason Phrase 1548 The Status-Code element is a 3-digit integer result code of the 1549 attempt to understand and satisfy the request. These codes are fully 1550 defined in Section 8 of [Part2]. The Reason Phrase exists for the 1551 sole purpose of providing a textual description associated with the 1552 numeric status code, out of deference to earlier Internet application 1553 protocols that were more frequently used with interactive text 1554 clients. A client SHOULD ignore the content of the Reason Phrase. 1556 The first digit of the Status-Code defines the class of response. 1557 The last two digits do not have any categorization role. There are 5 1558 values for the first digit: 1560 o 1xx: Informational - Request received, continuing process 1562 o 2xx: Success - The action was successfully received, understood, 1563 and accepted 1565 o 3xx: Redirection - Further action must be taken in order to 1566 complete the request 1568 o 4xx: Client Error - The request contains bad syntax or cannot be 1569 fulfilled 1571 o 5xx: Server Error - The server failed to fulfill an apparently 1572 valid request 1574 Status-Code = 3DIGIT 1575 Reason-Phrase = *( WSP / VCHAR / obs-text ) 1577 6. Protocol Parameters 1579 6.1. Date/Time Formats: Full Date 1581 HTTP applications have historically allowed three different formats 1582 for date/time stamps. However, the preferred format is a fixed- 1583 length subset of that defined by [RFC1123]: 1585 Sun, 06 Nov 1994 08:49:37 GMT ; RFC 1123 1587 The other formats are described here only for compatibility with 1588 obsolete implementations. 1590 Sunday, 06-Nov-94 08:49:37 GMT ; obsolete RFC 850 format 1591 Sun Nov 6 08:49:37 1994 ; ANSI C's asctime() format 1593 HTTP/1.1 clients and servers that parse a date value MUST accept all 1594 three formats (for compatibility with HTTP/1.0), though they MUST 1595 only generate the RFC 1123 format for representing HTTP-date values 1596 in header fields. See Appendix A for further information. 1598 All HTTP date/time stamps MUST be represented in Greenwich Mean Time 1599 (GMT), without exception. For the purposes of HTTP, GMT is exactly 1600 equal to UTC (Coordinated Universal Time). This is indicated in the 1601 first two formats by the inclusion of "GMT" as the three-letter 1602 abbreviation for time zone, and MUST be assumed when reading the 1603 asctime format. HTTP-date is case sensitive and MUST NOT include 1604 additional whitespace beyond that specifically included as SP in the 1605 grammar. 1607 HTTP-date = rfc1123-date / obs-date 1609 Preferred format: 1611 rfc1123-date = day-name "," SP date1 SP time-of-day SP GMT 1612 ; fixed length subset of the format defined in 1613 ; Section 5.2.14 of [RFC1123] 1615 day-name = %x4D.6F.6E ; "Mon", case-sensitive 1616 / %x54.75.65 ; "Tue", case-sensitive 1617 / %x57.65.64 ; "Wed", case-sensitive 1618 / %x54.68.75 ; "Thu", case-sensitive 1619 / %x46.72.69 ; "Fri", case-sensitive 1620 / %x53.61.74 ; "Sat", case-sensitive 1621 / %x53.75.6E ; "Sun", case-sensitive 1623 date1 = day SP month SP year 1624 ; e.g., 02 Jun 1982 1626 day = 2DIGIT 1627 month = %x4A.61.6E ; "Jan", case-sensitive 1628 / %x46.65.62 ; "Feb", case-sensitive 1629 / %x4D.61.72 ; "Mar", case-sensitive 1630 / %x41.70.72 ; "Apr", case-sensitive 1631 / %x4D.61.79 ; "May", case-sensitive 1632 / %x4A.75.6E ; "Jun", case-sensitive 1633 / %x4A.75.6C ; "Jul", case-sensitive 1634 / %x41.75.67 ; "Aug", case-sensitive 1635 / %x53.65.70 ; "Sep", case-sensitive 1636 / %x4F.63.74 ; "Oct", case-sensitive 1637 / %x4E.6F.76 ; "Nov", case-sensitive 1638 / %x44.65.63 ; "Dec", case-sensitive 1639 year = 4DIGIT 1641 GMT = %x47.4D.54 ; "GMT", case-sensitive 1643 time-of-day = hour ":" minute ":" second 1644 ; 00:00:00 - 23:59:59 1646 hour = 2DIGIT 1647 minute = 2DIGIT 1648 second = 2DIGIT 1650 The semantics of day-name, day, month, year, and time-of-day are the 1651 same as those defined for the RFC 5322 constructs with the 1652 corresponding name ([RFC5322], Section 3.3). 1654 Obsolete formats: 1656 obs-date = rfc850-date / asctime-date 1657 rfc850-date = day-name-l "," SP date2 SP time-of-day SP GMT 1658 date2 = day "-" month "-" 2DIGIT 1659 ; day-month-year (e.g., 02-Jun-82) 1661 day-name-l = %x4D.6F.6E.64.61.79 ; "Monday", case-sensitive 1662 / %x54.75.65.73.64.61.79 ; "Tuesday", case-sensitive 1663 / %x57.65.64.6E.65.73.64.61.79 ; "Wednesday", case-sensitive 1664 / %x54.68.75.72.73.64.61.79 ; "Thursday", case-sensitive 1665 / %x46.72.69.64.61.79 ; "Friday", case-sensitive 1666 / %x53.61.74.75.72.64.61.79 ; "Saturday", case-sensitive 1667 / %x53.75.6E.64.61.79 ; "Sunday", case-sensitive 1669 asctime-date = day-name SP date3 SP time-of-day SP year 1670 date3 = month SP ( 2DIGIT / ( SP 1DIGIT )) 1671 ; month day (e.g., Jun 2) 1673 Note: Recipients of date values are encouraged to be robust in 1674 accepting date values that might have been sent by non-HTTP 1675 applications, as is sometimes the case when retrieving or posting 1676 messages via proxies/gateways to SMTP or NNTP. 1678 Note: HTTP requirements for the date/time stamp format apply only 1679 to their usage within the protocol stream. Clients and servers 1680 are not required to use these formats for user presentation, 1681 request logging, etc. 1683 6.2. Transfer Codings 1685 Transfer-coding values are used to indicate an encoding 1686 transformation that has been, can be, or might need to be applied to 1687 a payload body in order to ensure "safe transport" through the 1688 network. This differs from a content coding in that the transfer- 1689 coding is a property of the message rather than a property of the 1690 representation that is being transferred. 1692 transfer-coding = "chunked" ; Section 6.2.1 1693 / "compress" ; Section 6.2.2.1 1694 / "deflate" ; Section 6.2.2.2 1695 / "gzip" ; Section 6.2.2.3 1696 / transfer-extension 1697 transfer-extension = token *( OWS ";" OWS transfer-parameter ) 1699 Parameters are in the form of attribute/value pairs. 1701 transfer-parameter = attribute BWS "=" BWS value 1702 attribute = token 1703 value = word 1705 All transfer-coding values are case-insensitive. HTTP/1.1 uses 1706 transfer-coding values in the TE header field (Section 9.5) and in 1707 the Transfer-Encoding header field (Section 9.7). 1709 Transfer-codings are analogous to the Content-Transfer-Encoding 1710 values of MIME, which were designed to enable safe transport of 1711 binary data over a 7-bit transport service ([RFC2045], Section 6). 1712 However, safe transport has a different focus for an 8bit-clean 1713 transfer protocol. In HTTP, the only unsafe characteristic of 1714 message-bodies is the difficulty in determining the exact message 1715 body length (Section 3.3), or the desire to encrypt data over a 1716 shared transport. 1718 A server that receives a request message with a transfer-coding it 1719 does not understand SHOULD respond with 501 (Not Implemented) and 1720 then close the connection. A server MUST NOT send transfer-codings 1721 to an HTTP/1.0 client. 1723 6.2.1. Chunked Transfer Coding 1725 The chunked encoding modifies the body of a message in order to 1726 transfer it as a series of chunks, each with its own size indicator, 1727 followed by an OPTIONAL trailer containing header fields. This 1728 allows dynamically produced content to be transferred along with the 1729 information necessary for the recipient to verify that it has 1730 received the full message. 1732 Chunked-Body = *chunk 1733 last-chunk 1734 trailer-part 1735 CRLF 1737 chunk = chunk-size *WSP [ chunk-ext ] CRLF 1738 chunk-data CRLF 1739 chunk-size = 1*HEXDIG 1740 last-chunk = 1*("0") *WSP [ chunk-ext ] CRLF 1742 chunk-ext = *( ";" *WSP chunk-ext-name 1743 [ "=" chunk-ext-val ] *WSP ) 1744 chunk-ext-name = token 1745 chunk-ext-val = token / quoted-str-nf 1746 chunk-data = 1*OCTET ; a sequence of chunk-size octets 1747 trailer-part = *( header-field CRLF ) 1749 quoted-str-nf = DQUOTE *( qdtext-nf / quoted-pair ) DQUOTE 1750 ; like quoted-string, but disallowing line folding 1751 qdtext-nf = WSP / %x21 / %x23-5B / %x5D-7E / obs-text 1752 ; WSP / / obs-text 1754 The chunk-size field is a string of hex digits indicating the size of 1755 the chunk-data in octets. The chunked encoding is ended by any chunk 1756 whose size is zero, followed by the trailer, which is terminated by 1757 an empty line. 1759 The trailer allows the sender to include additional HTTP header 1760 fields at the end of the message. The Trailer header field can be 1761 used to indicate which header fields are included in a trailer (see 1762 Section 9.6). 1764 A server using chunked transfer-coding in a response MUST NOT use the 1765 trailer for any header fields unless at least one of the following is 1766 true: 1768 1. the request included a TE header field that indicates "trailers" 1769 is acceptable in the transfer-coding of the response, as 1770 described in Section 9.5; or, 1772 2. the trailer fields consist entirely of optional metadata, and the 1773 recipient could use the message (in a manner acceptable to the 1774 server where the field originated) without receiving it. In 1775 other words, the server that generated the header (often but not 1776 always the origin server) is willing to accept the possibility 1777 that the trailer fields might be silently discarded along the 1778 path to the client. 1780 This requirement prevents an interoperability failure when the 1781 message is being received by an HTTP/1.1 (or later) proxy and 1782 forwarded to an HTTP/1.0 recipient. It avoids a situation where 1783 compliance with the protocol would have necessitated a possibly 1784 infinite buffer on the proxy. 1786 A process for decoding the "chunked" transfer-coding can be 1787 represented in pseudo-code as: 1789 length := 0 1790 read chunk-size, chunk-ext (if any) and CRLF 1791 while (chunk-size > 0) { 1792 read chunk-data and CRLF 1793 append chunk-data to decoded-body 1794 length := length + chunk-size 1795 read chunk-size and CRLF 1796 } 1797 read header-field 1798 while (header-field not empty) { 1799 append header-field to existing header fields 1800 read header-field 1801 } 1802 Content-Length := length 1803 Remove "chunked" from Transfer-Encoding 1805 All HTTP/1.1 applications MUST be able to receive and decode the 1806 "chunked" transfer-coding and MUST ignore chunk-ext extensions they 1807 do not understand. 1809 Since "chunked" is the only transfer-coding required to be understood 1810 by HTTP/1.1 recipients, it plays a crucial role in delimiting 1811 messages on a persistent connection. Whenever a transfer-coding is 1812 applied to a payload body in a request, the final transfer-coding 1813 applied MUST be "chunked". If a transfer-coding is applied to a 1814 response payload body, then either the final transfer-coding applied 1815 MUST be "chunked" or the message MUST be terminated by closing the 1816 connection. When the "chunked" transfer-coding is used, it MUST be 1817 the last transfer-coding applied to form the message-body. The 1818 "chunked" transfer-coding MUST NOT be applied more than once in a 1819 message-body. 1821 6.2.2. Compression Codings 1823 The codings defined below can be used to compress the payload of a 1824 message. 1826 Note: Use of program names for the identification of encoding 1827 formats is not desirable and is discouraged for future encodings. 1828 Their use here is representative of historical practice, not good 1829 design. 1831 Note: For compatibility with previous implementations of HTTP, 1832 applications SHOULD consider "x-gzip" and "x-compress" to be 1833 equivalent to "gzip" and "compress" respectively. 1835 6.2.2.1. Compress Coding 1837 The "compress" format is produced by the common UNIX file compression 1838 program "compress". This format is an adaptive Lempel-Ziv-Welch 1839 coding (LZW). 1841 6.2.2.2. Deflate Coding 1843 The "deflate" format is defined as the "deflate" compression 1844 mechanism (described in [RFC1951]) used inside the "zlib" data format 1845 ([RFC1950]). 1847 Note: Some incorrect implementations send the "deflate" compressed 1848 data without the zlib wrapper. 1850 6.2.2.3. Gzip Coding 1852 The "gzip" format is produced by the file compression program "gzip" 1853 (GNU zip), as described in [RFC1952]. This format is a Lempel-Ziv 1854 coding (LZ77) with a 32 bit CRC. 1856 6.2.3. Transfer Coding Registry 1858 The HTTP Transfer Coding Registry defines the name space for the 1859 transfer coding names. 1861 Registrations MUST include the following fields: 1863 o Name 1865 o Description 1867 o Pointer to specification text 1869 Names of transfer codings MUST NOT overlap with names of content 1870 codings (Section 2.2 of [Part3]), unless the encoding transformation 1871 is identical (as it is the case for the compression codings defined 1872 in Section 6.2.2). 1874 Values to be added to this name space require a specification (see 1875 "Specification Required" in Section 4.1 of [RFC5226]), and MUST 1876 conform to the purpose of transfer coding defined in this section. 1878 The registry itself is maintained at 1879 . 1881 6.3. Product Tokens 1883 Product tokens are used to allow communicating applications to 1884 identify themselves by software name and version. Most fields using 1885 product tokens also allow sub-products which form a significant part 1886 of the application to be listed, separated by whitespace. By 1887 convention, the products are listed in order of their significance 1888 for identifying the application. 1890 product = token ["/" product-version] 1891 product-version = token 1893 Examples: 1895 User-Agent: CERN-LineMode/2.15 libwww/2.17b3 1896 Server: Apache/0.8.4 1898 Product tokens SHOULD be short and to the point. They MUST NOT be 1899 used for advertising or other non-essential information. Although 1900 any token octet MAY appear in a product-version, this token SHOULD 1901 only be used for a version identifier (i.e., successive versions of 1902 the same product SHOULD only differ in the product-version portion of 1903 the product value). 1905 6.4. Quality Values 1907 Both transfer codings (TE request header field, Section 9.5) and 1908 content negotiation (Section 5 of [Part3]) use short "floating point" 1909 numbers to indicate the relative importance ("weight") of various 1910 negotiable parameters. A weight is normalized to a real number in 1911 the range 0 through 1, where 0 is the minimum and 1 the maximum 1912 value. If a parameter has a quality value of 0, then content with 1913 this parameter is "not acceptable" for the client. HTTP/1.1 1914 applications MUST NOT generate more than three digits after the 1915 decimal point. User configuration of these values SHOULD also be 1916 limited in this fashion. 1918 qvalue = ( "0" [ "." 0*3DIGIT ] ) 1919 / ( "1" [ "." 0*3("0") ] ) 1921 Note: "Quality values" is a misnomer, since these values merely 1922 represent relative degradation in desired quality. 1924 7. Connections 1925 7.1. Persistent Connections 1927 7.1.1. Purpose 1929 Prior to persistent connections, a separate TCP connection was 1930 established for each request, increasing the load on HTTP servers and 1931 causing congestion on the Internet. The use of inline images and 1932 other associated data often requires a client to make multiple 1933 requests of the same server in a short amount of time. Analysis of 1934 these performance problems and results from a prototype 1935 implementation are available [Pad1995] [Spe]. Implementation 1936 experience and measurements of actual HTTP/1.1 implementations show 1937 good results [Nie1997]. Alternatives have also been explored, for 1938 example, T/TCP [Tou1998]. 1940 Persistent HTTP connections have a number of advantages: 1942 o By opening and closing fewer TCP connections, CPU time is saved in 1943 routers and hosts (clients, servers, proxies, gateways, tunnels, 1944 or caches), and memory used for TCP protocol control blocks can be 1945 saved in hosts. 1947 o HTTP requests and responses can be pipelined on a connection. 1948 Pipelining allows a client to make multiple requests without 1949 waiting for each response, allowing a single TCP connection to be 1950 used much more efficiently, with much lower elapsed time. 1952 o Network congestion is reduced by reducing the number of packets 1953 caused by TCP opens, and by allowing TCP sufficient time to 1954 determine the congestion state of the network. 1956 o Latency on subsequent requests is reduced since there is no time 1957 spent in TCP's connection opening handshake. 1959 o HTTP can evolve more gracefully, since errors can be reported 1960 without the penalty of closing the TCP connection. Clients using 1961 future versions of HTTP might optimistically try a new feature, 1962 but if communicating with an older server, retry with old 1963 semantics after an error is reported. 1965 HTTP implementations SHOULD implement persistent connections. 1967 7.1.2. Overall Operation 1969 A significant difference between HTTP/1.1 and earlier versions of 1970 HTTP is that persistent connections are the default behavior of any 1971 HTTP connection. That is, unless otherwise indicated, the client 1972 SHOULD assume that the server will maintain a persistent connection, 1973 even after error responses from the server. 1975 Persistent connections provide a mechanism by which a client and a 1976 server can signal the close of a TCP connection. This signaling 1977 takes place using the Connection header field (Section 9.1). Once a 1978 close has been signaled, the client MUST NOT send any more requests 1979 on that connection. 1981 7.1.2.1. Negotiation 1983 An HTTP/1.1 server MAY assume that a HTTP/1.1 client intends to 1984 maintain a persistent connection unless a Connection header field 1985 including the connection-token "close" was sent in the request. If 1986 the server chooses to close the connection immediately after sending 1987 the response, it SHOULD send a Connection header field including the 1988 connection-token "close". 1990 An HTTP/1.1 client MAY expect a connection to remain open, but would 1991 decide to keep it open based on whether the response from a server 1992 contains a Connection header field with the connection-token close. 1993 In case the client does not want to maintain a connection for more 1994 than that request, it SHOULD send a Connection header field including 1995 the connection-token close. 1997 If either the client or the server sends the close token in the 1998 Connection header field, that request becomes the last one for the 1999 connection. 2001 Clients and servers SHOULD NOT assume that a persistent connection is 2002 maintained for HTTP versions less than 1.1 unless it is explicitly 2003 signaled. See Appendix B.1.2 for more information on backward 2004 compatibility with HTTP/1.0 clients. 2006 In order to remain persistent, all messages on the connection MUST 2007 have a self-defined message length (i.e., one not defined by closure 2008 of the connection), as described in Section 3.3. 2010 7.1.2.2. Pipelining 2012 A client that supports persistent connections MAY "pipeline" its 2013 requests (i.e., send multiple requests without waiting for each 2014 response). A server MUST send its responses to those requests in the 2015 same order that the requests were received. 2017 Clients which assume persistent connections and pipeline immediately 2018 after connection establishment SHOULD be prepared to retry their 2019 connection if the first pipelined attempt fails. If a client does 2020 such a retry, it MUST NOT pipeline before it knows the connection is 2021 persistent. Clients MUST also be prepared to resend their requests 2022 if the server closes the connection before sending all of the 2023 corresponding responses. 2025 Clients SHOULD NOT pipeline requests using non-idempotent request 2026 methods or non-idempotent sequences of request methods (see Section 2027 7.1.2 of [Part2]). Otherwise, a premature termination of the 2028 transport connection could lead to indeterminate results. A client 2029 wishing to send a non-idempotent request SHOULD wait to send that 2030 request until it has received the response status line for the 2031 previous request. 2033 7.1.3. Proxy Servers 2035 It is especially important that proxies correctly implement the 2036 properties of the Connection header field as specified in 2037 Section 9.1. 2039 The proxy server MUST signal persistent connections separately with 2040 its clients and the origin servers (or other proxy servers) that it 2041 connects to. Each persistent connection applies to only one 2042 transport link. 2044 A proxy server MUST NOT establish a HTTP/1.1 persistent connection 2045 with an HTTP/1.0 client (but see Section 19.7.1 of [RFC2068] for 2046 information and discussion of the problems with the Keep-Alive header 2047 field implemented by many HTTP/1.0 clients). 2049 7.1.3.1. End-to-end and Hop-by-hop Header Fields 2051 For the purpose of defining the behavior of caches and non-caching 2052 proxies, we divide HTTP header fields into two categories: 2054 o End-to-end header fields, which are transmitted to the ultimate 2055 recipient of a request or response. End-to-end header fields in 2056 responses MUST be stored as part of a cache entry and MUST be 2057 transmitted in any response formed from a cache entry. 2059 o Hop-by-hop header fields, which are meaningful only for a single 2060 transport-level connection, and are not stored by caches or 2061 forwarded by proxies. 2063 The following HTTP/1.1 header fields are hop-by-hop header fields: 2065 o Connection 2067 o Keep-Alive 2068 o Proxy-Authenticate 2070 o Proxy-Authorization 2072 o TE 2074 o Trailer 2076 o Transfer-Encoding 2078 o Upgrade 2080 All other header fields defined by HTTP/1.1 are end-to-end header 2081 fields. 2083 Other hop-by-hop header fields MUST be listed in a Connection header 2084 field (Section 9.1). 2086 7.1.3.2. Non-modifiable Header Fields 2088 Some features of HTTP/1.1, such as Digest Authentication, depend on 2089 the value of certain end-to-end header fields. A non-transforming 2090 proxy SHOULD NOT modify an end-to-end header field unless the 2091 definition of that header field requires or specifically allows that. 2093 A non-transforming proxy MUST NOT modify any of the following fields 2094 in a request or response, and it MUST NOT add any of these fields if 2095 not already present: 2097 o Allow 2099 o Content-Location 2101 o Content-MD5 2103 o ETag 2105 o Last-Modified 2107 o Server 2109 A non-transforming proxy MUST NOT modify any of the following fields 2110 in a response: 2112 o Expires 2114 but it MAY add any of these fields if not already present. If an 2115 Expires header field is added, it MUST be given a field-value 2116 identical to that of the Date header field in that response. 2118 A proxy MUST NOT modify or add any of the following fields in a 2119 message that contains the no-transform cache-control directive, or in 2120 any request: 2122 o Content-Encoding 2124 o Content-Range 2126 o Content-Type 2128 A transforming proxy MAY modify or add these fields to a message that 2129 does not include no-transform, but if it does so, it MUST add a 2130 Warning 214 (Transformation applied) if one does not already appear 2131 in the message (see Section 3.6 of [Part6]). 2133 Warning: Unnecessary modification of end-to-end header fields 2134 might cause authentication failures if stronger authentication 2135 mechanisms are introduced in later versions of HTTP. Such 2136 authentication mechanisms MAY rely on the values of header fields 2137 not listed here. 2139 A non-transforming proxy MUST preserve the message payload ([Part3]), 2140 though it MAY change the message-body through application or removal 2141 of a transfer-coding (Section 6.2). 2143 7.1.4. Practical Considerations 2145 Servers will usually have some time-out value beyond which they will 2146 no longer maintain an inactive connection. Proxy servers might make 2147 this a higher value since it is likely that the client will be making 2148 more connections through the same server. The use of persistent 2149 connections places no requirements on the length (or existence) of 2150 this time-out for either the client or the server. 2152 When a client or server wishes to time-out it SHOULD issue a graceful 2153 close on the transport connection. Clients and servers SHOULD both 2154 constantly watch for the other side of the transport close, and 2155 respond to it as appropriate. If a client or server does not detect 2156 the other side's close promptly it could cause unnecessary resource 2157 drain on the network. 2159 A client, server, or proxy MAY close the transport connection at any 2160 time. For example, a client might have started to send a new request 2161 at the same time that the server has decided to close the "idle" 2162 connection. From the server's point of view, the connection is being 2163 closed while it was idle, but from the client's point of view, a 2164 request is in progress. 2166 This means that clients, servers, and proxies MUST be able to recover 2167 from asynchronous close events. Client software SHOULD reopen the 2168 transport connection and retransmit the aborted sequence of requests 2169 without user interaction so long as the request sequence is 2170 idempotent (see Section 7.1.2 of [Part2]). Non-idempotent request 2171 methods or sequences MUST NOT be automatically retried, although user 2172 agents MAY offer a human operator the choice of retrying the 2173 request(s). Confirmation by user-agent software with semantic 2174 understanding of the application MAY substitute for user 2175 confirmation. The automatic retry SHOULD NOT be repeated if the 2176 second sequence of requests fails. 2178 Servers SHOULD always respond to at least one request per connection, 2179 if at all possible. Servers SHOULD NOT close a connection in the 2180 middle of transmitting a response, unless a network or client failure 2181 is suspected. 2183 Clients (including proxies) SHOULD limit the number of simultaneous 2184 connections that they maintain to a given server (including proxies). 2186 Previous revisions of HTTP gave a specific number of connections as a 2187 ceiling, but this was found to be impractical for many applications. 2188 As a result, this specification does not mandate a particular maximum 2189 number of connections, but instead encourages clients to be 2190 conservative when opening multiple connections. 2192 In particular, while using multiple connections avoids the "head-of- 2193 line blocking" problem (whereby a request that takes significant 2194 server-side processing and/or has a large payload can block 2195 subsequent requests on the same connection), each connection used 2196 consumes server resources (sometimes significantly), and furthermore 2197 using multiple connections can cause undesirable side effects in 2198 congested networks. 2200 Note that servers might reject traffic that they deem abusive, 2201 including an excessive number of connections from a client. 2203 7.2. Message Transmission Requirements 2205 7.2.1. Persistent Connections and Flow Control 2207 HTTP/1.1 servers SHOULD maintain persistent connections and use TCP's 2208 flow control mechanisms to resolve temporary overloads, rather than 2209 terminating connections with the expectation that clients will retry. 2210 The latter technique can exacerbate network congestion. 2212 7.2.2. Monitoring Connections for Error Status Messages 2214 An HTTP/1.1 (or later) client sending a message-body SHOULD monitor 2215 the network connection for an error status code while it is 2216 transmitting the request. If the client sees an error status code, 2217 it SHOULD immediately cease transmitting the body. If the body is 2218 being sent using a "chunked" encoding (Section 6.2), a zero length 2219 chunk and empty trailer MAY be used to prematurely mark the end of 2220 the message. If the body was preceded by a Content-Length header 2221 field, the client MUST close the connection. 2223 7.2.3. Use of the 100 (Continue) Status 2225 The purpose of the 100 (Continue) status code (see Section 8.1.1 of 2226 [Part2]) is to allow a client that is sending a request message with 2227 a request body to determine if the origin server is willing to accept 2228 the request (based on the request header fields) before the client 2229 sends the request body. In some cases, it might either be 2230 inappropriate or highly inefficient for the client to send the body 2231 if the server will reject the message without looking at the body. 2233 Requirements for HTTP/1.1 clients: 2235 o If a client will wait for a 100 (Continue) response before sending 2236 the request body, it MUST send an Expect header field (Section 9.2 2237 of [Part2]) with the "100-continue" expectation. 2239 o A client MUST NOT send an Expect header field (Section 9.2 of 2240 [Part2]) with the "100-continue" expectation if it does not intend 2241 to send a request body. 2243 Because of the presence of older implementations, the protocol allows 2244 ambiguous situations in which a client might send "Expect: 100- 2245 continue" without receiving either a 417 (Expectation Failed) or a 2246 100 (Continue) status code. Therefore, when a client sends this 2247 header field to an origin server (possibly via a proxy) from which it 2248 has never seen a 100 (Continue) status code, the client SHOULD NOT 2249 wait for an indefinite period before sending the request body. 2251 Requirements for HTTP/1.1 origin servers: 2253 o Upon receiving a request which includes an Expect header field 2254 with the "100-continue" expectation, an origin server MUST either 2255 respond with 100 (Continue) status code and continue to read from 2256 the input stream, or respond with a final status code. The origin 2257 server MUST NOT wait for the request body before sending the 100 2258 (Continue) response. If it responds with a final status code, it 2259 MAY close the transport connection or it MAY continue to read and 2260 discard the rest of the request. It MUST NOT perform the request 2261 method if it returns a final status code. 2263 o An origin server SHOULD NOT send a 100 (Continue) response if the 2264 request message does not include an Expect header field with the 2265 "100-continue" expectation, and MUST NOT send a 100 (Continue) 2266 response if such a request comes from an HTTP/1.0 (or earlier) 2267 client. There is an exception to this rule: for compatibility 2268 with [RFC2068], a server MAY send a 100 (Continue) status code in 2269 response to an HTTP/1.1 PUT or POST request that does not include 2270 an Expect header field with the "100-continue" expectation. This 2271 exception, the purpose of which is to minimize any client 2272 processing delays associated with an undeclared wait for 100 2273 (Continue) status code, applies only to HTTP/1.1 requests, and not 2274 to requests with any other HTTP-version value. 2276 o An origin server MAY omit a 100 (Continue) response if it has 2277 already received some or all of the request body for the 2278 corresponding request. 2280 o An origin server that sends a 100 (Continue) response MUST 2281 ultimately send a final status code, once the request body is 2282 received and processed, unless it terminates the transport 2283 connection prematurely. 2285 o If an origin server receives a request that does not include an 2286 Expect header field with the "100-continue" expectation, the 2287 request includes a request body, and the server responds with a 2288 final status code before reading the entire request body from the 2289 transport connection, then the server SHOULD NOT close the 2290 transport connection until it has read the entire request, or 2291 until the client closes the connection. Otherwise, the client 2292 might not reliably receive the response message. However, this 2293 requirement is not be construed as preventing a server from 2294 defending itself against denial-of-service attacks, or from badly 2295 broken client implementations. 2297 Requirements for HTTP/1.1 proxies: 2299 o If a proxy receives a request that includes an Expect header field 2300 with the "100-continue" expectation, and the proxy either knows 2301 that the next-hop server complies with HTTP/1.1 or higher, or does 2302 not know the HTTP version of the next-hop server, it MUST forward 2303 the request, including the Expect header field. 2305 o If the proxy knows that the version of the next-hop server is 2306 HTTP/1.0 or lower, it MUST NOT forward the request, and it MUST 2307 respond with a 417 (Expectation Failed) status code. 2309 o Proxies SHOULD maintain a cache recording the HTTP version numbers 2310 received from recently-referenced next-hop servers. 2312 o A proxy MUST NOT forward a 100 (Continue) response if the request 2313 message was received from an HTTP/1.0 (or earlier) client and did 2314 not include an Expect header field with the "100-continue" 2315 expectation. This requirement overrides the general rule for 2316 forwarding of 1xx responses (see Section 8.1 of [Part2]). 2318 7.2.4. Client Behavior if Server Prematurely Closes Connection 2320 If an HTTP/1.1 client sends a request which includes a request body, 2321 but which does not include an Expect header field with the "100- 2322 continue" expectation, and if the client is not directly connected to 2323 an HTTP/1.1 origin server, and if the client sees the connection 2324 close before receiving a status line from the server, the client 2325 SHOULD retry the request. If the client does retry this request, it 2326 MAY use the following "binary exponential backoff" algorithm to be 2327 assured of obtaining a reliable response: 2329 1. Initiate a new connection to the server 2331 2. Transmit the request-line, header fields, and the CRLF that 2332 indicates the end of header fields. 2334 3. Initialize a variable R to the estimated round-trip time to the 2335 server (e.g., based on the time it took to establish the 2336 connection), or to a constant value of 5 seconds if the round- 2337 trip time is not available. 2339 4. Compute T = R * (2**N), where N is the number of previous retries 2340 of this request. 2342 5. Wait either for an error response from the server, or for T 2343 seconds (whichever comes first) 2345 6. If no error response is received, after T seconds transmit the 2346 body of the request. 2348 7. If client sees that the connection is closed prematurely, repeat 2349 from step 1 until the request is accepted, an error response is 2350 received, or the user becomes impatient and terminates the retry 2351 process. 2353 If at any point an error status code is received, the client 2355 o SHOULD NOT continue and 2356 o SHOULD close the connection if it has not completed sending the 2357 request message. 2359 8. Miscellaneous notes that might disappear 2361 8.1. Scheme aliases considered harmful 2363 [[TBD-aliases-harmful: describe why aliases like webcal are 2364 harmful.]] 2366 8.2. Use of HTTP for proxy communication 2368 [[TBD-proxy-other: Configured to use HTTP to proxy HTTP or other 2369 protocols.]] 2371 8.3. Interception of HTTP for access control 2373 [[TBD-intercept: Interception of HTTP traffic for initiating access 2374 control.]] 2376 8.4. Use of HTTP by other protocols 2378 [[TBD-profiles: Profiles of HTTP defined by other protocol. 2379 Extensions of HTTP like WebDAV.]] 2381 8.5. Use of HTTP by media type specification 2383 [[TBD-hypertext: Instructions on composing HTTP requests via 2384 hypertext formats.]] 2386 9. Header Field Definitions 2388 This section defines the syntax and semantics of HTTP header fields 2389 related to message framing and transport protocols. 2391 9.1. Connection 2393 The "Connection" header field allows the sender to specify options 2394 that are desired only for that particular connection. Such 2395 connection options MUST be removed or replaced before the message can 2396 be forwarded downstream by a proxy or gateway. This mechanism also 2397 allows the sender to indicate which HTTP header fields used in the 2398 message are only intended for the immediate recipient ("hop-by-hop"), 2399 as opposed to all recipients on the chain ("end-to-end"), enabling 2400 the message to be self-descriptive and allowing future connection- 2401 specific extensions to be deployed in HTTP without fear that they 2402 will be blindly forwarded by previously deployed intermediaries. 2404 The Connection header field's value has the following grammar: 2406 Connection = 1#connection-token 2407 connection-token = token 2409 A proxy or gateway MUST parse a received Connection header field 2410 before a message is forwarded and, for each connection-token in this 2411 field, remove any header field(s) from the message with the same name 2412 as the connection-token, and then remove the Connection header field 2413 itself or replace it with the sender's own connection options for the 2414 forwarded message. 2416 A sender MUST NOT include field-names in the Connection header field- 2417 value for fields that are defined as expressing constraints for all 2418 recipients in the request or response chain, such as the Cache- 2419 Control header field (Section 3.2 of [Part6]). 2421 The connection options do not have to correspond to a header field 2422 present in the message, since a connection-specific header field 2423 might not be needed if there are no parameters associated with that 2424 connection option. Recipients that trigger certain connection 2425 behavior based on the presence of connection options MUST do so based 2426 on the presence of the connection-token rather than only the presence 2427 of the optional header field. In other words, if the connection 2428 option is received as a header field but not indicated within the 2429 Connection field-value, then the recipient MUST ignore the 2430 connection-specific header field because it has likely been forwarded 2431 by an intermediary that is only partially compliant. 2433 When defining new connection options, specifications ought to 2434 carefully consider existing deployed header fields and ensure that 2435 the new connection-token does not share the same name as an unrelated 2436 header field that might already be deployed. Defining a new 2437 connection-token essentially reserves that potential field-name for 2438 carrying additional information related to the connection option, 2439 since it would be unwise for senders to use that field-name for 2440 anything else. 2442 HTTP/1.1 defines the "close" connection option for the sender to 2443 signal that the connection will be closed after completion of the 2444 response. For example, 2446 Connection: close 2448 in either the request or the response header fields indicates that 2449 the connection SHOULD NOT be considered "persistent" (Section 7.1) 2450 after the current request/response is complete. 2452 An HTTP/1.1 client that does not support persistent connections MUST 2453 include the "close" connection option in every request message. 2455 An HTTP/1.1 server that does not support persistent connections MUST 2456 include the "close" connection option in every response message that 2457 does not have a 1xx (Informational) status code. 2459 9.2. Content-Length 2461 The "Content-Length" header field indicates the size of the message- 2462 body, in decimal number of octets, for any message other than a 2463 response to a HEAD request or a response with a status code of 304. 2464 In the case of a response to a HEAD request, Content-Length indicates 2465 the size of the payload body (not including any potential transfer- 2466 coding) that would have been sent had the request been a GET. In the 2467 case of a 304 (Not Modified) response to a GET request, Content- 2468 Length indicates the size of the payload body (not including any 2469 potential transfer-coding) that would have been sent in a 200 (OK) 2470 response. 2472 Content-Length = 1*DIGIT 2474 An example is 2476 Content-Length: 3495 2478 Implementations SHOULD use this field to indicate the message-body 2479 length when no transfer-coding is being applied and the payload's 2480 body length can be determined prior to being transferred. 2481 Section 3.3 describes how recipients determine the length of a 2482 message-body. 2484 Any Content-Length greater than or equal to zero is a valid value. 2486 Note that the use of this field in HTTP is significantly different 2487 from the corresponding definition in MIME, where it is an optional 2488 field used within the "message/external-body" content-type. 2490 9.3. Date 2492 The "Date" header field represents the date and time at which the 2493 message was originated, having the same semantics as the Origination 2494 Date Field (orig-date) defined in Section 3.6.1 of [RFC5322]. The 2495 field value is an HTTP-date, as described in Section 6.1; it MUST be 2496 sent in rfc1123-date format. 2498 Date = HTTP-date 2500 An example is 2502 Date: Tue, 15 Nov 1994 08:12:31 GMT 2504 Origin servers MUST include a Date header field in all responses, 2505 except in these cases: 2507 1. If the response status code is 100 (Continue) or 101 (Switching 2508 Protocols), the response MAY include a Date header field, at the 2509 server's option. 2511 2. If the response status code conveys a server error, e.g., 500 2512 (Internal Server Error) or 503 (Service Unavailable), and it is 2513 inconvenient or impossible to generate a valid Date. 2515 3. If the server does not have a clock that can provide a reasonable 2516 approximation of the current time, its responses MUST NOT include 2517 a Date header field. In this case, the rules in Section 9.3.1 2518 MUST be followed. 2520 A received message that does not have a Date header field MUST be 2521 assigned one by the recipient if the message will be cached by that 2522 recipient. 2524 Clients can use the Date header field as well; in order to keep 2525 request messages small, they are advised not to include it when it 2526 doesn't convey any useful information (as it is usually the case for 2527 requests that do not contain a payload). 2529 The HTTP-date sent in a Date header field SHOULD NOT represent a date 2530 and time subsequent to the generation of the message. It SHOULD 2531 represent the best available approximation of the date and time of 2532 message generation, unless the implementation has no means of 2533 generating a reasonably accurate date and time. In theory, the date 2534 ought to represent the moment just before the payload is generated. 2535 In practice, the date can be generated at any time during the message 2536 origination without affecting its semantic value. 2538 9.3.1. Clockless Origin Server Operation 2540 Some origin server implementations might not have a clock available. 2541 An origin server without a clock MUST NOT assign Expires or Last- 2542 Modified values to a response, unless these values were associated 2543 with the resource by a system or user with a reliable clock. It MAY 2544 assign an Expires value that is known, at or before server 2545 configuration time, to be in the past (this allows "pre-expiration" 2546 of responses without storing separate Expires values for each 2547 resource). 2549 9.4. Host 2551 The "Host" header field in a request provides the host and port 2552 information from the target resource's URI, enabling the origin 2553 server to distinguish between resources while servicing requests for 2554 multiple host names on a single IP address. Since the Host field- 2555 value is critical information for handling a request, it SHOULD be 2556 sent as the first header field following the Request-Line. 2558 Host = uri-host [ ":" port ] ; Section 2.7.1 2560 A client MUST send a Host header field in all HTTP/1.1 request 2561 messages. If the target resource's URI includes an authority 2562 component, then the Host field-value MUST be identical to that 2563 authority component after excluding any userinfo (Section 2.7.1). If 2564 the authority component is missing or undefined for the target 2565 resource's URI, then the Host header field MUST be sent with an empty 2566 field-value. 2568 For example, a GET request to the origin server for 2569 would begin with: 2571 GET /pub/WWW/ HTTP/1.1 2572 Host: www.example.org 2574 The Host header field MUST be sent in an HTTP/1.1 request even if the 2575 request-target is in the form of an absolute-URI, since this allows 2576 the Host information to be forwarded through ancient HTTP/1.0 proxies 2577 that might not have implemented Host. 2579 When an HTTP/1.1 proxy receives a request with a request-target in 2580 the form of an absolute-URI, the proxy MUST ignore the received Host 2581 header field (if any) and instead replace it with the host 2582 information of the request-target. When a proxy forwards a request, 2583 it MUST generate the Host header field based on the received 2584 absolute-URI rather than the received Host. 2586 Since the Host header field acts as an application-level routing 2587 mechanism, it is a frequent target for malware seeking to poison a 2588 shared cache or redirect a request to an unintended server. An 2589 interception proxy is particularly vulnerable if it relies on the 2590 Host header field value for redirecting requests to internal servers, 2591 or for use as a cache key in a shared cache, without first verifying 2592 that the intercepted connection is targeting a valid IP address for 2593 that host. 2595 A server MUST respond with a 400 (Bad Request) status code to any 2596 HTTP/1.1 request message that lacks a Host header field and to any 2597 request message that contains more than one Host header field or a 2598 Host header field with an invalid field-value. 2600 See Sections 4.2 and B.1.1 for other requirements relating to Host. 2602 9.5. TE 2604 The "TE" header field indicates what extension transfer-codings it is 2605 willing to accept in the response, and whether or not it is willing 2606 to accept trailer fields in a chunked transfer-coding. 2608 Its value consists of the keyword "trailers" and/or a comma-separated 2609 list of extension transfer-coding names with optional accept 2610 parameters (as described in Section 6.2). 2612 TE = #t-codings 2613 t-codings = "trailers" / ( transfer-extension [ te-params ] ) 2614 te-params = OWS ";" OWS "q=" qvalue *( te-ext ) 2615 te-ext = OWS ";" OWS token [ "=" word ] 2617 The presence of the keyword "trailers" indicates that the client is 2618 willing to accept trailer fields in a chunked transfer-coding, as 2619 defined in Section 6.2.1. This keyword is reserved for use with 2620 transfer-coding values even though it does not itself represent a 2621 transfer-coding. 2623 Examples of its use are: 2625 TE: deflate 2626 TE: 2627 TE: trailers, deflate;q=0.5 2629 The TE header field only applies to the immediate connection. 2630 Therefore, the keyword MUST be supplied within a Connection header 2631 field (Section 9.1) whenever TE is present in an HTTP/1.1 message. 2633 A server tests whether a transfer-coding is acceptable, according to 2634 a TE field, using these rules: 2636 1. The "chunked" transfer-coding is always acceptable. If the 2637 keyword "trailers" is listed, the client indicates that it is 2638 willing to accept trailer fields in the chunked response on 2639 behalf of itself and any downstream clients. The implication is 2640 that, if given, the client is stating that either all downstream 2641 clients are willing to accept trailer fields in the forwarded 2642 response, or that it will attempt to buffer the response on 2643 behalf of downstream recipients. 2645 Note: HTTP/1.1 does not define any means to limit the size of a 2646 chunked response such that a client can be assured of buffering 2647 the entire response. 2649 2. If the transfer-coding being tested is one of the transfer- 2650 codings listed in the TE field, then it is acceptable unless it 2651 is accompanied by a qvalue of 0. (As defined in Section 6.4, a 2652 qvalue of 0 means "not acceptable".) 2654 3. If multiple transfer-codings are acceptable, then the acceptable 2655 transfer-coding with the highest non-zero qvalue is preferred. 2656 The "chunked" transfer-coding always has a qvalue of 1. 2658 If the TE field-value is empty or if no TE field is present, the only 2659 transfer-coding is "chunked". A message with no transfer-coding is 2660 always acceptable. 2662 9.6. Trailer 2664 The "Trailer" header field indicates that the given set of header 2665 fields is present in the trailer of a message encoded with chunked 2666 transfer-coding. 2668 Trailer = 1#field-name 2670 An HTTP/1.1 message SHOULD include a Trailer header field in a 2671 message using chunked transfer-coding with a non-empty trailer. 2672 Doing so allows the recipient to know which header fields to expect 2673 in the trailer. 2675 If no Trailer header field is present, the trailer SHOULD NOT include 2676 any header fields. See Section 6.2.1 for restrictions on the use of 2677 trailer fields in a "chunked" transfer-coding. 2679 Message header fields listed in the Trailer header field MUST NOT 2680 include the following header fields: 2682 o Transfer-Encoding 2684 o Content-Length 2686 o Trailer 2688 9.7. Transfer-Encoding 2690 The "Transfer-Encoding" header field indicates what transfer-codings 2691 (if any) have been applied to the message body. It differs from 2692 Content-Encoding (Section 2.2 of [Part3]) in that transfer-codings 2693 are a property of the message (and therefore are removed by 2694 intermediaries), whereas content-codings are not. 2696 Transfer-Encoding = 1#transfer-coding 2698 Transfer-codings are defined in Section 6.2. An example is: 2700 Transfer-Encoding: chunked 2702 If multiple encodings have been applied to a representation, the 2703 transfer-codings MUST be listed in the order in which they were 2704 applied. Additional information about the encoding parameters MAY be 2705 provided by other header fields not defined by this specification. 2707 Many older HTTP/1.0 applications do not understand the Transfer- 2708 Encoding header field. 2710 9.8. Upgrade 2712 The "Upgrade" header field allows the client to specify what 2713 additional communication protocols it would like to use, if the 2714 server chooses to switch protocols. Servers can use it to indicate 2715 what protocols they are willing to switch to. 2717 Upgrade = 1#product 2719 For example, 2721 Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11 2723 The Upgrade header field is intended to provide a simple mechanism 2724 for transition from HTTP/1.1 to some other, incompatible protocol. 2725 It does so by allowing the client to advertise its desire to use 2726 another protocol, such as a later version of HTTP with a higher major 2727 version number, even though the current request has been made using 2728 HTTP/1.1. This eases the difficult transition between incompatible 2729 protocols by allowing the client to initiate a request in the more 2730 commonly supported protocol while indicating to the server that it 2731 would like to use a "better" protocol if available (where "better" is 2732 determined by the server, possibly according to the nature of the 2733 request method or target resource). 2735 The Upgrade header field only applies to switching application-layer 2736 protocols upon the existing transport-layer connection. Upgrade 2737 cannot be used to insist on a protocol change; its acceptance and use 2738 by the server is optional. The capabilities and nature of the 2739 application-layer communication after the protocol change is entirely 2740 dependent upon the new protocol chosen, although the first action 2741 after changing the protocol MUST be a response to the initial HTTP 2742 request containing the Upgrade header field. 2744 The Upgrade header field only applies to the immediate connection. 2745 Therefore, the upgrade keyword MUST be supplied within a Connection 2746 header field (Section 9.1) whenever Upgrade is present in an HTTP/1.1 2747 message. 2749 The Upgrade header field cannot be used to indicate a switch to a 2750 protocol on a different connection. For that purpose, it is more 2751 appropriate to use a 3xx redirection response (Section 8.3 of 2752 [Part2]). 2754 Servers MUST include the "Upgrade" header field in 101 (Switching 2755 Protocols) responses to indicate which protocol(s) are being switched 2756 to, and MUST include it in 426 (Upgrade Required) responses to 2757 indicate acceptable protocols to upgrade to. Servers MAY include it 2758 in any other response to indicate that they are willing to upgrade to 2759 one of the specified protocols. 2761 This specification only defines the protocol name "HTTP" for use by 2762 the family of Hypertext Transfer Protocols, as defined by the HTTP 2763 version rules of Section 2.6 and future updates to this 2764 specification. Additional tokens can be registered with IANA using 2765 the registration procedure defined below. 2767 9.8.1. Upgrade Token Registry 2769 The HTTP Upgrade Token Registry defines the name space for product 2770 tokens used to identify protocols in the Upgrade header field. Each 2771 registered token is associated with contact information and an 2772 optional set of specifications that details how the connection will 2773 be processed after it has been upgraded. 2775 Registrations are allowed on a First Come First Served basis as 2776 described in Section 4.1 of [RFC5226]. The specifications need not 2777 be IETF documents or be subject to IESG review. Registrations are 2778 subject to the following rules: 2780 1. A token, once registered, stays registered forever. 2782 2. The registration MUST name a responsible party for the 2783 registration. 2785 3. The registration MUST name a point of contact. 2787 4. The registration MAY name a set of specifications associated with 2788 that token. Such specifications need not be publicly available. 2790 5. The responsible party MAY change the registration at any time. 2791 The IANA will keep a record of all such changes, and make them 2792 available upon request. 2794 6. The responsible party for the first registration of a "product" 2795 token MUST approve later registrations of a "version" token 2796 together with that "product" token before they can be registered. 2798 7. If absolutely required, the IESG MAY reassign the responsibility 2799 for a token. This will normally only be used in the case when a 2800 responsible party cannot be contacted. 2802 9.9. Via 2804 The "Via" header field MUST be sent by a proxy or gateway to indicate 2805 the intermediate protocols and recipients between the user agent and 2806 the server on requests, and between the origin server and the client 2807 on responses. It is analogous to the "Received" field used by email 2808 systems (Section 3.6.7 of [RFC5322]) and is intended to be used for 2809 tracking message forwards, avoiding request loops, and identifying 2810 the protocol capabilities of all senders along the request/response 2811 chain. 2813 Via = 1#( received-protocol RWS received-by 2814 [ RWS comment ] ) 2815 received-protocol = [ protocol-name "/" ] protocol-version 2816 protocol-name = token 2817 protocol-version = token 2818 received-by = ( uri-host [ ":" port ] ) / pseudonym 2819 pseudonym = token 2821 The received-protocol indicates the protocol version of the message 2822 received by the server or client along each segment of the request/ 2823 response chain. The received-protocol version is appended to the Via 2824 field value when the message is forwarded so that information about 2825 the protocol capabilities of upstream applications remains visible to 2826 all recipients. 2828 The protocol-name is excluded if and only if it would be "HTTP". The 2829 received-by field is normally the host and optional port number of a 2830 recipient server or client that subsequently forwarded the message. 2831 However, if the real host is considered to be sensitive information, 2832 it MAY be replaced by a pseudonym. If the port is not given, it MAY 2833 be assumed to be the default port of the received-protocol. 2835 Multiple Via field values represent each proxy or gateway that has 2836 forwarded the message. Each recipient MUST append its information 2837 such that the end result is ordered according to the sequence of 2838 forwarding applications. 2840 Comments MAY be used in the Via header field to identify the software 2841 of each recipient, analogous to the User-Agent and Server header 2842 fields. However, all comments in the Via field are optional and MAY 2843 be removed by any recipient prior to forwarding the message. 2845 For example, a request message could be sent from an HTTP/1.0 user 2846 agent to an internal proxy code-named "fred", which uses HTTP/1.1 to 2847 forward the request to a public proxy at p.example.net, which 2848 completes the request by forwarding it to the origin server at 2849 www.example.com. The request received by www.example.com would then 2850 have the following Via header field: 2852 Via: 1.0 fred, 1.1 p.example.net (Apache/1.1) 2854 A proxy or gateway used as a portal through a network firewall SHOULD 2855 NOT forward the names and ports of hosts within the firewall region 2856 unless it is explicitly enabled to do so. If not enabled, the 2857 received-by host of any host behind the firewall SHOULD be replaced 2858 by an appropriate pseudonym for that host. 2860 For organizations that have strong privacy requirements for hiding 2861 internal structures, a proxy or gateway MAY combine an ordered 2862 subsequence of Via header field entries with identical received- 2863 protocol values into a single such entry. For example, 2865 Via: 1.0 ricky, 1.1 ethel, 1.1 fred, 1.0 lucy 2867 could be collapsed to 2869 Via: 1.0 ricky, 1.1 mertz, 1.0 lucy 2871 Senders SHOULD NOT combine multiple entries unless they are all under 2872 the same organizational control and the hosts have already been 2873 replaced by pseudonyms. Senders MUST NOT combine entries which have 2874 different received-protocol values. 2876 10. IANA Considerations 2878 10.1. Header Field Registration 2880 The Message Header Field Registry located at shall be 2882 updated with the permanent registrations below (see [RFC3864]): 2884 +-------------------+----------+----------+-------------+ 2885 | Header Field Name | Protocol | Status | Reference | 2886 +-------------------+----------+----------+-------------+ 2887 | Connection | http | standard | Section 9.1 | 2888 | Content-Length | http | standard | Section 9.2 | 2889 | Date | http | standard | Section 9.3 | 2890 | Host | http | standard | Section 9.4 | 2891 | TE | http | standard | Section 9.5 | 2892 | Trailer | http | standard | Section 9.6 | 2893 | Transfer-Encoding | http | standard | Section 9.7 | 2894 | Upgrade | http | standard | Section 9.8 | 2895 | Via | http | standard | Section 9.9 | 2896 +-------------------+----------+----------+-------------+ 2898 The change controller is: "IETF (iesg@ietf.org) - Internet 2899 Engineering Task Force". 2901 10.2. URI Scheme Registration 2903 The entries for the "http" and "https" URI Schemes in the registry 2904 located at shall 2905 be updated to point to Sections 2.7.1 and 2.7.2 of this document (see 2906 [RFC4395]). 2908 10.3. Internet Media Type Registrations 2910 This document serves as the specification for the Internet media 2911 types "message/http" and "application/http". The following is to be 2912 registered with IANA (see [RFC4288]). 2914 10.3.1. Internet Media Type message/http 2916 The message/http type can be used to enclose a single HTTP request or 2917 response message, provided that it obeys the MIME restrictions for 2918 all "message" types regarding line length and encodings. 2920 Type name: message 2922 Subtype name: http 2924 Required parameters: none 2926 Optional parameters: version, msgtype 2928 version: The HTTP-Version number of the enclosed message (e.g., 2929 "1.1"). If not present, the version can be determined from the 2930 first line of the body. 2932 msgtype: The message type -- "request" or "response". If not 2933 present, the type can be determined from the first line of the 2934 body. 2936 Encoding considerations: only "7bit", "8bit", or "binary" are 2937 permitted 2939 Security considerations: none 2941 Interoperability considerations: none 2943 Published specification: This specification (see Section 10.3.1). 2945 Applications that use this media type: 2947 Additional information: 2949 Magic number(s): none 2951 File extension(s): none 2953 Macintosh file type code(s): none 2955 Person and email address to contact for further information: See 2956 Authors Section. 2958 Intended usage: COMMON 2960 Restrictions on usage: none 2962 Author/Change controller: IESG 2964 10.3.2. Internet Media Type application/http 2966 The application/http type can be used to enclose a pipeline of one or 2967 more HTTP request or response messages (not intermixed). 2969 Type name: application 2971 Subtype name: http 2973 Required parameters: none 2975 Optional parameters: version, msgtype 2976 version: The HTTP-Version number of the enclosed messages (e.g., 2977 "1.1"). If not present, the version can be determined from the 2978 first line of the body. 2980 msgtype: The message type -- "request" or "response". If not 2981 present, the type can be determined from the first line of the 2982 body. 2984 Encoding considerations: HTTP messages enclosed by this type are in 2985 "binary" format; use of an appropriate Content-Transfer-Encoding 2986 is required when transmitted via E-mail. 2988 Security considerations: none 2990 Interoperability considerations: none 2992 Published specification: This specification (see Section 10.3.2). 2994 Applications that use this media type: 2996 Additional information: 2998 Magic number(s): none 3000 File extension(s): none 3002 Macintosh file type code(s): none 3004 Person and email address to contact for further information: See 3005 Authors Section. 3007 Intended usage: COMMON 3009 Restrictions on usage: none 3011 Author/Change controller: IESG 3013 10.4. Transfer Coding Registry 3015 The registration procedure for HTTP Transfer Codings is now defined 3016 by Section 6.2.3 of this document. 3018 The HTTP Transfer Codings Registry located at 3019 shall be updated 3020 with the registrations below: 3022 +----------+--------------------------------------+-----------------+ 3023 | Name | Description | Reference | 3024 +----------+--------------------------------------+-----------------+ 3025 | chunked | Transfer in a series of chunks | Section 6.2.1 | 3026 | compress | UNIX "compress" program method | Section 6.2.2.1 | 3027 | deflate | "deflate" compression mechanism | Section 6.2.2.2 | 3028 | | ([RFC1951]) used inside the "zlib" | | 3029 | | data format ([RFC1950]) | | 3030 | gzip | Same as GNU zip [RFC1952] | Section 6.2.2.3 | 3031 +----------+--------------------------------------+-----------------+ 3033 10.5. Upgrade Token Registration 3035 The registration procedure for HTTP Upgrade Tokens -- previously 3036 defined in Section 7.2 of [RFC2817] -- is now defined by 3037 Section 9.8.1 of this document. 3039 The HTTP Status Code Registry located at 3040 shall be 3041 updated with the registration below: 3043 +-------+---------------------------+-------------------------------+ 3044 | Value | Description | Reference | 3045 +-------+---------------------------+-------------------------------+ 3046 | HTTP | Hypertext Transfer | Section 2.6 of this | 3047 | | Protocol | specification | 3048 +-------+---------------------------+-------------------------------+ 3050 11. Security Considerations 3052 This section is meant to inform application developers, information 3053 providers, and users of the security limitations in HTTP/1.1 as 3054 described by this document. The discussion does not include 3055 definitive solutions to the problems revealed, though it does make 3056 some suggestions for reducing security risks. 3058 11.1. Personal Information 3060 HTTP clients are often privy to large amounts of personal information 3061 (e.g., the user's name, location, mail address, passwords, encryption 3062 keys, etc.), and SHOULD be very careful to prevent unintentional 3063 leakage of this information. We very strongly recommend that a 3064 convenient interface be provided for the user to control 3065 dissemination of such information, and that designers and 3066 implementors be particularly careful in this area. History shows 3067 that errors in this area often create serious security and/or privacy 3068 problems and generate highly adverse publicity for the implementor's 3069 company. 3071 11.2. Abuse of Server Log Information 3073 A server is in the position to save personal data about a user's 3074 requests which might identify their reading patterns or subjects of 3075 interest. This information is clearly confidential in nature and its 3076 handling can be constrained by law in certain countries. People 3077 using HTTP to provide data are responsible for ensuring that such 3078 material is not distributed without the permission of any individuals 3079 that are identifiable by the published results. 3081 11.3. Attacks Based On File and Path Names 3083 Implementations of HTTP origin servers SHOULD be careful to restrict 3084 the documents returned by HTTP requests to be only those that were 3085 intended by the server administrators. If an HTTP server translates 3086 HTTP URIs directly into file system calls, the server MUST take 3087 special care not to serve files that were not intended to be 3088 delivered to HTTP clients. For example, UNIX, Microsoft Windows, and 3089 other operating systems use ".." as a path component to indicate a 3090 directory level above the current one. On such a system, an HTTP 3091 server MUST disallow any such construct in the request-target if it 3092 would otherwise allow access to a resource outside those intended to 3093 be accessible via the HTTP server. Similarly, files intended for 3094 reference only internally to the server (such as access control 3095 files, configuration files, and script code) MUST be protected from 3096 inappropriate retrieval, since they might contain sensitive 3097 information. Experience has shown that minor bugs in such HTTP 3098 server implementations have turned into security risks. 3100 11.4. DNS Spoofing 3102 Clients using HTTP rely heavily on the Domain Name Service, and are 3103 thus generally prone to security attacks based on the deliberate mis- 3104 association of IP addresses and DNS names. Clients need to be 3105 cautious in assuming the continuing validity of an IP number/DNS name 3106 association. 3108 In particular, HTTP clients SHOULD rely on their name resolver for 3109 confirmation of an IP number/DNS name association, rather than 3110 caching the result of previous host name lookups. Many platforms 3111 already can cache host name lookups locally when appropriate, and 3112 they SHOULD be configured to do so. It is proper for these lookups 3113 to be cached, however, only when the TTL (Time To Live) information 3114 reported by the name server makes it likely that the cached 3115 information will remain useful. 3117 If HTTP clients cache the results of host name lookups in order to 3118 achieve a performance improvement, they MUST observe the TTL 3119 information reported by DNS. 3121 If HTTP clients do not observe this rule, they could be spoofed when 3122 a previously-accessed server's IP address changes. As network 3123 renumbering is expected to become increasingly common [RFC1900], the 3124 possibility of this form of attack will grow. Observing this 3125 requirement thus reduces this potential security vulnerability. 3127 This requirement also improves the load-balancing behavior of clients 3128 for replicated servers using the same DNS name and reduces the 3129 likelihood of a user's experiencing failure in accessing sites which 3130 use that strategy. 3132 11.5. Proxies and Caching 3134 By their very nature, HTTP proxies are men-in-the-middle, and 3135 represent an opportunity for man-in-the-middle attacks. Compromise 3136 of the systems on which the proxies run can result in serious 3137 security and privacy problems. Proxies have access to security- 3138 related information, personal information about individual users and 3139 organizations, and proprietary information belonging to users and 3140 content providers. A compromised proxy, or a proxy implemented or 3141 configured without regard to security and privacy considerations, 3142 might be used in the commission of a wide range of potential attacks. 3144 Proxy operators need to protect the systems on which proxies run as 3145 they would protect any system that contains or transports sensitive 3146 information. In particular, log information gathered at proxies 3147 often contains highly sensitive personal information, and/or 3148 information about organizations. Log information needs to be 3149 carefully guarded, and appropriate guidelines for use need to be 3150 developed and followed. (Section 11.2). 3152 Proxy implementors need to consider the privacy and security 3153 implications of their design and coding decisions, and of the 3154 configuration options they provide to proxy operators (especially the 3155 default configuration). 3157 Users of a proxy need to be aware that proxies are no trustworthier 3158 than the people who run them; HTTP itself cannot solve this problem. 3160 The judicious use of cryptography, when appropriate, might suffice to 3161 protect against a broad range of security and privacy attacks. Such 3162 cryptography is beyond the scope of the HTTP/1.1 specification. 3164 11.6. Protocol Element Size Overflows 3166 Because HTTP uses mostly textual, character-delimited fields, 3167 attackers can overflow buffers in implementations, and/or perform a 3168 Denial of Service against implementations that accept fields with 3169 unlimited lengths. 3171 To promote interoperability, this specification makes specific 3172 recommendations for size limits on request-targets (Section 4.1.2) 3173 and blocks of header fields (Section 3.2). These are minimum 3174 recommendations, chosen to be supportable even by implementations 3175 with limited resources; it is expected that most implementations will 3176 choose substantially higher limits. 3178 This specification also provides a way for servers to reject messages 3179 that have request-targets that are too long (Section 8.4.15 of 3180 [Part2]) or request entities that are too large (Section 8.4 of 3181 [Part2]). 3183 Other fields (including but not limited to request methods, response 3184 status phrases, header field-names, and body chunks) SHOULD be 3185 limited by implementations carefully, so as to not impede 3186 interoperability. 3188 11.7. Denial of Service Attacks on Proxies 3190 They exist. They are hard to defend against. Research continues. 3191 Beware. 3193 12. Acknowledgments 3195 HTTP has evolved considerably over the years. It has benefited from 3196 a large and active developer community -- the many people who have 3197 participated on the www-talk mailing list -- and it is that community 3198 which has been most responsible for the success of HTTP and of the 3199 World-Wide Web in general. Marc Andreessen, Robert Cailliau, Daniel 3200 W. Connolly, Bob Denny, John Franks, Jean-Francois Groff, Phillip M. 3201 Hallam-Baker, Hakon W. Lie, Ari Luotonen, Rob McCool, Lou Montulli, 3202 Dave Raggett, Tony Sanders, and Marc VanHeyningen deserve special 3203 recognition for their efforts in defining early aspects of the 3204 protocol. 3206 This document has benefited greatly from the comments of all those 3207 participating in the HTTP-WG. In addition to those already 3208 mentioned, the following individuals have contributed to this 3209 specification: 3211 Gary Adams, Harald Tveit Alvestrand, Keith Ball, Brian Behlendorf, 3212 Paul Burchard, Maurizio Codogno, Josh Cohen, Mike Cowlishaw, Roman 3213 Czyborra, Michael A. Dolan, Daniel DuBois, David J. Fiander, Alan 3214 Freier, Marc Hedlund, Greg Herlihy, Koen Holtman, Alex Hopmann, Bob 3215 Jernigan, Shel Kaphan, Rohit Khare, John Klensin, Martijn Koster, 3216 Alexei Kosut, David M. Kristol, Daniel LaLiberte, Ben Laurie, Paul J. 3217 Leach, Albert Lunde, John C. Mallery, Jean-Philippe Martin-Flatin, 3218 Mitra, David Morris, Gavin Nicol, Ross Patterson, Bill Perry, Jeffrey 3219 Perry, Scott Powers, Owen Rees, Luigi Rizzo, David Robinson, Marc 3220 Salomon, Rich Salz, Allan M. Schiffman, Jim Seidman, Chuck Shotton, 3221 Eric W. Sink, Simon E. Spero, Richard N. Taylor, Robert S. Thau, Bill 3222 (BearHeart) Weinman, Francois Yergeau, Mary Ellen Zurko. 3224 Thanks to the "cave men" of Palo Alto. You know who you are. 3226 Jim Gettys (the editor of [RFC2616]) wishes particularly to thank Roy 3227 Fielding, the editor of [RFC2068], along with John Klensin, Jeff 3228 Mogul, Paul Leach, Dave Kristol, Koen Holtman, John Franks, Josh 3229 Cohen, Alex Hopmann, Scott Lawrence, and Larry Masinter for their 3230 help. And thanks go particularly to Jeff Mogul and Scott Lawrence 3231 for performing the "MUST/MAY/SHOULD" audit. 3233 The Apache Group, Anselm Baird-Smith, author of Jigsaw, and Henrik 3234 Frystyk implemented RFC 2068 early, and we wish to thank them for the 3235 discovery of many of the problems that this document attempts to 3236 rectify. 3238 This specification makes heavy use of the augmented BNF and generic 3239 constructs defined by David H. Crocker for [RFC5234]. Similarly, it 3240 reuses many of the definitions provided by Nathaniel Borenstein and 3241 Ned Freed for MIME [RFC2045]. We hope that their inclusion in this 3242 specification will help reduce past confusion over the relationship 3243 between HTTP and Internet mail message formats. 3245 13. References 3247 13.1. Normative References 3249 [ISO-8859-1] International Organization for Standardization, 3250 "Information technology -- 8-bit single-byte coded 3251 graphic character sets -- Part 1: Latin alphabet No. 3252 1", ISO/IEC 8859-1:1998, 1998. 3254 [Part2] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., 3255 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., 3256 Ed., and J. Reschke, Ed., "HTTP/1.1, part 2: Message 3257 Semantics", draft-ietf-httpbis-p2-semantics-15 (work in 3258 progress), July 2011. 3260 [Part3] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., 3261 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., 3262 Ed., and J. Reschke, Ed., "HTTP/1.1, part 3: Message 3263 Payload and Content Negotiation", 3264 draft-ietf-httpbis-p3-payload-15 (work in progress), 3265 July 2011. 3267 [Part6] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., 3268 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., 3269 Ed., Nottingham, M., Ed., and J. Reschke, Ed., 3270 "HTTP/1.1, part 6: Caching", 3271 draft-ietf-httpbis-p6-cache-15 (work in progress), 3272 July 2011. 3274 [RFC1950] Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data 3275 Format Specification version 3.3", RFC 1950, May 1996. 3277 RFC 1950 is an Informational RFC, thus it might be less 3278 stable than this specification. On the other hand, 3279 this downward reference was present since the 3280 publication of RFC 2068 in 1997 ([RFC2068]), therefore 3281 it is unlikely to cause problems in practice. See also 3282 [BCP97]. 3284 [RFC1951] Deutsch, P., "DEFLATE Compressed Data Format 3285 Specification version 1.3", RFC 1951, May 1996. 3287 RFC 1951 is an Informational RFC, thus it might be less 3288 stable than this specification. On the other hand, 3289 this downward reference was present since the 3290 publication of RFC 2068 in 1997 ([RFC2068]), therefore 3291 it is unlikely to cause problems in practice. See also 3292 [BCP97]. 3294 [RFC1952] Deutsch, P., Gailly, J-L., Adler, M., Deutsch, L., and 3295 G. Randers-Pehrson, "GZIP file format specification 3296 version 4.3", RFC 1952, May 1996. 3298 RFC 1952 is an Informational RFC, thus it might be less 3299 stable than this specification. On the other hand, 3300 this downward reference was present since the 3301 publication of RFC 2068 in 1997 ([RFC2068]), therefore 3302 it is unlikely to cause problems in practice. See also 3303 [BCP97]. 3305 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3306 Requirement Levels", BCP 14, RFC 2119, March 1997. 3308 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, 3309 "Uniform Resource Identifier (URI): Generic Syntax", 3310 STD 66, RFC 3986, January 2005. 3312 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for 3313 Syntax Specifications: ABNF", STD 68, RFC 5234, 3314 January 2008. 3316 [USASCII] American National Standards Institute, "Coded Character 3317 Set -- 7-bit American Standard Code for Information 3318 Interchange", ANSI X3.4, 1986. 3320 13.2. Informative References 3322 [BCP97] Klensin, J. and S. Hartman, "Handling Normative 3323 References to Standards-Track Documents", BCP 97, 3324 RFC 4897, June 2007. 3326 [Kri2001] Kristol, D., "HTTP Cookies: Standards, Privacy, and 3327 Politics", ACM Transactions on Internet Technology Vol. 3328 1, #2, November 2001, 3329 . 3331 [Nie1997] Frystyk, H., Gettys, J., Prud'hommeaux, E., Lie, H., 3332 and C. Lilley, "Network Performance Effects of 3333 HTTP/1.1, CSS1, and PNG", ACM Proceedings of the ACM 3334 SIGCOMM '97 conference on Applications, technologies, 3335 architectures, and protocols for computer communication 3336 SIGCOMM '97, September 1997, 3337 . 3339 [Pad1995] Padmanabhan, V. and J. Mogul, "Improving HTTP Latency", 3340 Computer Networks and ISDN Systems v. 28, pp. 25-35, 3341 December 1995, 3342 . 3344 [RFC1123] Braden, R., "Requirements for Internet Hosts - 3345 Application and Support", STD 3, RFC 1123, 3346 October 1989. 3348 [RFC1900] Carpenter, B. and Y. Rekhter, "Renumbering Needs Work", 3349 RFC 1900, February 1996. 3351 [RFC1919] Chatel, M., "Classical versus Transparent IP Proxies", 3352 RFC 1919, March 1996. 3354 [RFC1945] Berners-Lee, T., Fielding, R., and H. Nielsen, 3355 "Hypertext Transfer Protocol -- HTTP/1.0", RFC 1945, 3356 May 1996. 3358 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet 3359 Mail Extensions (MIME) Part One: Format of Internet 3360 Message Bodies", RFC 2045, November 1996. 3362 [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail 3363 Extensions) Part Three: Message Header Extensions for 3364 Non-ASCII Text", RFC 2047, November 1996. 3366 [RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and 3367 T. Berners-Lee, "Hypertext Transfer Protocol -- 3368 HTTP/1.1", RFC 2068, January 1997. 3370 [RFC2145] Mogul, J., Fielding, R., Gettys, J., and H. Nielsen, 3371 "Use and Interpretation of HTTP Version Numbers", 3372 RFC 2145, May 1997. 3374 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 3375 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 3376 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 3378 [RFC2817] Khare, R. and S. Lawrence, "Upgrading to TLS Within 3379 HTTP/1.1", RFC 2817, May 2000. 3381 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 3383 [RFC2965] Kristol, D. and L. Montulli, "HTTP State Management 3384 Mechanism", RFC 2965, October 2000. 3386 [RFC3040] Cooper, I., Melve, I., and G. Tomlinson, "Internet Web 3387 Replication and Caching Taxonomy", RFC 3040, 3388 January 2001. 3390 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration 3391 Procedures for Message Header Fields", BCP 90, 3392 RFC 3864, September 2004. 3394 [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications 3395 and Registration Procedures", BCP 13, RFC 4288, 3396 December 2005. 3398 [RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines 3399 and Registration Procedures for New URI Schemes", 3400 BCP 115, RFC 4395, February 2006. 3402 [RFC4559] Jaganathan, K., Zhu, L., and J. Brezak, "SPNEGO-based 3403 Kerberos and NTLM HTTP Authentication in Microsoft 3404 Windows", RFC 4559, June 2006. 3406 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing 3407 an IANA Considerations Section in RFCs", BCP 26, 3408 RFC 5226, May 2008. 3410 [RFC5322] Resnick, P., "Internet Message Format", RFC 5322, 3411 October 2008. 3413 [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, 3414 April 2011. 3416 [Spe] Spero, S., "Analysis of HTTP Performance Problems", 3417 . 3419 [Tou1998] Touch, J., Heidemann, J., and K. Obraczka, "Analysis of 3420 HTTP Performance", ISI Research Report ISI/RR-98-463, 3421 Aug 1998, . 3423 (original report dated Aug. 1996) 3425 Appendix A. Tolerant Applications 3427 Although this document specifies the requirements for the generation 3428 of HTTP/1.1 messages, not all applications will be correct in their 3429 implementation. We therefore recommend that operational applications 3430 be tolerant of deviations whenever those deviations can be 3431 interpreted unambiguously. 3433 The line terminator for header fields is the sequence CRLF. However, 3434 we recommend that applications, when parsing such headers fields, 3435 recognize a single LF as a line terminator and ignore the leading CR. 3437 The character encoding of a representation SHOULD be labeled as the 3438 lowest common denominator of the character codes used within that 3439 representation, with the exception that not labeling the 3440 representation is preferred over labeling the representation with the 3441 labels US-ASCII or ISO-8859-1. See [Part3]. 3443 Additional rules for requirements on parsing and encoding of dates 3444 and other potential problems with date encodings include: 3446 o HTTP/1.1 clients and caches SHOULD assume that an RFC-850 date 3447 which appears to be more than 50 years in the future is in fact in 3448 the past (this helps solve the "year 2000" problem). 3450 o Although all date formats are specified to be case-sensitive, 3451 recipients SHOULD match day, week and timezone names case- 3452 insensitively. 3454 o An HTTP/1.1 implementation MAY internally represent a parsed 3455 Expires date as earlier than the proper value, but MUST NOT 3456 internally represent a parsed Expires date as later than the 3457 proper value. 3459 o All expiration-related calculations MUST be done in GMT. The 3460 local time zone MUST NOT influence the calculation or comparison 3461 of an age or expiration time. 3463 o If an HTTP header field incorrectly carries a date value with a 3464 time zone other than GMT, it MUST be converted into GMT using the 3465 most conservative possible conversion. 3467 Appendix B. HTTP Version History 3469 HTTP has been in use by the World-Wide Web global information 3470 initiative since 1990. The first version of HTTP, later referred to 3471 as HTTP/0.9, was a simple protocol for hypertext data transfer across 3472 the Internet with only a single request method (GET) and no metadata. 3473 HTTP/1.0, as defined by [RFC1945], added a range of request methods 3474 and MIME-like messaging that could include metadata about the data 3475 transferred and modifiers on the request/response semantics. 3476 However, HTTP/1.0 did not sufficiently take into consideration the 3477 effects of hierarchical proxies, caching, the need for persistent 3478 connections, or name-based virtual hosts. The proliferation of 3479 incompletely-implemented applications calling themselves "HTTP/1.0" 3480 further necessitated a protocol version change in order for two 3481 communicating applications to determine each other's true 3482 capabilities. 3484 HTTP/1.1 remains compatible with HTTP/1.0 by including more stringent 3485 requirements that enable reliable implementations, adding only those 3486 new features that will either be safely ignored by an HTTP/1.0 3487 recipient or only sent when communicating with a party advertising 3488 compliance with HTTP/1.1. 3490 It is beyond the scope of a protocol specification to mandate 3491 compliance with previous versions. HTTP/1.1 was deliberately 3492 designed, however, to make supporting previous versions easy. We 3493 would expect a general-purpose HTTP/1.1 server to understand any 3494 valid request in the format of HTTP/1.0 and respond appropriately 3495 with an HTTP/1.1 message that only uses features understood (or 3496 safely ignored) by HTTP/1.0 clients. Likewise, would expect an 3497 HTTP/1.1 client to understand any valid HTTP/1.0 response. 3499 Since HTTP/0.9 did not support header fields in a request, there is 3500 no mechanism for it to support name-based virtual hosts (selection of 3501 resource by inspection of the Host header field). Any server that 3502 implements name-based virtual hosts ought to disable support for 3503 HTTP/0.9. Most requests that appear to be HTTP/0.9 are, in fact, 3504 badly constructed HTTP/1.x requests wherein a buggy client failed to 3505 properly encode linear whitespace found in a URI reference and placed 3506 in the request-target. 3508 B.1. Changes from HTTP/1.0 3510 This section summarizes major differences between versions HTTP/1.0 3511 and HTTP/1.1. 3513 B.1.1. Multi-homed Web Servers 3515 The requirements that clients and servers support the Host header 3516 field (Section 9.4), report an error if it is missing from an 3517 HTTP/1.1 request, and accept absolute URIs (Section 4.1.2) are among 3518 the most important changes defined by HTTP/1.1. 3520 Older HTTP/1.0 clients assumed a one-to-one relationship of IP 3521 addresses and servers; there was no other established mechanism for 3522 distinguishing the intended server of a request than the IP address 3523 to which that request was directed. The Host header field was 3524 introduced during the development of HTTP/1.1 and, though it was 3525 quickly implemented by most HTTP/1.0 browsers, additional 3526 requirements were placed on all HTTP/1.1 requests in order to ensure 3527 complete adoption. At the time of this writing, most HTTP-based 3528 services are dependent upon the Host header field for targeting 3529 requests. 3531 B.1.2. Keep-Alive Connections 3533 For most implementations of HTTP/1.0, each connection is established 3534 by the client prior to the request and closed by the server after 3535 sending the response. However, some implementations implement the 3536 Keep-Alive version of persistent connections described in Section 3537 19.7.1 of [RFC2068]. 3539 Some clients and servers might wish to be compatible with some 3540 previous implementations of persistent connections in HTTP/1.0 3541 clients and servers. Persistent connections in HTTP/1.0 are 3542 explicitly negotiated as they are not the default behavior. HTTP/1.0 3543 experimental implementations of persistent connections are faulty, 3544 and the new facilities in HTTP/1.1 are designed to rectify these 3545 problems. The problem was that some existing HTTP/1.0 clients might 3546 send Keep-Alive to a proxy server that doesn't understand Connection, 3547 which would then erroneously forward it to the next inbound server, 3548 which would establish the Keep-Alive connection and result in a hung 3549 HTTP/1.0 proxy waiting for the close on the response. The result is 3550 that HTTP/1.0 clients must be prevented from using Keep-Alive when 3551 talking to proxies. 3553 However, talking to proxies is the most important use of persistent 3554 connections, so that prohibition is clearly unacceptable. Therefore, 3555 we need some other mechanism for indicating a persistent connection 3556 is desired, which is safe to use even when talking to an old proxy 3557 that ignores Connection. Persistent connections are the default for 3558 HTTP/1.1 messages; we introduce a new keyword (Connection: close) for 3559 declaring non-persistence. See Section 9.1. 3561 B.2. Changes from RFC 2616 3563 Empty list elements in list productions have been deprecated. 3564 (Section 1.2.1) 3566 Rules about implicit linear whitespace between certain grammar 3567 productions have been removed; now it's only allowed when 3568 specifically pointed out in the ABNF. The NUL octet is no longer 3569 allowed in comment and quoted-string text. The quoted-pair rule no 3570 longer allows escaping control characters other than HTAB. Non-ASCII 3571 content in header fields and reason phrase has been obsoleted and 3572 made opaque (the TEXT rule was removed) (Section 1.2.2) 3574 Clarify that the string "HTTP" in the HTTP-Version ABFN production is 3575 case sensitive. Restrict the version numbers to be single digits due 3576 to the fact that implementations are known to handle multi-digit 3577 version numbers incorrectly. (Section 2.6) 3579 Require that invalid whitespace around field-names be rejected. 3580 (Section 3.2) 3582 Require recipients to handle bogus Content-Length header fields as 3583 errors. (Section 3.3) 3585 Remove reference to non-existent identity transfer-coding value 3586 tokens. (Sections 3.3 and 6.2) 3588 Update use of abs_path production from RFC 1808 to the path-absolute 3589 + query components of RFC 3986. State that the asterisk form is 3590 allowed for the OPTIONS request method only. (Section 4.1.2) 3592 Clarification that the chunk length does not include the count of the 3593 octets in the chunk header and trailer. Furthermore disallowed line 3594 folding in chunk extensions. (Section 6.2.1) 3595 Remove hard limit of two connections per server. (Section 7.1.4) 3597 Change ABNF productions for header fields to only define the field 3598 value. (Section 9) 3600 Clarify exactly when close connection options must be sent. 3601 (Section 9.1) 3603 Define the semantics of the "Upgrade" header field in responses other 3604 than 101 (this was incorporated from [RFC2817]). (Section 9.8) 3606 Appendix C. Collected ABNF 3608 BWS = OWS 3610 Chunked-Body = *chunk last-chunk trailer-part CRLF 3611 Connection = *( "," OWS ) connection-token *( OWS "," [ OWS 3612 connection-token ] ) 3613 Content-Length = 1*DIGIT 3615 Date = HTTP-date 3617 GMT = %x47.4D.54 ; GMT 3619 HTTP-Prot-Name = %x48.54.54.50 ; HTTP 3620 HTTP-Version = HTTP-Prot-Name "/" DIGIT "." DIGIT 3621 HTTP-date = rfc1123-date / obs-date 3622 HTTP-message = start-line *( header-field CRLF ) CRLF [ message-body 3623 ] 3624 Host = uri-host [ ":" port ] 3626 Method = token 3628 OWS = *( [ obs-fold ] WSP ) 3630 RWS = 1*( [ obs-fold ] WSP ) 3631 Reason-Phrase = *( WSP / VCHAR / obs-text ) 3632 Request = Request-Line *( header-field CRLF ) CRLF [ message-body ] 3633 Request-Line = Method SP request-target SP HTTP-Version CRLF 3634 Response = Status-Line *( header-field CRLF ) CRLF [ message-body ] 3636 Status-Code = 3DIGIT 3637 Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF 3639 TE = [ ( "," / t-codings ) *( OWS "," [ OWS t-codings ] ) ] 3640 Trailer = *( "," OWS ) field-name *( OWS "," [ OWS field-name ] ) 3641 Transfer-Encoding = *( "," OWS ) transfer-coding *( OWS "," [ OWS 3642 transfer-coding ] ) 3644 URI-reference = 3645 Upgrade = *( "," OWS ) product *( OWS "," [ OWS product ] ) 3647 Via = *( "," OWS ) received-protocol RWS received-by [ RWS comment ] 3648 *( OWS "," [ OWS received-protocol RWS received-by [ RWS comment ] ] 3649 ) 3651 absolute-URI = 3652 asctime-date = day-name SP date3 SP time-of-day SP year 3653 attribute = token 3654 authority = 3656 chunk = chunk-size *WSP [ chunk-ext ] CRLF chunk-data CRLF 3657 chunk-data = 1*OCTET 3658 chunk-ext = *( ";" *WSP chunk-ext-name [ "=" chunk-ext-val ] *WSP ) 3659 chunk-ext-name = token 3660 chunk-ext-val = token / quoted-str-nf 3661 chunk-size = 1*HEXDIG 3662 comment = "(" *( ctext / quoted-cpair / comment ) ")" 3663 connection-token = token 3664 ctext = OWS / %x21-27 ; '!'-''' 3665 / %x2A-5B ; '*'-'[' 3666 / %x5D-7E ; ']'-'~' 3667 / obs-text 3669 date1 = day SP month SP year 3670 date2 = day "-" month "-" 2DIGIT 3671 date3 = month SP ( 2DIGIT / ( SP DIGIT ) ) 3672 day = 2DIGIT 3673 day-name = %x4D.6F.6E ; Mon 3674 / %x54.75.65 ; Tue 3675 / %x57.65.64 ; Wed 3676 / %x54.68.75 ; Thu 3677 / %x46.72.69 ; Fri 3678 / %x53.61.74 ; Sat 3679 / %x53.75.6E ; Sun 3680 day-name-l = %x4D.6F.6E.64.61.79 ; Monday 3681 / %x54.75.65.73.64.61.79 ; Tuesday 3682 / %x57.65.64.6E.65.73.64.61.79 ; Wednesday 3683 / %x54.68.75.72.73.64.61.79 ; Thursday 3684 / %x46.72.69.64.61.79 ; Friday 3685 / %x53.61.74.75.72.64.61.79 ; Saturday 3686 / %x53.75.6E.64.61.79 ; Sunday 3688 field-content = *( WSP / VCHAR / obs-text ) 3689 field-name = token 3690 field-value = *( field-content / OWS ) 3691 header-field = field-name ":" OWS [ field-value ] OWS 3692 hour = 2DIGIT 3693 http-URI = "http://" authority path-abempty [ "?" query ] 3694 https-URI = "https://" authority path-abempty [ "?" query ] 3696 last-chunk = 1*"0" *WSP [ chunk-ext ] CRLF 3698 message-body = *OCTET 3699 minute = 2DIGIT 3700 month = %x4A.61.6E ; Jan 3701 / %x46.65.62 ; Feb 3702 / %x4D.61.72 ; Mar 3703 / %x41.70.72 ; Apr 3704 / %x4D.61.79 ; May 3705 / %x4A.75.6E ; Jun 3706 / %x4A.75.6C ; Jul 3707 / %x41.75.67 ; Aug 3708 / %x53.65.70 ; Sep 3709 / %x4F.63.74 ; Oct 3710 / %x4E.6F.76 ; Nov 3711 / %x44.65.63 ; Dec 3713 obs-date = rfc850-date / asctime-date 3714 obs-fold = CRLF 3715 obs-text = %x80-FF 3717 partial-URI = relative-part [ "?" query ] 3718 path-abempty = 3719 path-absolute = 3720 port = 3721 product = token [ "/" product-version ] 3722 product-version = token 3723 protocol-name = token 3724 protocol-version = token 3725 pseudonym = token 3727 qdtext = OWS / "!" / %x23-5B ; '#'-'[' 3728 / %x5D-7E ; ']'-'~' 3729 / obs-text 3730 qdtext-nf = WSP / "!" / %x23-5B ; '#'-'[' 3731 / %x5D-7E ; ']'-'~' 3732 / obs-text 3733 query = 3734 quoted-cpair = "\" ( WSP / VCHAR / obs-text ) 3735 quoted-pair = "\" ( WSP / VCHAR / obs-text ) 3736 quoted-str-nf = DQUOTE *( qdtext-nf / quoted-pair ) DQUOTE 3737 quoted-string = DQUOTE *( qdtext / quoted-pair ) DQUOTE 3738 qvalue = ( "0" [ "." *3DIGIT ] ) / ( "1" [ "." *3"0" ] ) 3739 received-by = ( uri-host [ ":" port ] ) / pseudonym 3740 received-protocol = [ protocol-name "/" ] protocol-version 3741 relative-part = 3742 request-target = "*" / absolute-URI / ( path-absolute [ "?" query ] ) 3743 / authority 3744 rfc1123-date = day-name "," SP date1 SP time-of-day SP GMT 3745 rfc850-date = day-name-l "," SP date2 SP time-of-day SP GMT 3747 second = 2DIGIT 3748 special = "(" / ")" / "<" / ">" / "@" / "," / ";" / ":" / "\" / 3749 DQUOTE / "/" / "[" / "]" / "?" / "=" / "{" / "}" 3750 start-line = Request-Line / Status-Line 3752 t-codings = "trailers" / ( transfer-extension [ te-params ] ) 3753 tchar = "!" / "#" / "$" / "%" / "&" / "'" / "*" / "+" / "-" / "." / 3754 "^" / "_" / "`" / "|" / "~" / DIGIT / ALPHA 3755 te-ext = OWS ";" OWS token [ "=" word ] 3756 te-params = OWS ";" OWS "q=" qvalue *te-ext 3757 time-of-day = hour ":" minute ":" second 3758 token = 1*tchar 3759 trailer-part = *( header-field CRLF ) 3760 transfer-coding = "chunked" / "compress" / "deflate" / "gzip" / 3761 transfer-extension 3762 transfer-extension = token *( OWS ";" OWS transfer-parameter ) 3763 transfer-parameter = attribute BWS "=" BWS value 3765 uri-host = 3767 value = word 3769 word = token / quoted-string 3771 year = 4DIGIT 3772 ABNF diagnostics: 3774 ; Chunked-Body defined but not used 3775 ; Connection defined but not used 3776 ; Content-Length defined but not used 3777 ; Date defined but not used 3778 ; HTTP-message defined but not used 3779 ; Host defined but not used 3780 ; Request defined but not used 3781 ; Response defined but not used 3782 ; TE defined but not used 3783 ; Trailer defined but not used 3784 ; Transfer-Encoding defined but not used 3785 ; URI-reference defined but not used 3786 ; Upgrade defined but not used 3787 ; Via defined but not used 3788 ; http-URI defined but not used 3789 ; https-URI defined but not used 3790 ; partial-URI defined but not used 3791 ; special defined but not used 3793 Appendix D. Change Log (to be removed by RFC Editor before publication) 3795 D.1. Since RFC 2616 3797 Extracted relevant partitions from [RFC2616]. 3799 D.2. Since draft-ietf-httpbis-p1-messaging-00 3801 Closed issues: 3803 o : "HTTP Version 3804 should be case sensitive" 3805 () 3807 o : "'unsafe' 3808 characters" () 3810 o : "Chunk Size 3811 Definition" () 3813 o : "Message Length" 3814 () 3816 o : "Media Type 3817 Registrations" () 3819 o : "URI includes 3820 query" () 3822 o : "No close on 3823 1xx responses" () 3825 o : "Remove 3826 'identity' token references" 3827 () 3829 o : "Import query 3830 BNF" 3832 o : "qdtext BNF" 3834 o : "Normative and 3835 Informative references" 3837 o : "RFC2606 3838 Compliance" 3840 o : "RFC977 3841 reference" 3843 o : "RFC1700 3844 references" 3846 o : "inconsistency 3847 in date format explanation" 3849 o : "Date reference 3850 typo" 3852 o : "Informative 3853 references" 3855 o : "ISO-8859-1 3856 Reference" 3858 o : "Normative up- 3859 to-date references" 3861 Other changes: 3863 o Update media type registrations to use RFC4288 template. 3865 o Use names of RFC4234 core rules DQUOTE and WSP, fix broken ABNF 3866 for chunk-data (work in progress on 3867 ) 3869 D.3. Since draft-ietf-httpbis-p1-messaging-01 3871 Closed issues: 3873 o : "Bodies on GET 3874 (and other) requests" 3876 o : "Updating to 3877 RFC4288" 3879 o : "Status Code 3880 and Reason Phrase" 3882 o : "rel_path not 3883 used" 3885 Ongoing work on ABNF conversion 3886 (): 3888 o Get rid of duplicate BNF rule names ("host" -> "uri-host", 3889 "trailer" -> "trailer-part"). 3891 o Avoid underscore character in rule names ("http_URL" -> "http- 3892 URL", "abs_path" -> "path-absolute"). 3894 o Add rules for terms imported from URI spec ("absoluteURI", 3895 "authority", "path-absolute", "port", "query", "relativeURI", 3896 "host) -- these will have to be updated when switching over to 3897 RFC3986. 3899 o Synchronize core rules with RFC5234. 3901 o Get rid of prose rules that span multiple lines. 3903 o Get rid of unused rules LOALPHA and UPALPHA. 3905 o Move "Product Tokens" section (back) into Part 1, as "token" is 3906 used in the definition of the Upgrade header field. 3908 o Add explicit references to BNF syntax and rules imported from 3909 other parts of the specification. 3911 o Rewrite prose rule "token" in terms of "tchar", rewrite prose rule 3912 "TEXT". 3914 D.4. Since draft-ietf-httpbis-p1-messaging-02 3916 Closed issues: 3918 o : "HTTP-date vs. 3919 rfc1123-date" 3921 o : "WS in quoted- 3922 pair" 3924 Ongoing work on IANA Message Header Field Registration 3925 (): 3927 o Reference RFC 3984, and update header field registrations for 3928 headers defined in this document. 3930 Ongoing work on ABNF conversion 3931 (): 3933 o Replace string literals when the string really is case-sensitive 3934 (HTTP-Version). 3936 D.5. Since draft-ietf-httpbis-p1-messaging-03 3938 Closed issues: 3940 o : "Connection 3941 closing" 3943 o : "Move 3944 registrations and registry information to IANA Considerations" 3946 o : "need new URL 3947 for PAD1995 reference" 3949 o : "IANA 3950 Considerations: update HTTP URI scheme registration" 3952 o : "Cite HTTPS 3953 URI scheme definition" 3955 o : "List-type 3956 headers vs Set-Cookie" 3958 Ongoing work on ABNF conversion 3959 (): 3961 o Replace string literals when the string really is case-sensitive 3962 (HTTP-Date). 3964 o Replace HEX by HEXDIG for future consistence with RFC 5234's core 3965 rules. 3967 D.6. Since draft-ietf-httpbis-p1-messaging-04 3969 Closed issues: 3971 o : "Out-of-date 3972 reference for URIs" 3974 o : "RFC 2822 is 3975 updated by RFC 5322" 3977 Ongoing work on ABNF conversion 3978 (): 3980 o Use "/" instead of "|" for alternatives. 3982 o Get rid of RFC822 dependency; use RFC5234 plus extensions instead. 3984 o Only reference RFC 5234's core rules. 3986 o Introduce new ABNF rules for "bad" whitespace ("BWS"), optional 3987 whitespace ("OWS") and required whitespace ("RWS"). 3989 o Rewrite ABNFs to spell out whitespace rules, factor out header 3990 field value format definitions. 3992 D.7. Since draft-ietf-httpbis-p1-messaging-05 3994 Closed issues: 3996 o : "Header LWS" 3998 o : "Sort 1.3 3999 Terminology" 4001 o : "RFC2047 4002 encoded words" 4004 o : "Character 4005 Encodings in TEXT" 4007 o : "Line Folding" 4008 o : "OPTIONS * and 4009 proxies" 4011 o : "Reason-Phrase 4012 BNF" 4014 o : "Use of TEXT" 4016 o : "Join 4017 "Differences Between HTTP Entities and RFC 2045 Entities"?" 4019 o : "RFC822 4020 reference left in discussion of date formats" 4022 Final work on ABNF conversion 4023 (): 4025 o Rewrite definition of list rules, deprecate empty list elements. 4027 o Add appendix containing collected and expanded ABNF. 4029 Other changes: 4031 o Rewrite introduction; add mostly new Architecture Section. 4033 o Move definition of quality values from Part 3 into Part 1; make TE 4034 request header field grammar independent of accept-params (defined 4035 in Part 3). 4037 D.8. Since draft-ietf-httpbis-p1-messaging-06 4039 Closed issues: 4041 o : "base for 4042 numeric protocol elements" 4044 o : "comment ABNF" 4046 Partly resolved issues: 4048 o : "205 Bodies" 4049 (took out language that implied that there might be methods for 4050 which a request body MUST NOT be included) 4052 o : "editorial 4053 improvements around HTTP-date" 4055 D.9. Since draft-ietf-httpbis-p1-messaging-07 4057 Closed issues: 4059 o : "Repeating 4060 single-value headers" 4062 o : "increase 4063 connection limit" 4065 o : "IP addresses 4066 in URLs" 4068 o : "take over 4069 HTTP Upgrade Token Registry" 4071 o : "CR and LF in 4072 chunk extension values" 4074 o : "HTTP/0.9 4075 support" 4077 o : "pick IANA 4078 policy (RFC5226) for Transfer Coding / Content Coding" 4080 o : "move 4081 definitions of gzip/deflate/compress to part 1" 4083 o : "disallow 4084 control characters in quoted-pair" 4086 Partly resolved issues: 4088 o : "update IANA 4089 requirements wrt Transfer-Coding values" (add the IANA 4090 Considerations subsection) 4092 D.10. Since draft-ietf-httpbis-p1-messaging-08 4094 Closed issues: 4096 o : "header 4097 parsing, treatment of leading and trailing OWS" 4099 Partly resolved issues: 4101 o : "Placement of 4102 13.5.1 and 13.5.2" 4104 o : "use of term 4105 "word" when talking about header structure" 4107 D.11. Since draft-ietf-httpbis-p1-messaging-09 4109 Closed issues: 4111 o : "Clarification 4112 of the term 'deflate'" 4114 o : "OPTIONS * and 4115 proxies" 4117 o : "MIME-Version 4118 not listed in P1, general header fields" 4120 o : "IANA registry 4121 for content/transfer encodings" 4123 o : "Case- 4124 sensitivity of HTTP-date" 4126 o : "use of term 4127 "word" when talking about header structure" 4129 Partly resolved issues: 4131 o : "Term for the 4132 requested resource's URI" 4134 D.12. Since draft-ietf-httpbis-p1-messaging-10 4136 Closed issues: 4138 o : "Connection 4139 Closing" 4141 o : "Delimiting 4142 messages with multipart/byteranges" 4144 o : "Handling 4145 multiple Content-Length headers" 4147 o : "Clarify 4148 entity / representation / variant terminology" 4150 o : "consider 4151 removing the 'changes from 2068' sections" 4153 Partly resolved issues: 4155 o : "HTTP(s) URI 4156 scheme definitions" 4158 D.13. Since draft-ietf-httpbis-p1-messaging-11 4160 Closed issues: 4162 o : "Trailer 4163 requirements" 4165 o : "Text about 4166 clock requirement for caches belongs in p6" 4168 o : "effective 4169 request URI: handling of missing host in HTTP/1.0" 4171 o : "confusing 4172 Date requirements for clients" 4174 Partly resolved issues: 4176 o : "Handling 4177 multiple Content-Length headers" 4179 D.14. Since draft-ietf-httpbis-p1-messaging-12 4181 Closed issues: 4183 o : "RFC2145 4184 Normative" 4186 o : "HTTP(s) URI 4187 scheme definitions" (tune the requirements on userinfo) 4189 o : "define 4190 'transparent' proxy" 4192 o : "Header 4193 Classification" 4195 o : "Is * usable 4196 as a request-uri for new methods?" 4198 o : "Migrate 4199 Upgrade details from RFC2817" 4201 o : "untangle 4202 ABNFs for header fields" 4204 o : "update RFC 4205 2109 reference" 4207 D.15. Since draft-ietf-httpbis-p1-messaging-13 4209 Closed issues: 4211 o : "Allow is not 4212 in 13.5.2" 4214 o : "untangle 4215 ABNFs for header fields" 4217 o : "Content- 4218 Length ABNF broken" 4220 D.16. Since draft-ietf-httpbis-p1-messaging-14 4222 Closed issues: 4224 o : "HTTP-Version 4225 should be redefined as fixed length pair of DIGIT . DIGIT" 4227 o : "Recommend 4228 minimum sizes for protocol elements" 4230 o : "Set 4231 expectations around buffering" 4233 o : "Considering 4234 messages in isolation" 4236 Index 4238 A 4239 absolute-URI form (of request-target) 29 4240 accelerator 14 4241 application/http Media Type 64 4242 asterisk form (of request-target) 29 4243 authority form (of request-target) 30 4245 B 4246 browser 10 4248 C 4249 cache 15 4250 cacheable 15 4251 captive portal 14 4252 chunked (Coding Format) 38 4253 client 10 4254 Coding Format 4255 chunked 38 4256 compress 41 4257 deflate 41 4258 gzip 41 4259 compress (Coding Format) 41 4260 connection 10 4261 Connection header field 52 4262 Content-Length header field 54 4264 D 4265 Date header field 54 4266 deflate (Coding Format) 41 4267 downstream 13 4269 E 4270 effective request URI 32 4272 G 4273 gateway 14 4274 Grammar 4275 absolute-URI 18 4276 ALPHA 7 4277 asctime-date 37 4278 attribute 37 4279 authority 18 4280 BWS 9 4281 chunk 38 4282 chunk-data 38 4283 chunk-ext 38 4284 chunk-ext-name 38 4285 chunk-ext-val 38 4286 chunk-size 38 4287 Chunked-Body 38 4288 comment 24 4289 Connection 53 4290 connection-token 53 4291 Content-Length 54 4292 CR 7 4293 CRLF 7 4294 ctext 24 4295 CTL 7 4296 Date 54 4297 date1 36 4298 date2 37 4299 date3 37 4300 day 36 4301 day-name 36 4302 day-name-l 36 4303 DIGIT 7 4304 DQUOTE 7 4305 field-content 23 4306 field-name 23 4307 field-value 23 4308 GMT 36 4309 header-field 23 4310 HEXDIG 7 4311 Host 56 4312 hour 36 4313 HTTP-date 35 4314 HTTP-message 21 4315 HTTP-Prot-Name 16 4316 http-URI 18 4317 HTTP-Version 16 4318 https-URI 20 4319 last-chunk 38 4320 LF 7 4321 message-body 25 4322 Method 29 4323 minute 36 4324 month 36 4325 obs-date 36 4326 obs-text 10 4327 OCTET 7 4328 OWS 9 4329 path-absolute 18 4330 port 18 4331 product 42 4332 product-version 42 4333 protocol-name 61 4334 protocol-version 61 4335 pseudonym 61 4336 qdtext 10 4337 qdtext-nf 38 4338 query 18 4339 quoted-cpair 24 4340 quoted-pair 10 4341 quoted-str-nf 38 4342 quoted-string 10 4343 qvalue 42 4344 Reason-Phrase 34 4345 received-by 61 4346 received-protocol 61 4347 Request 29 4348 Request-Line 29 4349 request-target 29 4350 Response 33 4351 rfc850-date 37 4352 rfc1123-date 36 4353 RWS 9 4354 second 36 4355 SP 7 4356 special 9 4357 Status-Code 34 4358 Status-Line 34 4359 t-codings 57 4360 tchar 9 4361 TE 57 4362 te-ext 57 4363 te-params 57 4364 time-of-day 36 4365 token 9 4366 Trailer 58 4367 trailer-part 38 4368 transfer-coding 37 4369 Transfer-Encoding 59 4370 transfer-extension 37 4371 transfer-parameter 37 4372 Upgrade 59 4373 uri-host 18 4374 URI-reference 18 4375 value 37 4376 VCHAR 7 4377 Via 61 4378 word 9 4379 WSP 7 4380 year 36 4381 gzip (Coding Format) 41 4383 H 4384 header field 21 4385 Header Fields 4386 Connection 52 4387 Content-Length 54 4388 Date 54 4389 Host 56 4390 TE 57 4391 Trailer 58 4392 Transfer-Encoding 58 4393 Upgrade 59 4394 Via 61 4395 header section 21 4396 headers 21 4397 Host header field 56 4398 http URI scheme 18 4399 https URI scheme 20 4401 I 4402 inbound 13 4403 interception proxy 14 4404 intermediary 13 4406 M 4407 Media Type 4408 application/http 64 4409 message/http 63 4410 message 11 4411 message/http Media Type 63 4413 N 4414 non-transforming proxy 13 4416 O 4417 origin form (of request-target) 30 4418 origin server 10 4419 outbound 13 4421 P 4422 proxy 13 4424 R 4425 recipient 10 4426 request 11 4427 resource 18 4428 response 11 4429 reverse proxy 14 4431 S 4432 sender 10 4433 server 10 4434 spider 10 4436 T 4437 target resource 32 4438 TE header field 57 4439 Trailer header field 58 4440 Transfer-Encoding header field 58 4441 transforming proxy 13 4442 transparent proxy 14 4443 tunnel 14 4445 U 4446 Upgrade header field 59 4447 upstream 13 4448 URI scheme 4449 http 18 4450 https 20 4451 user agent 10 4453 V 4454 Via header field 61 4456 Authors' Addresses 4458 Roy T. Fielding (editor) 4459 Adobe Systems Incorporated 4460 345 Park Ave 4461 San Jose, CA 95110 4462 USA 4464 EMail: fielding@gbiv.com 4465 URI: http://roy.gbiv.com/ 4467 Jim Gettys 4468 Alcatel-Lucent Bell Labs 4469 21 Oak Knoll Road 4470 Carlisle, MA 01741 4471 USA 4473 EMail: jg@freedesktop.org 4474 URI: http://gettys.wordpress.com/ 4476 Jeffrey C. Mogul 4477 Hewlett-Packard Company 4478 HP Labs, Large Scale Systems Group 4479 1501 Page Mill Road, MS 1177 4480 Palo Alto, CA 94304 4481 USA 4483 EMail: JeffMogul@acm.org 4484 Henrik Frystyk Nielsen 4485 Microsoft Corporation 4486 1 Microsoft Way 4487 Redmond, WA 98052 4488 USA 4490 EMail: henrikn@microsoft.com 4492 Larry Masinter 4493 Adobe Systems Incorporated 4494 345 Park Ave 4495 San Jose, CA 95110 4496 USA 4498 EMail: LMM@acm.org 4499 URI: http://larry.masinter.net/ 4501 Paul J. Leach 4502 Microsoft Corporation 4503 1 Microsoft Way 4504 Redmond, WA 98052 4506 EMail: paulle@microsoft.com 4508 Tim Berners-Lee 4509 World Wide Web Consortium 4510 MIT Computer Science and Artificial Intelligence Laboratory 4511 The Stata Center, Building 32 4512 32 Vassar Street 4513 Cambridge, MA 02139 4514 USA 4516 EMail: timbl@w3.org 4517 URI: http://www.w3.org/People/Berners-Lee/ 4518 Yves Lafon (editor) 4519 World Wide Web Consortium 4520 W3C / ERCIM 4521 2004, rte des Lucioles 4522 Sophia-Antipolis, AM 06902 4523 France 4525 EMail: ylafon@w3.org 4526 URI: http://www.raubacapeu.net/people/yves/ 4528 Julian F. Reschke (editor) 4529 greenbytes GmbH 4530 Hafenweg 16 4531 Muenster, NW 48155 4532 Germany 4534 Phone: +49 251 2807760 4535 Fax: +49 251 2807761 4536 EMail: julian.reschke@greenbytes.de 4537 URI: http://greenbytes.de/tech/webdav/