idnits 2.17.1 draft-ietf-httpbis-p1-messaging-13.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 (March 14, 2011) is 4792 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO-8859-1' == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p2-semantics-13 == Outdated reference: A later version (-20) exists of draft-ietf-httpbis-p3-payload-13 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p6-cache-13 ** 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 (~~), 4 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 J. Gettys 5 (if approved) Alcatel-Lucent 6 Updates: 2817 (if approved) J. Mogul 7 Intended status: Standards Track HP 8 Expires: September 15, 2011 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 March 14, 2011 22 HTTP/1.1, part 1: URIs, Connections, and Message Parsing 23 draft-ietf-httpbis-p1-messaging-13 25 Abstract 27 The Hypertext Transfer Protocol (HTTP) is an application-level 28 protocol for distributed, collaborative, hypertext information 29 systems. HTTP has been in use by the World Wide Web global 30 information initiative since 1990. This document is Part 1 of the 31 seven-part specification that defines the protocol referred to as 32 "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 1 provides 33 an overview of HTTP and its associated terminology, defines the 34 "http" and "https" Uniform Resource Identifier (URI) schemes, defines 35 the generic message syntax and parsing requirements for HTTP message 36 frames, and describes general security concerns for implementations. 38 Editorial Note (To be removed by RFC Editor) 40 Discussion of this draft should take place on the HTTPBIS working 41 group mailing list (ietf-http-wg@w3.org). The current issues list is 42 at and related 43 documents (including fancy diffs) can be found at 44 . 46 The changes in this draft are summarized in Appendix D.14. 48 Status of This Memo 49 This Internet-Draft is submitted in full conformance with the 50 provisions of BCP 78 and BCP 79. 52 Internet-Drafts are working documents of the Internet Engineering 53 Task Force (IETF). Note that other groups may also distribute 54 working documents as Internet-Drafts. The list of current Internet- 55 Drafts is at http://datatracker.ietf.org/drafts/current/. 57 Internet-Drafts are draft documents valid for a maximum of six months 58 and may be updated, replaced, or obsoleted by other documents at any 59 time. It is inappropriate to use Internet-Drafts as reference 60 material or to cite them other than as "work in progress." 62 This Internet-Draft will expire on September 15, 2011. 64 Copyright Notice 66 Copyright (c) 2011 IETF Trust and the persons identified as the 67 document authors. All rights reserved. 69 This document is subject to BCP 78 and the IETF Trust's Legal 70 Provisions Relating to IETF Documents 71 (http://trustee.ietf.org/license-info) in effect on the date of 72 publication of this document. Please review these documents 73 carefully, as they describe your rights and restrictions with respect 74 to this document. Code Components extracted from this document must 75 include Simplified BSD License text as described in Section 4.e of 76 the Trust Legal Provisions and are provided without warranty as 77 described in the Simplified BSD License. 79 This document may contain material from IETF Documents or IETF 80 Contributions published or made publicly available before November 81 10, 2008. The person(s) controlling the copyright in some of this 82 material may not have granted the IETF Trust the right to allow 83 modifications of such material outside the IETF Standards Process. 84 Without obtaining an adequate license from the person(s) controlling 85 the copyright in such materials, this document may not be modified 86 outside the IETF Standards Process, and derivative works of it may 87 not be created outside the IETF Standards Process, except to format 88 it for publication as an RFC or to translate it into languages other 89 than English. 91 Table of Contents 93 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6 94 1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 7 95 1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 7 96 1.2.1. ABNF Extension: #rule . . . . . . . . . . . . . . . . 7 97 1.2.2. Basic Rules . . . . . . . . . . . . . . . . . . . . . 8 98 2. HTTP-related architecture . . . . . . . . . . . . . . . . . . 10 99 2.1. Client/Server Messaging . . . . . . . . . . . . . . . . . 10 100 2.2. Connections and Transport Independence . . . . . . . . . . 12 101 2.3. Intermediaries . . . . . . . . . . . . . . . . . . . . . . 12 102 2.4. Caches . . . . . . . . . . . . . . . . . . . . . . . . . . 14 103 2.5. Protocol Versioning . . . . . . . . . . . . . . . . . . . 15 104 2.6. Uniform Resource Identifiers . . . . . . . . . . . . . . . 17 105 2.6.1. http URI scheme . . . . . . . . . . . . . . . . . . . 18 106 2.6.2. https URI scheme . . . . . . . . . . . . . . . . . . . 19 107 2.6.3. http and https URI Normalization and Comparison . . . 20 108 3. Message Format . . . . . . . . . . . . . . . . . . . . . . . . 20 109 3.1. Message Parsing Robustness . . . . . . . . . . . . . . . . 21 110 3.2. Header Fields . . . . . . . . . . . . . . . . . . . . . . 22 111 3.3. Message Body . . . . . . . . . . . . . . . . . . . . . . . 24 112 3.4. General Header Fields . . . . . . . . . . . . . . . . . . 27 113 4. Request . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 114 4.1. Request-Line . . . . . . . . . . . . . . . . . . . . . . . 28 115 4.1.1. Method . . . . . . . . . . . . . . . . . . . . . . . . 28 116 4.1.2. request-target . . . . . . . . . . . . . . . . . . . . 28 117 4.2. The Resource Identified by a Request . . . . . . . . . . . 30 118 4.3. Effective Request URI . . . . . . . . . . . . . . . . . . 31 119 5. Response . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 120 5.1. Status-Line . . . . . . . . . . . . . . . . . . . . . . . 33 121 5.1.1. Status Code and Reason Phrase . . . . . . . . . . . . 33 122 6. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 33 123 6.1. Date/Time Formats: Full Date . . . . . . . . . . . . . . . 33 124 6.2. Transfer Codings . . . . . . . . . . . . . . . . . . . . . 36 125 6.2.1. Chunked Transfer Coding . . . . . . . . . . . . . . . 37 126 6.2.2. Compression Codings . . . . . . . . . . . . . . . . . 39 127 6.2.3. Transfer Coding Registry . . . . . . . . . . . . . . . 40 128 6.3. Product Tokens . . . . . . . . . . . . . . . . . . . . . . 41 129 6.4. Quality Values . . . . . . . . . . . . . . . . . . . . . . 41 130 7. Connections . . . . . . . . . . . . . . . . . . . . . . . . . 41 131 7.1. Persistent Connections . . . . . . . . . . . . . . . . . . 42 132 7.1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . 42 133 7.1.2. Overall Operation . . . . . . . . . . . . . . . . . . 42 134 7.1.3. Proxy Servers . . . . . . . . . . . . . . . . . . . . 44 135 7.1.4. Practical Considerations . . . . . . . . . . . . . . . 46 136 7.2. Message Transmission Requirements . . . . . . . . . . . . 47 137 7.2.1. Persistent Connections and Flow Control . . . . . . . 47 138 7.2.2. Monitoring Connections for Error Status Messages . . . 47 139 7.2.3. Use of the 100 (Continue) Status . . . . . . . . . . . 48 140 7.2.4. Client Behavior if Server Prematurely Closes 141 Connection . . . . . . . . . . . . . . . . . . . . . . 50 142 8. Miscellaneous notes that might disappear . . . . . . . . . . . 51 143 8.1. Scheme aliases considered harmful . . . . . . . . . . . . 51 144 8.2. Use of HTTP for proxy communication . . . . . . . . . . . 51 145 8.3. Interception of HTTP for access control . . . . . . . . . 51 146 8.4. Use of HTTP by other protocols . . . . . . . . . . . . . . 51 147 8.5. Use of HTTP by media type specification . . . . . . . . . 51 148 9. Header Field Definitions . . . . . . . . . . . . . . . . . . . 51 149 9.1. Connection . . . . . . . . . . . . . . . . . . . . . . . . 51 150 9.2. Content-Length . . . . . . . . . . . . . . . . . . . . . . 53 151 9.3. Date . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 152 9.3.1. Clockless Origin Server Operation . . . . . . . . . . 54 153 9.4. Host . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 154 9.5. TE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 155 9.6. Trailer . . . . . . . . . . . . . . . . . . . . . . . . . 57 156 9.7. Transfer-Encoding . . . . . . . . . . . . . . . . . . . . 58 157 9.8. Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . 58 158 9.8.1. Upgrade Token Registry . . . . . . . . . . . . . . . . 59 159 9.9. Via . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 160 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 62 161 10.1. Header Field Registration . . . . . . . . . . . . . . . . 62 162 10.2. URI Scheme Registration . . . . . . . . . . . . . . . . . 62 163 10.3. Internet Media Type Registrations . . . . . . . . . . . . 62 164 10.3.1. Internet Media Type message/http . . . . . . . . . . . 62 165 10.3.2. Internet Media Type application/http . . . . . . . . . 64 166 10.4. Transfer Coding Registry . . . . . . . . . . . . . . . . . 65 167 10.5. Upgrade Token Registration . . . . . . . . . . . . . . . . 65 168 11. Security Considerations . . . . . . . . . . . . . . . . . . . 65 169 11.1. Personal Information . . . . . . . . . . . . . . . . . . . 66 170 11.2. Abuse of Server Log Information . . . . . . . . . . . . . 66 171 11.3. Attacks Based On File and Path Names . . . . . . . . . . . 66 172 11.4. DNS Spoofing . . . . . . . . . . . . . . . . . . . . . . . 66 173 11.5. Proxies and Caching . . . . . . . . . . . . . . . . . . . 67 174 11.6. Denial of Service Attacks on Proxies . . . . . . . . . . . 68 175 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 68 176 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 69 177 13.1. Normative References . . . . . . . . . . . . . . . . . . . 69 178 13.2. Informative References . . . . . . . . . . . . . . . . . . 71 179 Appendix A. Tolerant Applications . . . . . . . . . . . . . . . . 74 180 Appendix B. HTTP Version History . . . . . . . . . . . . . . . . 75 181 B.1. Changes from HTTP/1.0 . . . . . . . . . . . . . . . . . . 75 182 B.1.1. Multi-homed Web Servers . . . . . . . . . . . . . . . 76 183 B.1.2. Keep-Alive Connections . . . . . . . . . . . . . . . . 76 184 B.2. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 77 185 Appendix C. Collected ABNF . . . . . . . . . . . . . . . . . . . 77 186 Appendix D. Change Log (to be removed by RFC Editor before 187 publication) . . . . . . . . . . . . . . . . . . . . 82 188 D.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 82 189 D.2. Since draft-ietf-httpbis-p1-messaging-00 . . . . . . . . . 82 190 D.3. Since draft-ietf-httpbis-p1-messaging-01 . . . . . . . . . 83 191 D.4. Since draft-ietf-httpbis-p1-messaging-02 . . . . . . . . . 84 192 D.5. Since draft-ietf-httpbis-p1-messaging-03 . . . . . . . . . 85 193 D.6. Since draft-ietf-httpbis-p1-messaging-04 . . . . . . . . . 85 194 D.7. Since draft-ietf-httpbis-p1-messaging-05 . . . . . . . . . 86 195 D.8. Since draft-ietf-httpbis-p1-messaging-06 . . . . . . . . . 87 196 D.9. Since draft-ietf-httpbis-p1-messaging-07 . . . . . . . . . 87 197 D.10. Since draft-ietf-httpbis-p1-messaging-08 . . . . . . . . . 88 198 D.11. Since draft-ietf-httpbis-p1-messaging-09 . . . . . . . . . 88 199 D.12. Since draft-ietf-httpbis-p1-messaging-10 . . . . . . . . . 89 200 D.13. Since draft-ietf-httpbis-p1-messaging-11 . . . . . . . . . 89 201 D.14. Since draft-ietf-httpbis-p1-messaging-12 . . . . . . . . . 90 202 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90 204 1. Introduction 206 The Hypertext Transfer Protocol (HTTP) is an application-level 207 request/response protocol that uses extensible semantics and MIME- 208 like message payloads for flexible interaction with network-based 209 hypertext information systems. HTTP relies upon the Uniform Resource 210 Identifier (URI) standard [RFC3986] to indicate the target resource 211 and relationships between resources. Messages are passed in a format 212 similar to that used by Internet mail [RFC5322] and the Multipurpose 213 Internet Mail Extensions (MIME) [RFC2045] (see Appendix A of [Part3] 214 for the differences between HTTP and MIME messages). 216 HTTP is a generic interface protocol for information systems. It is 217 designed to hide the details of how a service is implemented by 218 presenting a uniform interface to clients that is independent of the 219 types of resources provided. Likewise, servers do not need to be 220 aware of each client's purpose: an HTTP request can be considered in 221 isolation rather than being associated with a specific type of client 222 or a predetermined sequence of application steps. The result is a 223 protocol that can be used effectively in many different contexts and 224 for which implementations can evolve independently over time. 226 HTTP is also designed for use as an intermediation protocol for 227 translating communication to and from non-HTTP information systems. 228 HTTP proxies and gateways can provide access to alternative 229 information services by translating their diverse protocols into a 230 hypertext format that can be viewed and manipulated by clients in the 231 same way as HTTP services. 233 One consequence of HTTP flexibility is that the protocol cannot be 234 defined in terms of what occurs behind the interface. Instead, we 235 are limited to defining the syntax of communication, the intent of 236 received communication, and the expected behavior of recipients. If 237 the communication is considered in isolation, then successful actions 238 ought to be reflected in corresponding changes to the observable 239 interface provided by servers. However, since multiple clients might 240 act in parallel and perhaps at cross-purposes, we cannot require that 241 such changes be observable beyond the scope of a single response. 243 This document is Part 1 of the seven-part specification of HTTP, 244 defining the protocol referred to as "HTTP/1.1", obsoleting [RFC2616] 245 and [RFC2145]. Part 1 describes the architectural elements that are 246 used or referred to in HTTP, defines the "http" and "https" URI 247 schemes, describes overall network operation and connection 248 management, and defines HTTP message framing and forwarding 249 requirements. Our goal is to define all of the mechanisms necessary 250 for HTTP message handling that are independent of message semantics, 251 thereby defining the complete set of requirements for message parsers 252 and message-forwarding intermediaries. 254 1.1. Requirements 256 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 257 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 258 document are to be interpreted as described in [RFC2119]. 260 An implementation is not compliant if it fails to satisfy one or more 261 of the "MUST" or "REQUIRED" level requirements for the protocols it 262 implements. An implementation that satisfies all the "MUST" or 263 "REQUIRED" level and all the "SHOULD" level requirements for its 264 protocols is said to be "unconditionally compliant"; one that 265 satisfies all the "MUST" level requirements but not all the "SHOULD" 266 level requirements for its protocols is said to be "conditionally 267 compliant". 269 1.2. Syntax Notation 271 This specification uses the Augmented Backus-Naur Form (ABNF) 272 notation of [RFC5234]. 274 The following core rules are included by reference, as defined in 275 [RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF 276 (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote), 277 HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any 8-bit 278 sequence of data), SP (space), VCHAR (any visible [USASCII] 279 character), and WSP (whitespace). 281 As a syntactic convention, ABNF rule names prefixed with "obs-" 282 denote "obsolete" grammar rules that appear for historical reasons. 284 1.2.1. ABNF Extension: #rule 286 The #rule extension to the ABNF rules of [RFC5234] is used to improve 287 readability. 289 A construct "#" is defined, similar to "*", for defining comma- 290 delimited lists of elements. The full form is "#element" 291 indicating at least and at most elements, each separated by a 292 single comma (",") and optional whitespace (OWS, Section 1.2.2). 294 Thus, 296 1#element => element *( OWS "," OWS element ) 298 and: 300 #element => [ 1#element ] 302 and for n >= 1 and m > 1: 304 #element => element *( OWS "," OWS element ) 306 For compatibility with legacy list rules, recipients SHOULD accept 307 empty list elements. In other words, consumers would follow the list 308 productions: 310 #element => [ ( "," / element ) *( OWS "," [ OWS element ] ) ] 312 1#element => *( "," OWS ) element *( OWS "," [ OWS element ] ) 314 Note that empty elements do not contribute to the count of elements 315 present, though. 317 For example, given these ABNF productions: 319 example-list = 1#example-list-elmt 320 example-list-elmt = token ; see Section 1.2.2 322 Then these are valid values for example-list (not including the 323 double quotes, which are present for delimitation only): 325 "foo,bar" 326 " foo ,bar," 327 " foo , ,bar,charlie " 328 "foo ,bar, charlie " 330 But these values would be invalid, as at least one non-empty element 331 is required: 333 "" 334 "," 335 ", ," 337 Appendix C shows the collected ABNF, with the list rules expanded as 338 explained above. 340 1.2.2. Basic Rules 342 HTTP/1.1 defines the sequence CR LF as the end-of-line marker for all 343 protocol elements other than the message-body (see Appendix A for 344 tolerant applications). 346 This specification uses three rules to denote the use of linear 347 whitespace: OWS (optional whitespace), RWS (required whitespace), and 348 BWS ("bad" whitespace). 350 The OWS rule is used where zero or more linear whitespace octets 351 might appear. OWS SHOULD either not be produced or be produced as a 352 single SP. Multiple OWS octets that occur within field-content 353 SHOULD be replaced with a single SP before interpreting the field 354 value or forwarding the message downstream. 356 RWS is used when at least one linear whitespace octet is required to 357 separate field tokens. RWS SHOULD be produced as a single SP. 358 Multiple RWS octets that occur within field-content SHOULD be 359 replaced with a single SP before interpreting the field value or 360 forwarding the message downstream. 362 BWS is used where the grammar allows optional whitespace for 363 historical reasons but senders SHOULD NOT produce it in messages. 364 HTTP/1.1 recipients MUST accept such bad optional whitespace and 365 remove it before interpreting the field value or forwarding the 366 message downstream. 368 OWS = *( [ obs-fold ] WSP ) 369 ; "optional" whitespace 370 RWS = 1*( [ obs-fold ] WSP ) 371 ; "required" whitespace 372 BWS = OWS 373 ; "bad" whitespace 374 obs-fold = CRLF 375 ; see Section 3.2 377 Many HTTP/1.1 header field values consist of words (token or quoted- 378 string) separated by whitespace or special characters. These special 379 characters MUST be in a quoted string to be used within a parameter 380 value (as defined in Section 6.2). 382 word = token / quoted-string 384 token = 1*tchar 386 tchar = "!" / "#" / "$" / "%" / "&" / "'" / "*" 387 / "+" / "-" / "." / "^" / "_" / "`" / "|" / "~" 388 / DIGIT / ALPHA 389 ; any VCHAR, except special 391 special = "(" / ")" / "<" / ">" / "@" / "," 392 / ";" / ":" / "\" / DQUOTE / "/" / "[" 393 / "]" / "?" / "=" / "{" / "}" 395 A string of text is parsed as a single word if it is quoted using 396 double-quote marks. 398 quoted-string = DQUOTE *( qdtext / quoted-pair ) DQUOTE 399 qdtext = OWS / %x21 / %x23-5B / %x5D-7E / obs-text 400 ; OWS / / obs-text 401 obs-text = %x80-FF 403 The backslash octet ("\") can be used as a single-octet quoting 404 mechanism within quoted-string constructs: 406 quoted-pair = "\" ( WSP / VCHAR / obs-text ) 408 Senders SHOULD NOT escape octets that do not require escaping (i.e., 409 other than DQUOTE and the backslash octet). 411 2. HTTP-related architecture 413 HTTP was created for the World Wide Web architecture and has evolved 414 over time to support the scalability needs of a worldwide hypertext 415 system. Much of that architecture is reflected in the terminology 416 and syntax productions used to define HTTP. 418 2.1. Client/Server Messaging 420 HTTP is a stateless request/response protocol that operates by 421 exchanging messages across a reliable transport or session-layer 422 connection. An HTTP "client" is a program that establishes a 423 connection to a server for the purpose of sending one or more HTTP 424 requests. An HTTP "server" is a program that accepts connections in 425 order to service HTTP requests by sending HTTP responses. 427 Note that the terms client and server refer only to the roles that 428 these programs perform for a particular connection. The same program 429 might act as a client on some connections and a server on others. We 430 use the term "user agent" to refer to the program that initiates a 431 request, such as a WWW browser, editor, or spider (web-traversing 432 robot), and the term "origin server" to refer to the program that can 433 originate authoritative responses to a request. For general 434 requirements, we use the term "sender" to refer to whichever 435 component sent a given message and the term "recipient" to refer to 436 any component that receives the message. 438 Most HTTP communication consists of a retrieval request (GET) for a 439 representation of some resource identified by a URI. In the simplest 440 case, this might be accomplished via a single bidirectional 441 connection (===) between the user agent (UA) and the origin server 442 (O). 444 request > 445 UA ======================================= O 446 < response 448 A client sends an HTTP request to the server in the form of a request 449 message (Section 4), beginning with a method, URI, and protocol 450 version, followed by MIME-like header fields containing request 451 modifiers, client information, and payload metadata, an empty line to 452 indicate the end of the header section, and finally the payload body 453 (if any). 455 A server responds to the client's request by sending an HTTP response 456 message (Section 5), beginning with a status line that includes the 457 protocol version, a success or error code, and textual reason phrase, 458 followed by MIME-like header fields containing server information, 459 resource metadata, and payload metadata, an empty line to indicate 460 the end of the header section, and finally the payload body (if any). 462 The following example illustrates a typical message exchange for a 463 GET request on the URI "http://www.example.com/hello.txt": 465 client request: 467 GET /hello.txt HTTP/1.1 468 User-Agent: curl/7.16.3 libcurl/7.16.3 OpenSSL/0.9.7l zlib/1.2.3 469 Host: www.example.com 470 Accept: */* 472 server response: 474 HTTP/1.1 200 OK 475 Date: Mon, 27 Jul 2009 12:28:53 GMT 476 Server: Apache 477 Last-Modified: Wed, 22 Jul 2009 19:15:56 GMT 478 ETag: "34aa387-d-1568eb00" 479 Accept-Ranges: bytes 480 Content-Length: 14 481 Vary: Accept-Encoding 482 Content-Type: text/plain 484 Hello World! 486 2.2. Connections and Transport Independence 488 HTTP messaging is independent of the underlying transport or session- 489 layer connection protocol(s). HTTP only presumes a reliable 490 transport with in-order delivery of requests and the corresponding 491 in-order delivery of responses. The mapping of HTTP request and 492 response structures onto the data units of the underlying transport 493 protocol is outside the scope of this specification. 495 The specific connection protocols to be used for an interaction are 496 determined by client configuration and the target resource's URI. 497 For example, the "http" URI scheme (Section 2.6.1) indicates a 498 default connection of TCP over IP, with a default TCP port of 80, but 499 the client might be configured to use a proxy via some other 500 connection port or protocol instead of using the defaults. 502 A connection might be used for multiple HTTP request/response 503 exchanges, as defined in Section 7.1. 505 2.3. Intermediaries 507 HTTP enables the use of intermediaries to satisfy requests through a 508 chain of connections. There are three common forms of HTTP 509 intermediary: proxy, gateway, and tunnel. In some cases, a single 510 intermediary might act as an origin server, proxy, gateway, or 511 tunnel, switching behavior based on the nature of each request. 513 > > > > 514 UA =========== A =========== B =========== C =========== O 515 < < < < 517 The figure above shows three intermediaries (A, B, and C) between the 518 user agent and origin server. A request or response message that 519 travels the whole chain will pass through four separate connections. 520 Some HTTP communication options might apply only to the connection 521 with the nearest, non-tunnel neighbor, only to the end-points of the 522 chain, or to all connections along the chain. Although the diagram 523 is linear, each participant might be engaged in multiple, 524 simultaneous communications. For example, B might be receiving 525 requests from many clients other than A, and/or forwarding requests 526 to servers other than C, at the same time that it is handling A's 527 request. 529 We use the terms "upstream" and "downstream" to describe various 530 requirements in relation to the directional flow of a message: all 531 messages flow from upstream to downstream. Likewise, we use the 532 terms "inbound" and "outbound" to refer to directions in relation to 533 the request path: "inbound" means toward the origin server and 534 "outbound" means toward the user agent. 536 A "proxy" is a message forwarding agent that is selected by the 537 client, usually via local configuration rules, to receive requests 538 for some type(s) of absolute URI and attempt to satisfy those 539 requests via translation through the HTTP interface. Some 540 translations are minimal, such as for proxy requests for "http" URIs, 541 whereas other requests might require translation to and from entirely 542 different application-layer protocols. Proxies are often used to 543 group an organization's HTTP requests through a common intermediary 544 for the sake of security, annotation services, or shared caching. 546 An HTTP-to-HTTP proxy is called a "transforming proxy" if it is 547 designed or configured to modify request or response messages in a 548 semantically meaningful way (i.e., modifications, beyond those 549 required by normal HTTP processing, that change the message in a way 550 that would be significant to the original sender or potentially 551 significant to downstream recipients). For example, a transforming 552 proxy might be acting as a shared annotation server (modifying 553 responses to include references to a local annotation database), a 554 malware filter, a format transcoder, or an intranet-to-Internet 555 privacy filter. Such transformations are presumed to be desired by 556 the client (or client organization) that selected the proxy and are 557 beyond the scope of this specification. However, when a proxy is not 558 intended to transform a given message, we use the term "non- 559 transforming proxy" to target requirements that preserve HTTP message 560 semantics. 562 A "gateway" (a.k.a., "reverse proxy") is a receiving agent that acts 563 as a layer above some other server(s) and translates the received 564 requests to the underlying server's protocol. Gateways are often 565 used to encapsulate legacy or untrusted information services, to 566 improve server performance through "accelerator" caching, and to 567 enable partitioning or load-balancing of HTTP services across 568 multiple machines. 570 A gateway behaves as an origin server on its outbound connection and 571 as a user agent on its inbound connection. All HTTP requirements 572 applicable to an origin server also apply to the outbound 573 communication of a gateway. A gateway communicates with inbound 574 servers using any protocol that it desires, including private 575 extensions to HTTP that are outside the scope of this specification. 576 However, an HTTP-to-HTTP gateway that wishes to interoperate with 577 third-party HTTP servers MUST comply with HTTP user agent 578 requirements on the gateway's inbound connection and MUST implement 579 the Connection (Section 9.1) and Via (Section 9.9) header fields for 580 both connections. 582 A "tunnel" acts as a blind relay between two connections without 583 changing the messages. Once active, a tunnel is not considered a 584 party to the HTTP communication, though the tunnel might have been 585 initiated by an HTTP request. A tunnel ceases to exist when both 586 ends of the relayed connection are closed. Tunnels are used to 587 extend a virtual connection through an intermediary, such as when 588 transport-layer security is used to establish private communication 589 through a shared firewall proxy. 591 In addition, there may exist network intermediaries that are not 592 considered part of the HTTP communication but nevertheless act as 593 filters or redirecting agents (usually violating HTTP semantics, 594 causing security problems, and otherwise making a mess of things). 595 Such a network intermediary, often referred to as an "interception 596 proxy" [RFC3040], "transparent proxy" [RFC1919], or "captive portal", 597 differs from an HTTP proxy because it has not been selected by the 598 client. Instead, the network intermediary redirects outgoing TCP 599 port 80 packets (and occasionally other common port traffic) to an 600 internal HTTP server. Interception proxies are commonly found on 601 public network access points, as a means of enforcing account 602 subscription prior to allowing use of non-local Internet services, 603 and within corporate firewalls to enforce network usage policies. 604 They are indistinguishable from a man-in-the-middle attack. 606 2.4. Caches 608 A "cache" is a local store of previous response messages and the 609 subsystem that controls its message storage, retrieval, and deletion. 610 A cache stores cacheable responses in order to reduce the response 611 time and network bandwidth consumption on future, equivalent 612 requests. Any client or server MAY employ a cache, though a cache 613 cannot be used by a server while it is acting as a tunnel. 615 The effect of a cache is that the request/response chain is shortened 616 if one of the participants along the chain has a cached response 617 applicable to that request. The following illustrates the resulting 618 chain if B has a cached copy of an earlier response from O (via C) 619 for a request which has not been cached by UA or A. 621 > > 622 UA =========== A =========== B - - - - - - C - - - - - - O 623 < < 625 A response is "cacheable" if a cache is allowed to store a copy of 626 the response message for use in answering subsequent requests. Even 627 when a response is cacheable, there might be additional constraints 628 placed by the client or by the origin server on when that cached 629 response can be used for a particular request. HTTP requirements for 630 cache behavior and cacheable responses are defined in Section 2 of 631 [Part6]. 633 There are a wide variety of architectures and configurations of 634 caches and proxies deployed across the World Wide Web and inside 635 large organizations. These systems include national hierarchies of 636 proxy caches to save transoceanic bandwidth, systems that broadcast 637 or multicast cache entries, organizations that distribute subsets of 638 cached data via optical media, and so on. 640 2.5. Protocol Versioning 642 HTTP uses a "." numbering scheme to indicate versions 643 of the protocol. This specification defines version "1.1". The 644 protocol version as a whole indicates the sender's compliance with 645 the set of requirements laid out in that version's corresponding 646 specification of HTTP. 648 The version of an HTTP message is indicated by an HTTP-Version field 649 in the first line of the message. HTTP-Version is case-sensitive. 651 HTTP-Version = HTTP-Prot-Name "/" 1*DIGIT "." 1*DIGIT 652 HTTP-Prot-Name = %x48.54.54.50 ; "HTTP", case-sensitive 654 The HTTP version number consists of two non-negative decimal integers 655 separated by a "." (period or decimal point). The first number 656 ("major version") indicates the HTTP messaging syntax, whereas the 657 second number ("minor version") indicates the highest minor version 658 to which the sender is at least conditionally compliant and able to 659 understand for future communication. The minor version advertises 660 the sender's communication capabilities even when the sender is only 661 using a backwards-compatible subset of the protocol, thereby letting 662 the recipient know that more advanced features can be used in 663 response (by servers) or in future requests (by clients). 665 When comparing HTTP versions, the numbers MUST be compared 666 numerically rather than lexically. For example, HTTP/2.4 is a lower 667 version than HTTP/2.13, which in turn is lower than HTTP/12.3. 668 Leading zeros MUST be ignored by recipients and MUST NOT be sent. 670 When an HTTP/1.1 message is sent to an HTTP/1.0 recipient [RFC1945] 671 or a recipient whose version is unknown, the HTTP/1.1 message is 672 constructed such that it can be interpreted as a valid HTTP/1.0 673 message if all of the newer features are ignored. This specification 674 places recipient-version requirements on some new features so that a 675 compliant sender will only use compatible features until it has 676 determined, through configuration or the receipt of a message, that 677 the recipient supports HTTP/1.1. 679 The interpretation of an HTTP header field does not change between 680 minor versions of the same major version, though the default behavior 681 of a recipient in the absence of such a field can change. Unless 682 specified otherwise, header fields defined in HTTP/1.1 are defined 683 for all versions of HTTP/1.x. In particular, the Host and Connection 684 header fields ought to be implemented by all HTTP/1.x implementations 685 whether or not they advertise compliance with HTTP/1.1. 687 New header fields can be defined such that, when they are understood 688 by a recipient, they might override or enhance the interpretation of 689 previously defined header fields. When an implementation receives an 690 unrecognized header field, the recipient MUST ignore that header 691 field for local processing regardless of the message's HTTP version. 692 An unrecognized header field received by a proxy MUST be forwarded 693 downstream unless the header field's field-name is listed in the 694 message's Connection header-field (see Section 9.1). These 695 requirements allow HTTP's functionality to be enhanced without 696 requiring prior update of all compliant intermediaries. 698 Intermediaries that process HTTP messages (i.e., all intermediaries 699 other than those acting as a tunnel) MUST send their own HTTP-Version 700 in forwarded messages. In other words, they MUST NOT blindly forward 701 the first line of an HTTP message without ensuring that the protocol 702 version matches what the intermediary understands, and is at least 703 conditionally compliant to, for both the receiving and sending of 704 messages. Forwarding an HTTP message without rewriting the HTTP- 705 Version might result in communication errors when downstream 706 recipients use the message sender's version to determine what 707 features are safe to use for later communication with that sender. 709 An HTTP client SHOULD send a request version equal to the highest 710 version for which the client is at least conditionally compliant and 711 whose major version is no higher than the highest version supported 712 by the server, if this is known. An HTTP client MUST NOT send a 713 version for which it is not at least conditionally compliant. 715 An HTTP client MAY send a lower request version if it is known that 716 the server incorrectly implements the HTTP specification, but only 717 after the client has attempted at least one normal request and 718 determined from the response status or header fields (e.g., Server) 719 that the server improperly handles higher request versions. 721 An HTTP server SHOULD send a response version equal to the highest 722 version for which the server is at least conditionally compliant and 723 whose major version is less than or equal to the one received in the 724 request. An HTTP server MUST NOT send a version for which it is not 725 at least conditionally compliant. A server MAY send a 505 (HTTP 726 Version Not Supported) response if it cannot send a response using 727 the major version used in the client's request. 729 An HTTP server MAY send an HTTP/1.0 response to an HTTP/1.0 request 730 if it is known or suspected that the client incorrectly implements 731 the HTTP specification and is incapable of correctly processing later 732 version responses, such as when a client fails to parse the version 733 number correctly or when an intermediary is known to blindly forward 734 the HTTP-Version even when it doesn't comply with the given minor 735 version of the protocol. Such protocol downgrades SHOULD NOT be 736 performed unless triggered by specific client attributes, such as 737 when one or more of the request header fields (e.g., User-Agent) 738 uniquely match the values sent by a client known to be in error. 740 The intention of HTTP's versioning design is that the major number 741 will only be incremented if an incompatible message syntax is 742 introduced, and that the minor number will only be incremented when 743 changes made to the protocol have the effect of adding to the message 744 semantics or implying additional capabilities of the sender. 745 However, the minor version was not incremented for the changes 746 introduced between [RFC2068] and [RFC2616], and this revision is 747 specifically avoiding any such changes to the protocol. 749 2.6. Uniform Resource Identifiers 751 Uniform Resource Identifiers (URIs) [RFC3986] are used throughout 752 HTTP as the means for identifying resources. URI references are used 753 to target requests, indicate redirects, and define relationships. 754 HTTP does not limit what a resource might be; it merely defines an 755 interface that can be used to interact with a resource via HTTP. 756 More information on the scope of URIs and resources can be found in 757 [RFC3986]. 759 This specification adopts the definitions of "URI-reference", 760 "absolute-URI", "relative-part", "port", "host", "path-abempty", 761 "path-absolute", "query", and "authority" from the URI generic syntax 762 [RFC3986]. In addition, we define a partial-URI rule for protocol 763 elements that allow a relative URI but not a fragment. 765 URI-reference = 766 absolute-URI = 767 relative-part = 768 authority = 769 path-abempty = 770 path-absolute = 771 port = 772 query = 773 uri-host = 774 partial-URI = relative-part [ "?" query ] 776 Each protocol element in HTTP that allows a URI reference will 777 indicate in its ABNF production whether the element allows any form 778 of reference (URI-reference), only a URI in absolute form (absolute- 779 URI), only the path and optional query components, or some 780 combination of the above. Unless otherwise indicated, URI references 781 are parsed relative to the effective request URI, which defines the 782 default base URI for references in both the request and its 783 corresponding response. 785 2.6.1. http URI scheme 787 The "http" URI scheme is hereby defined for the purpose of minting 788 identifiers according to their association with the hierarchical 789 namespace governed by a potential HTTP origin server listening for 790 TCP connections on a given port. 792 http-URI = "http:" "//" authority path-abempty [ "?" query ] 794 The HTTP origin server is identified by the generic syntax's 795 authority component, which includes a host identifier and optional 796 TCP port ([RFC3986], Section 3.2.2). The remainder of the URI, 797 consisting of both the hierarchical path component and optional query 798 component, serves as an identifier for a potential resource within 799 that origin server's name space. 801 If the host identifier is provided as an IP literal or IPv4 address, 802 then the origin server is any listener on the indicated TCP port at 803 that IP address. If host is a registered name, then that name is 804 considered an indirect identifier and the recipient might use a name 805 resolution service, such as DNS, to find the address of a listener 806 for that host. The host MUST NOT be empty; if an "http" URI is 807 received with an empty host, then it MUST be rejected as invalid. If 808 the port subcomponent is empty or not given, then TCP port 80 is 809 assumed (the default reserved port for WWW services). 811 Regardless of the form of host identifier, access to that host is not 812 implied by the mere presence of its name or address. The host might 813 or might not exist and, even when it does exist, might or might not 814 be running an HTTP server or listening to the indicated port. The 815 "http" URI scheme makes use of the delegated nature of Internet names 816 and addresses to establish a naming authority (whatever entity has 817 the ability to place an HTTP server at that Internet name or address) 818 and allows that authority to determine which names are valid and how 819 they might be used. 821 When an "http" URI is used within a context that calls for access to 822 the indicated resource, a client MAY attempt access by resolving the 823 host to an IP address, establishing a TCP connection to that address 824 on the indicated port, and sending an HTTP request message to the 825 server containing the URI's identifying data as described in 826 Section 4. If the server responds to that request with a non-interim 827 HTTP response message, as described in Section 5, then that response 828 is considered an authoritative answer to the client's request. 830 Although HTTP is independent of the transport protocol, the "http" 831 scheme is specific to TCP-based services because the name delegation 832 process depends on TCP for establishing authority. An HTTP service 833 based on some other underlying connection protocol would presumably 834 be identified using a different URI scheme, just as the "https" 835 scheme (below) is used for servers that require an SSL/TLS transport 836 layer on a connection. Other protocols might also be used to provide 837 access to "http" identified resources -- it is only the authoritative 838 interface used for mapping the namespace that is specific to TCP. 840 The URI generic syntax for authority also includes a deprecated 841 userinfo subcomponent ([RFC3986], Section 3.2.1) for including user 842 authentication information in the URI. Some implementations make use 843 of the userinfo component for internal configuration of 844 authentication information, such as within command invocation 845 options, configuration files, or bookmark lists, even though such 846 usage might expose a user identifier or password. Senders MUST NOT 847 include a userinfo subcomponent (and its "@" delimiter) when 848 transmitting an "http" URI in a message. Recipients of HTTP messages 849 that contain a URI reference SHOULD parse for the existence of 850 userinfo and treat its presence as an error, likely indicating that 851 the deprecated subcomponent is being used to obscure the authority 852 for the sake of phishing attacks. 854 2.6.2. https URI scheme 856 The "https" URI scheme is hereby defined for the purpose of minting 857 identifiers according to their association with the hierarchical 858 namespace governed by a potential HTTP origin server listening for 859 SSL/TLS-secured connections on a given TCP port. 861 All of the requirements listed above for the "http" scheme are also 862 requirements for the "https" scheme, except that a default TCP port 863 of 443 is assumed if the port subcomponent is empty or not given, and 864 the TCP connection MUST be secured for privacy through the use of 865 strong encryption prior to sending the first HTTP request. 867 https-URI = "https:" "//" authority path-abempty [ "?" query ] 869 Unlike the "http" scheme, responses to "https" identified requests 870 are never "public" and thus MUST NOT be reused for shared caching. 871 They can, however, be reused in a private cache if the message is 872 cacheable by default in HTTP or specifically indicated as such by the 873 Cache-Control header field (Section 3.2 of [Part6]). 875 Resources made available via the "https" scheme have no shared 876 identity with the "http" scheme even if their resource identifiers 877 indicate the same authority (the same host listening to the same TCP 878 port). They are distinct name spaces and are considered to be 879 distinct origin servers. However, an extension to HTTP that is 880 defined to apply to entire host domains, such as the Cookie protocol 881 [draft-ietf-httpstate-cookie], can allow information set by one 882 service to impact communication with other services within a matching 883 group of host domains. 885 The process for authoritative access to an "https" identified 886 resource is defined in [RFC2818]. 888 2.6.3. http and https URI Normalization and Comparison 890 Since the "http" and "https" schemes conform to the URI generic 891 syntax, such URIs are normalized and compared according to the 892 algorithm defined in [RFC3986], Section 6, using the defaults 893 described above for each scheme. 895 If the port is equal to the default port for a scheme, the normal 896 form is to elide the port subcomponent. Likewise, an empty path 897 component is equivalent to an absolute path of "/", so the normal 898 form is to provide a path of "/" instead. The scheme and host are 899 case-insensitive and normally provided in lowercase; all other 900 components are compared in a case-sensitive manner. Characters other 901 than those in the "reserved" set are equivalent to their percent- 902 encoded octets (see [RFC3986], Section 2.1): the normal form is to 903 not encode them. 905 For example, the following three URIs are equivalent: 907 http://example.com:80/~smith/home.html 908 http://EXAMPLE.com/%7Esmith/home.html 909 http://EXAMPLE.com:/%7esmith/home.html 911 3. Message Format 913 All HTTP/1.1 messages consist of a start-line followed by a sequence 914 of octets in a format similar to the Internet Message Format 915 [RFC5322]: zero or more header fields (collectively referred to as 916 the "headers" or the "header section"), an empty line indicating the 917 end of the header section, and an optional message-body. 919 An HTTP message can either be a request from client to server or a 920 response from server to client. Syntactically, the two types of 921 message differ only in the start-line, which is either a Request-Line 922 (for requests) or a Status-Line (for responses), and in the algorithm 923 for determining the length of the message-body (Section 3.3). In 924 theory, a client could receive requests and a server could receive 925 responses, distinguishing them by their different start-line formats, 926 but in practice servers are implemented to only expect a request (a 927 response is interpreted as an unknown or invalid request method) and 928 clients are implemented to only expect a response. 930 HTTP-message = start-line 931 *( header-field CRLF ) 932 CRLF 933 [ message-body ] 934 start-line = Request-Line / Status-Line 936 Implementations MUST NOT send whitespace between the start-line and 937 the first header field. The presence of such whitespace in a request 938 might be an attempt to trick a server into ignoring that field or 939 processing the line after it as a new request, either of which might 940 result in a security vulnerability if other implementations within 941 the request chain interpret the same message differently. Likewise, 942 the presence of such whitespace in a response might be ignored by 943 some clients or cause others to cease parsing. 945 3.1. Message Parsing Robustness 947 In the interest of robustness, servers SHOULD ignore at least one 948 empty line received where a Request-Line is expected. In other 949 words, if the server is reading the protocol stream at the beginning 950 of a message and receives a CRLF first, it SHOULD ignore the CRLF. 952 Some old HTTP/1.0 client implementations send an extra CRLF after a 953 POST request as a lame workaround for some early server applications 954 that failed to read message-body content that was not terminated by a 955 line-ending. An HTTP/1.1 client MUST NOT preface or follow a request 956 with an extra CRLF. If terminating the request message-body with a 957 line-ending is desired, then the client MUST include the terminating 958 CRLF octets as part of the message-body length. 960 When a server listening only for HTTP request messages, or processing 961 what appears from the start-line to be an HTTP request message, 962 receives a sequence of octets that does not match the HTTP-message 963 grammar aside from the robustness exceptions listed above, the server 964 MUST respond with an HTTP/1.1 400 (Bad Request) response. 966 The normal procedure for parsing an HTTP message is to read the 967 start-line into a structure, read each header field into a hash table 968 by field name until the empty line, and then use the parsed data to 969 determine if a message-body is expected. If a message-body has been 970 indicated, then it is read as a stream until an amount of octets 971 equal to the message-body length is read or the connection is closed. 972 Care must be taken to parse an HTTP message as a sequence of octets 973 in an encoding that is a superset of US-ASCII. Attempting to parse 974 HTTP as a stream of Unicode characters in a character encoding like 975 UTF-16 might introduce security flaws due to the differing ways that 976 such parsers interpret invalid characters. 978 HTTP allows the set of defined header fields to be extended without 979 changing the protocol version (see Section 10.1). Unrecognized 980 header fields MUST be forwarded by a proxy unless the proxy is 981 specifically configured to block or otherwise transform such fields. 982 Unrecognized header fields SHOULD be ignored by other recipients. 984 3.2. Header Fields 986 Each HTTP header field consists of a case-insensitive field name 987 followed by a colon (":"), optional whitespace, and the field value. 989 header-field = field-name ":" OWS [ field-value ] OWS 990 field-name = token 991 field-value = *( field-content / OWS ) 992 field-content = *( WSP / VCHAR / obs-text ) 994 No whitespace is allowed between the header field name and colon. 995 For security reasons, any request message received containing such 996 whitespace MUST be rejected with a response code of 400 (Bad 997 Request). A proxy MUST remove any such whitespace from a response 998 message before forwarding the message downstream. 1000 A field value MAY be preceded by optional whitespace (OWS); a single 1001 SP is preferred. The field value does not include any leading or 1002 trailing white space: OWS occurring before the first non-whitespace 1003 octet of the field value or after the last non-whitespace octet of 1004 the field value is ignored and SHOULD be removed before further 1005 processing (as this does not change the meaning of the header field). 1007 The order in which header fields with differing field names are 1008 received is not significant. However, it is "good practice" to send 1009 header fields that contain control data first, such as Host on 1010 requests and Date on responses, so that implementations can decide 1011 when not to handle a message as early as possible. A server MUST 1012 wait until the entire header section is received before interpreting 1013 a request message, since later header fields might include 1014 conditionals, authentication credentials, or deliberately misleading 1015 duplicate header fields that would impact request processing. 1017 Multiple header fields with the same field name MUST NOT be sent in a 1018 message unless the entire field value for that header field is 1019 defined as a comma-separated list [i.e., #(values)]. Multiple header 1020 fields with the same field name can be combined into one "field-name: 1021 field-value" pair, without changing the semantics of the message, by 1022 appending each subsequent field value to the combined field value in 1023 order, separated by a comma. The order in which header fields with 1024 the same field name are received is therefore significant to the 1025 interpretation of the combined field value; a proxy MUST NOT change 1026 the order of these field values when forwarding a message. 1028 Note: The "Set-Cookie" header field as implemented in practice can 1029 occur multiple times, but does not use the list syntax, and thus 1030 cannot be combined into a single line 1031 ([draft-ietf-httpstate-cookie]). (See Appendix A.2.3 of [Kri2001] 1032 for details.) Also note that the Set-Cookie2 header field 1033 specified in [RFC2965] does not share this problem. 1035 Historically, HTTP header field values could be extended over 1036 multiple lines by preceding each extra line with at least one space 1037 or horizontal tab octet (line folding). This specification 1038 deprecates such line folding except within the message/http media 1039 type (Section 10.3.1). HTTP/1.1 senders MUST NOT produce messages 1040 that include line folding (i.e., that contain any field-content that 1041 matches the obs-fold rule) unless the message is intended for 1042 packaging within the message/http media type. HTTP/1.1 recipients 1043 SHOULD accept line folding and replace any embedded obs-fold 1044 whitespace with a single SP prior to interpreting the field value or 1045 forwarding the message downstream. 1047 Historically, HTTP has allowed field content with text in the ISO- 1048 8859-1 [ISO-8859-1] character encoding and supported other character 1049 sets only through use of [RFC2047] encoding. In practice, most HTTP 1050 header field values use only a subset of the US-ASCII character 1051 encoding [USASCII]. Newly defined header fields SHOULD limit their 1052 field values to US-ASCII octets. Recipients SHOULD treat other (obs- 1053 text) octets in field content as opaque data. 1055 Comments can be included in some HTTP header fields by surrounding 1056 the comment text with parentheses. Comments are only allowed in 1057 fields containing "comment" as part of their field value definition. 1059 comment = "(" *( ctext / quoted-cpair / comment ) ")" 1060 ctext = OWS / %x21-27 / %x2A-5B / %x5D-7E / obs-text 1061 ; OWS / / obs-text 1063 The backslash octet ("\") can be used as a single-octet quoting 1064 mechanism within comment constructs: 1066 quoted-cpair = "\" ( WSP / VCHAR / obs-text ) 1068 Senders SHOULD NOT escape octets that do not require escaping (i.e., 1069 other than the backslash octet "\" and the parentheses "(" and ")"). 1071 3.3. Message Body 1073 The message-body (if any) of an HTTP message is used to carry the 1074 payload body associated with the request or response. 1076 message-body = *OCTET 1078 The message-body differs from the payload body only when a transfer- 1079 coding has been applied, as indicated by the Transfer-Encoding header 1080 field (Section 9.7). If more than one Transfer-Encoding header field 1081 is present in a message, the multiple field-values MUST be combined 1082 into one field-value, according to the algorithm defined in 1083 Section 3.2, before determining the message-body length. 1085 When one or more transfer-codings are applied to a payload in order 1086 to form the message-body, the Transfer-Encoding header field MUST 1087 contain the list of transfer-codings applied. Transfer-Encoding is a 1088 property of the message, not of the payload, and thus MAY be added or 1089 removed by any implementation along the request/response chain under 1090 the constraints found in Section 6.2. 1092 If a message is received that has multiple Content-Length header 1093 fields (Section 9.2) with field-values consisting of the same decimal 1094 value, or a single Content-Length header field with a field value 1095 containing a list of identical decimal values (e.g., "Content-Length: 1096 42, 42"), indicating that duplicate Content-Length header fields have 1097 been generated or combined by an upstream message processor, then the 1098 recipient MUST replace the duplicated fields or field-values with a 1099 single valid Content-Length field containing that decimal value prior 1100 to determining the message-body length. 1102 The rules for when a message-body is allowed in a message differ for 1103 requests and responses. 1105 The presence of a message-body in a request is signaled by the 1106 inclusion of a Content-Length or Transfer-Encoding header field in 1107 the request's header fields, even if the request method does not 1108 define any use for a message-body. This allows the request message 1109 framing algorithm to be independent of method semantics. 1111 For response messages, whether or not a message-body is included with 1112 a message is dependent on both the request method and the response 1113 status code (Section 5.1.1). Responses to the HEAD request method 1114 never include a message-body because the associated response header 1115 fields (e.g., Transfer-Encoding, Content-Length, etc.) only indicate 1116 what their values would have been if the request method had been GET. 1117 All 1xx (Informational), 204 (No Content), and 304 (Not Modified) 1118 responses MUST NOT include a message-body. All other responses do 1119 include a message-body, although the body MAY be of zero length. 1121 The length of the message-body is determined by one of the following 1122 (in order of precedence): 1124 1. Any response to a HEAD request and any response with a status 1125 code of 100-199, 204, or 304 is always terminated by the first 1126 empty line after the header fields, regardless of the header 1127 fields present in the message, and thus cannot contain a message- 1128 body. 1130 2. If a Transfer-Encoding header field is present and the "chunked" 1131 transfer-coding (Section 6.2) is the final encoding, the message- 1132 body length is determined by reading and decoding the chunked 1133 data until the transfer-coding indicates the data is complete. 1135 If a Transfer-Encoding header field is present in a response and 1136 the "chunked" transfer-coding is not the final encoding, the 1137 message-body length is determined by reading the connection until 1138 it is closed by the server. If a Transfer-Encoding header field 1139 is present in a request and the "chunked" transfer-coding is not 1140 the final encoding, the message-body length cannot be determined 1141 reliably; the server MUST respond with the 400 (Bad Request) 1142 status code and then close the connection. 1144 If a message is received with both a Transfer-Encoding header 1145 field and a Content-Length header field, the Transfer-Encoding 1146 overrides the Content-Length. Such a message might indicate an 1147 attempt to perform request or response smuggling (bypass of 1148 security-related checks on message routing or content) and thus 1149 ought to be handled as an error. The provided Content-Length 1150 MUST be removed, prior to forwarding the message downstream, or 1151 replaced with the real message-body length after the transfer- 1152 coding is decoded. 1154 3. If a message is received without Transfer-Encoding and with 1155 either multiple Content-Length header fields having differing 1156 field-values or a single Content-Length header field having an 1157 invalid value, then the message framing is invalid and MUST be 1158 treated as an error to prevent request or response smuggling. If 1159 this is a request message, the server MUST respond with a 400 1160 (Bad Request) status code and then close the connection. If this 1161 is a response message received by a proxy, the proxy MUST discard 1162 the received response, send a 502 (Bad Gateway) status code as 1163 its downstream response, and then close the connection. If this 1164 is a response message received by a user-agent, it MUST be 1165 treated as an error by discarding the message and closing the 1166 connection. 1168 4. If a valid Content-Length header field is present without 1169 Transfer-Encoding, its decimal value defines the message-body 1170 length in octets. If the actual number of octets sent in the 1171 message is less than the indicated Content-Length, the recipient 1172 MUST consider the message to be incomplete and treat the 1173 connection as no longer usable. If the actual number of octets 1174 sent in the message is more than the indicated Content-Length, 1175 the recipient MUST only process the message-body up to the field 1176 value's number of octets; the remainder of the message MUST 1177 either be discarded or treated as the next message in a pipeline. 1178 For the sake of robustness, a user-agent MAY attempt to detect 1179 and correct such an error in message framing if it is parsing the 1180 response to the last request on on a connection and the 1181 connection has been closed by the server. 1183 5. If this is a request message and none of the above are true, then 1184 the message-body length is zero (no message-body is present). 1186 6. Otherwise, this is a response message without a declared message- 1187 body length, so the message-body length is determined by the 1188 number of octets received prior to the server closing the 1189 connection. 1191 Since there is no way to distinguish a successfully completed, close- 1192 delimited message from a partially-received message interrupted by 1193 network failure, implementations SHOULD use encoding or length- 1194 delimited messages whenever possible. The close-delimiting feature 1195 exists primarily for backwards compatibility with HTTP/1.0. 1197 A server MAY reject a request that contains a message-body but not a 1198 Content-Length by responding with 411 (Length Required). 1200 Unless a transfer-coding other than "chunked" has been applied, a 1201 client that sends a request containing a message-body SHOULD use a 1202 valid Content-Length header field if the message-body length is known 1203 in advance, rather than the "chunked" encoding, since some existing 1204 services respond to "chunked" with a 411 (Length Required) status 1205 code even though they understand the chunked encoding. This is 1206 typically because such services are implemented via a gateway that 1207 requires a content-length in advance of being called and the server 1208 is unable or unwilling to buffer the entire request before 1209 processing. 1211 A client that sends a request containing a message-body MUST include 1212 a valid Content-Length header field if it does not know the server 1213 will handle HTTP/1.1 (or later) requests; such knowledge can be in 1214 the form of specific user configuration or by remembering the version 1215 of a prior received response. 1217 Request messages that are prematurely terminated, possibly due to a 1218 cancelled connection or a server-imposed time-out exception, MUST 1219 result in closure of the connection; sending an HTTP/1.1 error 1220 response prior to closing the connection is OPTIONAL. Response 1221 messages that are prematurely terminated, usually by closure of the 1222 connection prior to receiving the expected number of octets or by 1223 failure to decode a transfer-encoded message-body, MUST be recorded 1224 as incomplete. A user agent MUST NOT render an incomplete response 1225 message-body as if it were complete (i.e., some indication must be 1226 given to the user that an error occurred). Cache requirements for 1227 incomplete responses are defined in Section 2.1.1 of [Part6]. 1229 A server MUST read the entire request message-body or close the 1230 connection after sending its response, since otherwise the remaining 1231 data on a persistent connection would be misinterpreted as the next 1232 request. Likewise, a client MUST read the entire response message- 1233 body if it intends to reuse the same connection for a subsequent 1234 request. Pipelining multiple requests on a connection is described 1235 in Section 7.1.2.2. 1237 3.4. General Header Fields 1239 There are a few header fields which have general applicability for 1240 both request and response messages, but which do not apply to the 1241 payload being transferred. These header fields apply only to the 1242 message being transmitted. 1244 +-------------------+---------------+ 1245 | Header Field Name | Defined in... | 1246 +-------------------+---------------+ 1247 | Connection | Section 9.1 | 1248 | Date | Section 9.3 | 1249 | Trailer | Section 9.6 | 1250 | Transfer-Encoding | Section 9.7 | 1251 | Upgrade | Section 9.8 | 1252 | Via | Section 9.9 | 1253 +-------------------+---------------+ 1255 4. Request 1257 A request message from a client to a server begins with a Request- 1258 Line, followed by zero or more header fields, an empty line 1259 signifying the end of the header block, and an optional message body. 1261 Request = Request-Line ; Section 4.1 1262 *( header-field CRLF ) ; Section 3.2 1263 CRLF 1264 [ message-body ] ; Section 3.3 1266 4.1. Request-Line 1268 The Request-Line begins with a method token, followed by a single 1269 space (SP), the request-target, another single space (SP), the 1270 protocol version, and ending with CRLF. 1272 Request-Line = Method SP request-target SP HTTP-Version CRLF 1274 4.1.1. Method 1276 The Method token indicates the request method to be performed on the 1277 target resource. The request method is case-sensitive. 1279 Method = token 1281 4.1.2. request-target 1283 The request-target identifies the target resource upon which to apply 1284 the request. In most cases, the user agent is provided a URI 1285 reference from which it determines an absolute URI for identifying 1286 the target resource. When a request to the resource is initiated, 1287 all or part of that URI is used to construct the HTTP request-target. 1289 request-target = "*" 1290 / absolute-URI 1291 / ( path-absolute [ "?" query ] ) 1292 / authority 1294 The four options for request-target are dependent on the nature of 1295 the request. 1297 The asterisk "*" form of request-target, which MUST NOT be used with 1298 any request method other than OPTIONS, means that the request applies 1299 to the server as a whole (the listening process) rather than to a 1300 specific named resource at that server. For example, 1302 OPTIONS * HTTP/1.1 1304 The "absolute-URI" form is REQUIRED when the request is being made to 1305 a proxy. The proxy is requested to either forward the request or 1306 service it from a valid cache, and then return the response. Note 1307 that the proxy MAY forward the request on to another proxy or 1308 directly to the server specified by the absolute-URI. In order to 1309 avoid request loops, a proxy that forwards requests to other proxies 1310 MUST be able to recognize and exclude all of its own server names, 1311 including any aliases, local variations, and the numeric IP address. 1312 An example Request-Line would be: 1314 GET http://www.example.org/pub/WWW/TheProject.html HTTP/1.1 1316 To allow for transition to absolute-URIs in all requests in future 1317 versions of HTTP, all HTTP/1.1 servers MUST accept the absolute-URI 1318 form in requests, even though HTTP/1.1 clients will only generate 1319 them in requests to proxies. 1321 If a proxy receives a host name that is not a fully qualified domain 1322 name, it MAY add its domain to the host name it received. If a proxy 1323 receives a fully qualified domain name, the proxy MUST NOT change the 1324 host name. 1326 The "authority form" is only used by the CONNECT request method 1327 (Section 7.9 of [Part2]). 1329 The most common form of request-target is that used when making a 1330 request to an origin server ("origin form"). In this case, the 1331 absolute path and query components of the URI MUST be transmitted as 1332 the request-target, and the authority component MUST be transmitted 1333 in a Host header field. For example, a client wishing to retrieve a 1334 representation of the resource, as identified above, directly from 1335 the origin server would open (or reuse) a TCP connection to port 80 1336 of the host "www.example.org" and send the lines: 1338 GET /pub/WWW/TheProject.html HTTP/1.1 1339 Host: www.example.org 1341 followed by the remainder of the Request. Note that the origin form 1342 of request-target always starts with an absolute path; if the target 1343 resource's URI path is empty, then an absolute path of "/" MUST be 1344 provided in the request-target. 1346 If a proxy receives an OPTIONS request with an absolute-URI form of 1347 request-target in which the URI has an empty path and no query 1348 component, then the last proxy on the request chain MUST use a 1349 request-target of "*" when it forwards the request to the indicated 1350 origin server. 1352 For example, the request 1354 OPTIONS http://www.example.org:8001 HTTP/1.1 1356 would be forwarded by the final proxy as 1358 OPTIONS * HTTP/1.1 1359 Host: www.example.org:8001 1361 after connecting to port 8001 of host "www.example.org". 1363 The request-target is transmitted in the format specified in 1364 Section 2.6.1. If the request-target is percent-encoded ([RFC3986], 1365 Section 2.1), the origin server MUST decode the request-target in 1366 order to properly interpret the request. Servers SHOULD respond to 1367 invalid request-targets with an appropriate status code. 1369 A non-transforming proxy MUST NOT rewrite the "path-absolute" part of 1370 the received request-target when forwarding it to the next inbound 1371 server, except as noted above to replace a null path-absolute with 1372 "/" or "*". 1374 Note: The "no rewrite" rule prevents the proxy from changing the 1375 meaning of the request when the origin server is improperly using 1376 a non-reserved URI character for a reserved purpose. Implementors 1377 need to be aware that some pre-HTTP/1.1 proxies have been known to 1378 rewrite the request-target. 1380 HTTP does not place a pre-defined limit on the length of a request- 1381 target. A server MUST be prepared to receive URIs of unbounded 1382 length and respond with the 414 (URI Too Long) status code if the 1383 received request-target would be longer than the server wishes to 1384 handle (see Section 8.4.15 of [Part2]). 1386 Various ad-hoc limitations on request-target length are found in 1387 practice. It is RECOMMENDED that all HTTP senders and recipients 1388 support request-target lengths of 8000 or more octets. 1390 Note: Fragments ([RFC3986], Section 3.5) are not part of the 1391 request-target and thus will not be transmitted in an HTTP 1392 request. 1394 4.2. The Resource Identified by a Request 1396 The exact resource identified by an Internet request is determined by 1397 examining both the request-target and the Host header field. 1399 An origin server that does not allow resources to differ by the 1400 requested host MAY ignore the Host header field value when 1401 determining the resource identified by an HTTP/1.1 request. (But see 1402 Appendix B.1.1 for other requirements on Host support in HTTP/1.1.) 1404 An origin server that does differentiate resources based on the host 1405 requested (sometimes referred to as virtual hosts or vanity host 1406 names) MUST use the following rules for determining the requested 1407 resource on an HTTP/1.1 request: 1409 1. If request-target is an absolute-URI, the host is part of the 1410 request-target. Any Host header field value in the request MUST 1411 be ignored. 1413 2. If the request-target is not an absolute-URI, and the request 1414 includes a Host header field, the host is determined by the Host 1415 header field value. 1417 3. If the host as determined by rule 1 or 2 is not a valid host on 1418 the server, the response MUST be a 400 (Bad Request) error 1419 message. 1421 Recipients of an HTTP/1.0 request that lacks a Host header field MAY 1422 attempt to use heuristics (e.g., examination of the URI path for 1423 something unique to a particular host) in order to determine what 1424 exact resource is being requested. 1426 4.3. Effective Request URI 1428 HTTP requests often do not carry the absolute URI ([RFC3986], Section 1429 4.3) for the target resource; instead, the URI needs to be inferred 1430 from the request-target, Host header field, and connection context. 1431 The result of this process is called the "effective request URI". 1432 The "target resource" is the resource identified by the effective 1433 request URI. 1435 If the request-target is an absolute-URI, then the effective request 1436 URI is the request-target. 1438 If the request-target uses the path-absolute form or the asterisk 1439 form, and the Host header field is present, then the effective 1440 request URI is constructed by concatenating 1442 o the scheme name: "http" if the request was received over an 1443 insecure TCP connection, or "https" when received over a SSL/ 1444 TLS-secured TCP connection, 1446 o the octet sequence "://", 1447 o the authority component, as specified in the Host header field 1448 (Section 9.4), and 1450 o the request-target obtained from the Request-Line, unless the 1451 request-target is just the asterisk "*". 1453 If the request-target uses the path-absolute form or the asterisk 1454 form, and the Host header field is not present, then the effective 1455 request URI is undefined. 1457 Otherwise, when request-target uses the authority form, the effective 1458 request URI is undefined. 1460 Example 1: the effective request URI for the message 1462 GET /pub/WWW/TheProject.html HTTP/1.1 1463 Host: www.example.org:8080 1465 (received over an insecure TCP connection) is "http", plus "://", 1466 plus the authority component "www.example.org:8080", plus the 1467 request-target "/pub/WWW/TheProject.html", thus 1468 "http://www.example.org:8080/pub/WWW/TheProject.html". 1470 Example 2: the effective request URI for the message 1472 GET * HTTP/1.1 1473 Host: www.example.org 1475 (received over an SSL/TLS secured TCP connection) is "https", plus 1476 "://", plus the authority component "www.example.org", thus 1477 "https://www.example.org". 1479 Effective request URIs are compared using the rules described in 1480 Section 2.6.3, except that empty path components MUST NOT be treated 1481 as equivalent to an absolute path of "/". 1483 5. Response 1485 After receiving and interpreting a request message, a server responds 1486 with an HTTP response message. 1488 Response = Status-Line ; Section 5.1 1489 *( header-field CRLF ) ; Section 3.2 1490 CRLF 1491 [ message-body ] ; Section 3.3 1493 5.1. Status-Line 1495 The first line of a Response message is the Status-Line, consisting 1496 of the protocol version, a space (SP), the status code, another 1497 space, a possibly-empty textual phrase describing the status code, 1498 and ending with CRLF. 1500 Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF 1502 5.1.1. Status Code and Reason Phrase 1504 The Status-Code element is a 3-digit integer result code of the 1505 attempt to understand and satisfy the request. These codes are fully 1506 defined in Section 8 of [Part2]. The Reason Phrase exists for the 1507 sole purpose of providing a textual description associated with the 1508 numeric status code, out of deference to earlier Internet application 1509 protocols that were more frequently used with interactive text 1510 clients. A client SHOULD ignore the content of the Reason Phrase. 1512 The first digit of the Status-Code defines the class of response. 1513 The last two digits do not have any categorization role. There are 5 1514 values for the first digit: 1516 o 1xx: Informational - Request received, continuing process 1518 o 2xx: Success - The action was successfully received, understood, 1519 and accepted 1521 o 3xx: Redirection - Further action must be taken in order to 1522 complete the request 1524 o 4xx: Client Error - The request contains bad syntax or cannot be 1525 fulfilled 1527 o 5xx: Server Error - The server failed to fulfill an apparently 1528 valid request 1530 Status-Code = 3DIGIT 1531 Reason-Phrase = *( WSP / VCHAR / obs-text ) 1533 6. Protocol Parameters 1535 6.1. Date/Time Formats: Full Date 1537 HTTP applications have historically allowed three different formats 1538 for date/time stamps. However, the preferred format is a fixed- 1539 length subset of that defined by [RFC1123]: 1541 Sun, 06 Nov 1994 08:49:37 GMT ; RFC 1123 1543 The other formats are described here only for compatibility with 1544 obsolete implementations. 1546 Sunday, 06-Nov-94 08:49:37 GMT ; obsolete RFC 850 format 1547 Sun Nov 6 08:49:37 1994 ; ANSI C's asctime() format 1549 HTTP/1.1 clients and servers that parse a date value MUST accept all 1550 three formats (for compatibility with HTTP/1.0), though they MUST 1551 only generate the RFC 1123 format for representing HTTP-date values 1552 in header fields. See Appendix A for further information. 1554 All HTTP date/time stamps MUST be represented in Greenwich Mean Time 1555 (GMT), without exception. For the purposes of HTTP, GMT is exactly 1556 equal to UTC (Coordinated Universal Time). This is indicated in the 1557 first two formats by the inclusion of "GMT" as the three-letter 1558 abbreviation for time zone, and MUST be assumed when reading the 1559 asctime format. HTTP-date is case sensitive and MUST NOT include 1560 additional whitespace beyond that specifically included as SP in the 1561 grammar. 1563 HTTP-date = rfc1123-date / obs-date 1565 Preferred format: 1567 rfc1123-date = day-name "," SP date1 SP time-of-day SP GMT 1568 ; fixed length subset of the format defined in 1569 ; Section 5.2.14 of [RFC1123] 1571 day-name = %x4D.6F.6E ; "Mon", case-sensitive 1572 / %x54.75.65 ; "Tue", case-sensitive 1573 / %x57.65.64 ; "Wed", case-sensitive 1574 / %x54.68.75 ; "Thu", case-sensitive 1575 / %x46.72.69 ; "Fri", case-sensitive 1576 / %x53.61.74 ; "Sat", case-sensitive 1577 / %x53.75.6E ; "Sun", case-sensitive 1579 date1 = day SP month SP year 1580 ; e.g., 02 Jun 1982 1582 day = 2DIGIT 1583 month = %x4A.61.6E ; "Jan", case-sensitive 1584 / %x46.65.62 ; "Feb", case-sensitive 1585 / %x4D.61.72 ; "Mar", case-sensitive 1586 / %x41.70.72 ; "Apr", case-sensitive 1587 / %x4D.61.79 ; "May", case-sensitive 1588 / %x4A.75.6E ; "Jun", case-sensitive 1589 / %x4A.75.6C ; "Jul", case-sensitive 1590 / %x41.75.67 ; "Aug", case-sensitive 1591 / %x53.65.70 ; "Sep", case-sensitive 1592 / %x4F.63.74 ; "Oct", case-sensitive 1593 / %x4E.6F.76 ; "Nov", case-sensitive 1594 / %x44.65.63 ; "Dec", case-sensitive 1595 year = 4DIGIT 1597 GMT = %x47.4D.54 ; "GMT", case-sensitive 1599 time-of-day = hour ":" minute ":" second 1600 ; 00:00:00 - 23:59:59 1602 hour = 2DIGIT 1603 minute = 2DIGIT 1604 second = 2DIGIT 1606 The semantics of day-name, day, month, year, and time-of-day are the 1607 same as those defined for the RFC 5322 constructs with the 1608 corresponding name ([RFC5322], Section 3.3). 1610 Obsolete formats: 1612 obs-date = rfc850-date / asctime-date 1613 rfc850-date = day-name-l "," SP date2 SP time-of-day SP GMT 1614 date2 = day "-" month "-" 2DIGIT 1615 ; day-month-year (e.g., 02-Jun-82) 1617 day-name-l = %x4D.6F.6E.64.61.79 ; "Monday", case-sensitive 1618 / %x54.75.65.73.64.61.79 ; "Tuesday", case-sensitive 1619 / %x57.65.64.6E.65.73.64.61.79 ; "Wednesday", case-sensitive 1620 / %x54.68.75.72.73.64.61.79 ; "Thursday", case-sensitive 1621 / %x46.72.69.64.61.79 ; "Friday", case-sensitive 1622 / %x53.61.74.75.72.64.61.79 ; "Saturday", case-sensitive 1623 / %x53.75.6E.64.61.79 ; "Sunday", case-sensitive 1625 asctime-date = day-name SP date3 SP time-of-day SP year 1626 date3 = month SP ( 2DIGIT / ( SP 1DIGIT )) 1627 ; month day (e.g., Jun 2) 1629 Note: Recipients of date values are encouraged to be robust in 1630 accepting date values that might have been sent by non-HTTP 1631 applications, as is sometimes the case when retrieving or posting 1632 messages via proxies/gateways to SMTP or NNTP. 1634 Note: HTTP requirements for the date/time stamp format apply only 1635 to their usage within the protocol stream. Clients and servers 1636 are not required to use these formats for user presentation, 1637 request logging, etc. 1639 6.2. Transfer Codings 1641 Transfer-coding values are used to indicate an encoding 1642 transformation that has been, can be, or might need to be applied to 1643 a payload body in order to ensure "safe transport" through the 1644 network. This differs from a content coding in that the transfer- 1645 coding is a property of the message rather than a property of the 1646 representation that is being transferred. 1648 transfer-coding = "chunked" ; Section 6.2.1 1649 / "compress" ; Section 6.2.2.1 1650 / "deflate" ; Section 6.2.2.2 1651 / "gzip" ; Section 6.2.2.3 1652 / transfer-extension 1653 transfer-extension = token *( OWS ";" OWS transfer-parameter ) 1655 Parameters are in the form of attribute/value pairs. 1657 transfer-parameter = attribute BWS "=" BWS value 1658 attribute = token 1659 value = word 1661 All transfer-coding values are case-insensitive. HTTP/1.1 uses 1662 transfer-coding values in the TE header field (Section 9.5) and in 1663 the Transfer-Encoding header field (Section 9.7). 1665 Transfer-codings are analogous to the Content-Transfer-Encoding 1666 values of MIME, which were designed to enable safe transport of 1667 binary data over a 7-bit transport service ([RFC2045], Section 6). 1668 However, safe transport has a different focus for an 8bit-clean 1669 transfer protocol. In HTTP, the only unsafe characteristic of 1670 message-bodies is the difficulty in determining the exact message 1671 body length (Section 3.3), or the desire to encrypt data over a 1672 shared transport. 1674 A server that receives a request message with a transfer-coding it 1675 does not understand SHOULD respond with 501 (Not Implemented) and 1676 then close the connection. A server MUST NOT send transfer-codings 1677 to an HTTP/1.0 client. 1679 6.2.1. Chunked Transfer Coding 1681 The chunked encoding modifies the body of a message in order to 1682 transfer it as a series of chunks, each with its own size indicator, 1683 followed by an OPTIONAL trailer containing header fields. This 1684 allows dynamically produced content to be transferred along with the 1685 information necessary for the recipient to verify that it has 1686 received the full message. 1688 Chunked-Body = *chunk 1689 last-chunk 1690 trailer-part 1691 CRLF 1693 chunk = chunk-size *WSP [ chunk-ext ] CRLF 1694 chunk-data CRLF 1695 chunk-size = 1*HEXDIG 1696 last-chunk = 1*("0") *WSP [ chunk-ext ] CRLF 1698 chunk-ext = *( ";" *WSP chunk-ext-name 1699 [ "=" chunk-ext-val ] *WSP ) 1700 chunk-ext-name = token 1701 chunk-ext-val = token / quoted-str-nf 1702 chunk-data = 1*OCTET ; a sequence of chunk-size octets 1703 trailer-part = *( header-field CRLF ) 1705 quoted-str-nf = DQUOTE *( qdtext-nf / quoted-pair ) DQUOTE 1706 ; like quoted-string, but disallowing line folding 1707 qdtext-nf = WSP / %x21 / %x23-5B / %x5D-7E / obs-text 1708 ; WSP / / obs-text 1710 The chunk-size field is a string of hex digits indicating the size of 1711 the chunk-data in octets. The chunked encoding is ended by any chunk 1712 whose size is zero, followed by the trailer, which is terminated by 1713 an empty line. 1715 The trailer allows the sender to include additional HTTP header 1716 fields at the end of the message. The Trailer header field can be 1717 used to indicate which header fields are included in a trailer (see 1718 Section 9.6). 1720 A server using chunked transfer-coding in a response MUST NOT use the 1721 trailer for any header fields unless at least one of the following is 1722 true: 1724 1. the request included a TE header field that indicates "trailers" 1725 is acceptable in the transfer-coding of the response, as 1726 described in Section 9.5; or, 1728 2. the trailer fields consist entirely of optional metadata, and the 1729 recipient could use the message (in a manner acceptable to the 1730 server where the field originated) without receiving it. In 1731 other words, the server that generated the header (often but not 1732 always the origin server) is willing to accept the possibility 1733 that the trailer fields might be silently discarded along the 1734 path to the client. 1736 This requirement prevents an interoperability failure when the 1737 message is being received by an HTTP/1.1 (or later) proxy and 1738 forwarded to an HTTP/1.0 recipient. It avoids a situation where 1739 compliance with the protocol would have necessitated a possibly 1740 infinite buffer on the proxy. 1742 A process for decoding the "chunked" transfer-coding can be 1743 represented in pseudo-code as: 1745 length := 0 1746 read chunk-size, chunk-ext (if any) and CRLF 1747 while (chunk-size > 0) { 1748 read chunk-data and CRLF 1749 append chunk-data to decoded-body 1750 length := length + chunk-size 1751 read chunk-size and CRLF 1752 } 1753 read header-field 1754 while (header-field not empty) { 1755 append header-field to existing header fields 1756 read header-field 1757 } 1758 Content-Length := length 1759 Remove "chunked" from Transfer-Encoding 1761 All HTTP/1.1 applications MUST be able to receive and decode the 1762 "chunked" transfer-coding and MUST ignore chunk-ext extensions they 1763 do not understand. 1765 Since "chunked" is the only transfer-coding required to be understood 1766 by HTTP/1.1 recipients, it plays a crucial role in delimiting 1767 messages on a persistent connection. Whenever a transfer-coding is 1768 applied to a payload body in a request, the final transfer-coding 1769 applied MUST be "chunked". If a transfer-coding is applied to a 1770 response payload body, then either the final transfer-coding applied 1771 MUST be "chunked" or the message MUST be terminated by closing the 1772 connection. When the "chunked" transfer-coding is used, it MUST be 1773 the last transfer-coding applied to form the message-body. The 1774 "chunked" transfer-coding MUST NOT be applied more than once in a 1775 message-body. 1777 6.2.2. Compression Codings 1779 The codings defined below can be used to compress the payload of a 1780 message. 1782 Note: Use of program names for the identification of encoding 1783 formats is not desirable and is discouraged for future encodings. 1784 Their use here is representative of historical practice, not good 1785 design. 1787 Note: For compatibility with previous implementations of HTTP, 1788 applications SHOULD consider "x-gzip" and "x-compress" to be 1789 equivalent to "gzip" and "compress" respectively. 1791 6.2.2.1. Compress Coding 1793 The "compress" format is produced by the common UNIX file compression 1794 program "compress". This format is an adaptive Lempel-Ziv-Welch 1795 coding (LZW). 1797 6.2.2.2. Deflate Coding 1799 The "deflate" format is defined as the "deflate" compression 1800 mechanism (described in [RFC1951]) used inside the "zlib" data format 1801 ([RFC1950]). 1803 Note: Some incorrect implementations send the "deflate" compressed 1804 data without the zlib wrapper. 1806 6.2.2.3. Gzip Coding 1808 The "gzip" format is produced by the file compression program "gzip" 1809 (GNU zip), as described in [RFC1952]. This format is a Lempel-Ziv 1810 coding (LZ77) with a 32 bit CRC. 1812 6.2.3. Transfer Coding Registry 1814 The HTTP Transfer Coding Registry defines the name space for the 1815 transfer coding names. 1817 Registrations MUST include the following fields: 1819 o Name 1821 o Description 1823 o Pointer to specification text 1825 Names of transfer codings MUST NOT overlap with names of content 1826 codings (Section 2.2 of [Part3]), unless the encoding transformation 1827 is identical (as it is the case for the compression codings defined 1828 in Section 6.2.2). 1830 Values to be added to this name space require a specification (see 1831 "Specification Required" in Section 4.1 of [RFC5226]), and MUST 1832 conform to the purpose of transfer coding defined in this section. 1834 The registry itself is maintained at 1835 . 1837 6.3. Product Tokens 1839 Product tokens are used to allow communicating applications to 1840 identify themselves by software name and version. Most fields using 1841 product tokens also allow sub-products which form a significant part 1842 of the application to be listed, separated by whitespace. By 1843 convention, the products are listed in order of their significance 1844 for identifying the application. 1846 product = token ["/" product-version] 1847 product-version = token 1849 Examples: 1851 User-Agent: CERN-LineMode/2.15 libwww/2.17b3 1852 Server: Apache/0.8.4 1854 Product tokens SHOULD be short and to the point. They MUST NOT be 1855 used for advertising or other non-essential information. Although 1856 any token octet MAY appear in a product-version, this token SHOULD 1857 only be used for a version identifier (i.e., successive versions of 1858 the same product SHOULD only differ in the product-version portion of 1859 the product value). 1861 6.4. Quality Values 1863 Both transfer codings (TE request header field, Section 9.5) and 1864 content negotiation (Section 5 of [Part3]) use short "floating point" 1865 numbers to indicate the relative importance ("weight") of various 1866 negotiable parameters. A weight is normalized to a real number in 1867 the range 0 through 1, where 0 is the minimum and 1 the maximum 1868 value. If a parameter has a quality value of 0, then content with 1869 this parameter is "not acceptable" for the client. HTTP/1.1 1870 applications MUST NOT generate more than three digits after the 1871 decimal point. User configuration of these values SHOULD also be 1872 limited in this fashion. 1874 qvalue = ( "0" [ "." 0*3DIGIT ] ) 1875 / ( "1" [ "." 0*3("0") ] ) 1877 Note: "Quality values" is a misnomer, since these values merely 1878 represent relative degradation in desired quality. 1880 7. Connections 1881 7.1. Persistent Connections 1883 7.1.1. Purpose 1885 Prior to persistent connections, a separate TCP connection was 1886 established for each request, increasing the load on HTTP servers and 1887 causing congestion on the Internet. The use of inline images and 1888 other associated data often requires a client to make multiple 1889 requests of the same server in a short amount of time. Analysis of 1890 these performance problems and results from a prototype 1891 implementation are available [Pad1995] [Spe]. Implementation 1892 experience and measurements of actual HTTP/1.1 implementations show 1893 good results [Nie1997]. Alternatives have also been explored, for 1894 example, T/TCP [Tou1998]. 1896 Persistent HTTP connections have a number of advantages: 1898 o By opening and closing fewer TCP connections, CPU time is saved in 1899 routers and hosts (clients, servers, proxies, gateways, tunnels, 1900 or caches), and memory used for TCP protocol control blocks can be 1901 saved in hosts. 1903 o HTTP requests and responses can be pipelined on a connection. 1904 Pipelining allows a client to make multiple requests without 1905 waiting for each response, allowing a single TCP connection to be 1906 used much more efficiently, with much lower elapsed time. 1908 o Network congestion is reduced by reducing the number of packets 1909 caused by TCP opens, and by allowing TCP sufficient time to 1910 determine the congestion state of the network. 1912 o Latency on subsequent requests is reduced since there is no time 1913 spent in TCP's connection opening handshake. 1915 o HTTP can evolve more gracefully, since errors can be reported 1916 without the penalty of closing the TCP connection. Clients using 1917 future versions of HTTP might optimistically try a new feature, 1918 but if communicating with an older server, retry with old 1919 semantics after an error is reported. 1921 HTTP implementations SHOULD implement persistent connections. 1923 7.1.2. Overall Operation 1925 A significant difference between HTTP/1.1 and earlier versions of 1926 HTTP is that persistent connections are the default behavior of any 1927 HTTP connection. That is, unless otherwise indicated, the client 1928 SHOULD assume that the server will maintain a persistent connection, 1929 even after error responses from the server. 1931 Persistent connections provide a mechanism by which a client and a 1932 server can signal the close of a TCP connection. This signaling 1933 takes place using the Connection header field (Section 9.1). Once a 1934 close has been signaled, the client MUST NOT send any more requests 1935 on that connection. 1937 7.1.2.1. Negotiation 1939 An HTTP/1.1 server MAY assume that a HTTP/1.1 client intends to 1940 maintain a persistent connection unless a Connection header field 1941 including the connection-token "close" was sent in the request. If 1942 the server chooses to close the connection immediately after sending 1943 the response, it SHOULD send a Connection header field including the 1944 connection-token "close". 1946 An HTTP/1.1 client MAY expect a connection to remain open, but would 1947 decide to keep it open based on whether the response from a server 1948 contains a Connection header field with the connection-token close. 1949 In case the client does not want to maintain a connection for more 1950 than that request, it SHOULD send a Connection header field including 1951 the connection-token close. 1953 If either the client or the server sends the close token in the 1954 Connection header field, that request becomes the last one for the 1955 connection. 1957 Clients and servers SHOULD NOT assume that a persistent connection is 1958 maintained for HTTP versions less than 1.1 unless it is explicitly 1959 signaled. See Appendix B.1.2 for more information on backward 1960 compatibility with HTTP/1.0 clients. 1962 In order to remain persistent, all messages on the connection MUST 1963 have a self-defined message length (i.e., one not defined by closure 1964 of the connection), as described in Section 3.3. 1966 7.1.2.2. Pipelining 1968 A client that supports persistent connections MAY "pipeline" its 1969 requests (i.e., send multiple requests without waiting for each 1970 response). A server MUST send its responses to those requests in the 1971 same order that the requests were received. 1973 Clients which assume persistent connections and pipeline immediately 1974 after connection establishment SHOULD be prepared to retry their 1975 connection if the first pipelined attempt fails. If a client does 1976 such a retry, it MUST NOT pipeline before it knows the connection is 1977 persistent. Clients MUST also be prepared to resend their requests 1978 if the server closes the connection before sending all of the 1979 corresponding responses. 1981 Clients SHOULD NOT pipeline requests using non-idempotent request 1982 methods or non-idempotent sequences of request methods (see Section 1983 7.1.2 of [Part2]). Otherwise, a premature termination of the 1984 transport connection could lead to indeterminate results. A client 1985 wishing to send a non-idempotent request SHOULD wait to send that 1986 request until it has received the response status line for the 1987 previous request. 1989 7.1.3. Proxy Servers 1991 It is especially important that proxies correctly implement the 1992 properties of the Connection header field as specified in 1993 Section 9.1. 1995 The proxy server MUST signal persistent connections separately with 1996 its clients and the origin servers (or other proxy servers) that it 1997 connects to. Each persistent connection applies to only one 1998 transport link. 2000 A proxy server MUST NOT establish a HTTP/1.1 persistent connection 2001 with an HTTP/1.0 client (but see Section 19.7.1 of [RFC2068] for 2002 information and discussion of the problems with the Keep-Alive header 2003 field implemented by many HTTP/1.0 clients). 2005 7.1.3.1. End-to-end and Hop-by-hop Header Fields 2007 For the purpose of defining the behavior of caches and non-caching 2008 proxies, we divide HTTP header fields into two categories: 2010 o End-to-end header fields, which are transmitted to the ultimate 2011 recipient of a request or response. End-to-end header fields in 2012 responses MUST be stored as part of a cache entry and MUST be 2013 transmitted in any response formed from a cache entry. 2015 o Hop-by-hop header fields, which are meaningful only for a single 2016 transport-level connection, and are not stored by caches or 2017 forwarded by proxies. 2019 The following HTTP/1.1 header fields are hop-by-hop header fields: 2021 o Connection 2023 o Keep-Alive 2024 o Proxy-Authenticate 2026 o Proxy-Authorization 2028 o TE 2030 o Trailer 2032 o Transfer-Encoding 2034 o Upgrade 2036 All other header fields defined by HTTP/1.1 are end-to-end header 2037 fields. 2039 Other hop-by-hop header fields MUST be listed in a Connection header 2040 field (Section 9.1). 2042 7.1.3.2. Non-modifiable Header Fields 2044 Some features of HTTP/1.1, such as Digest Authentication, depend on 2045 the value of certain end-to-end header fields. A non-transforming 2046 proxy SHOULD NOT modify an end-to-end header field unless the 2047 definition of that header field requires or specifically allows that. 2049 A non-transforming proxy MUST NOT modify any of the following fields 2050 in a request or response, and it MUST NOT add any of these fields if 2051 not already present: 2053 o Content-Location 2055 o Content-MD5 2057 o ETag 2059 o Last-Modified 2061 A non-transforming proxy MUST NOT modify any of the following fields 2062 in a response: 2064 o Expires 2066 but it MAY add any of these fields if not already present. If an 2067 Expires header field is added, it MUST be given a field-value 2068 identical to that of the Date header field in that response. 2070 A proxy MUST NOT modify or add any of the following fields in a 2071 message that contains the no-transform cache-control directive, or in 2072 any request: 2074 o Content-Encoding 2076 o Content-Range 2078 o Content-Type 2080 A transforming proxy MAY modify or add these fields to a message that 2081 does not include no-transform, but if it does so, it MUST add a 2082 Warning 214 (Transformation applied) if one does not already appear 2083 in the message (see Section 3.6 of [Part6]). 2085 Warning: Unnecessary modification of end-to-end header fields 2086 might cause authentication failures if stronger authentication 2087 mechanisms are introduced in later versions of HTTP. Such 2088 authentication mechanisms MAY rely on the values of header fields 2089 not listed here. 2091 A non-transforming proxy MUST preserve the message payload ([Part3]), 2092 though it MAY change the message-body through application or removal 2093 of a transfer-coding (Section 6.2). 2095 7.1.4. Practical Considerations 2097 Servers will usually have some time-out value beyond which they will 2098 no longer maintain an inactive connection. Proxy servers might make 2099 this a higher value since it is likely that the client will be making 2100 more connections through the same server. The use of persistent 2101 connections places no requirements on the length (or existence) of 2102 this time-out for either the client or the server. 2104 When a client or server wishes to time-out it SHOULD issue a graceful 2105 close on the transport connection. Clients and servers SHOULD both 2106 constantly watch for the other side of the transport close, and 2107 respond to it as appropriate. If a client or server does not detect 2108 the other side's close promptly it could cause unnecessary resource 2109 drain on the network. 2111 A client, server, or proxy MAY close the transport connection at any 2112 time. For example, a client might have started to send a new request 2113 at the same time that the server has decided to close the "idle" 2114 connection. From the server's point of view, the connection is being 2115 closed while it was idle, but from the client's point of view, a 2116 request is in progress. 2118 This means that clients, servers, and proxies MUST be able to recover 2119 from asynchronous close events. Client software SHOULD reopen the 2120 transport connection and retransmit the aborted sequence of requests 2121 without user interaction so long as the request sequence is 2122 idempotent (see Section 7.1.2 of [Part2]). Non-idempotent request 2123 methods or sequences MUST NOT be automatically retried, although user 2124 agents MAY offer a human operator the choice of retrying the 2125 request(s). Confirmation by user-agent software with semantic 2126 understanding of the application MAY substitute for user 2127 confirmation. The automatic retry SHOULD NOT be repeated if the 2128 second sequence of requests fails. 2130 Servers SHOULD always respond to at least one request per connection, 2131 if at all possible. Servers SHOULD NOT close a connection in the 2132 middle of transmitting a response, unless a network or client failure 2133 is suspected. 2135 Clients (including proxies) SHOULD limit the number of simultaneous 2136 connections that they maintain to a given server (including proxies). 2138 Previous revisions of HTTP gave a specific number of connections as a 2139 ceiling, but this was found to be impractical for many applications. 2140 As a result, this specification does not mandate a particular maximum 2141 number of connections, but instead encourages clients to be 2142 conservative when opening multiple connections. 2144 In particular, while using multiple connections avoids the "head-of- 2145 line blocking" problem (whereby a request that takes significant 2146 server-side processing and/or has a large payload can block 2147 subsequent requests on the same connection), each connection used 2148 consumes server resources (sometimes significantly), and furthermore 2149 using multiple connections can cause undesirable side effects in 2150 congested networks. 2152 Note that servers might reject traffic that they deem abusive, 2153 including an excessive number of connections from a client. 2155 7.2. Message Transmission Requirements 2157 7.2.1. Persistent Connections and Flow Control 2159 HTTP/1.1 servers SHOULD maintain persistent connections and use TCP's 2160 flow control mechanisms to resolve temporary overloads, rather than 2161 terminating connections with the expectation that clients will retry. 2162 The latter technique can exacerbate network congestion. 2164 7.2.2. Monitoring Connections for Error Status Messages 2166 An HTTP/1.1 (or later) client sending a message-body SHOULD monitor 2167 the network connection for an error status code while it is 2168 transmitting the request. If the client sees an error status code, 2169 it SHOULD immediately cease transmitting the body. If the body is 2170 being sent using a "chunked" encoding (Section 6.2), a zero length 2171 chunk and empty trailer MAY be used to prematurely mark the end of 2172 the message. If the body was preceded by a Content-Length header 2173 field, the client MUST close the connection. 2175 7.2.3. Use of the 100 (Continue) Status 2177 The purpose of the 100 (Continue) status code (see Section 8.1.1 of 2178 [Part2]) is to allow a client that is sending a request message with 2179 a request body to determine if the origin server is willing to accept 2180 the request (based on the request header fields) before the client 2181 sends the request body. In some cases, it might either be 2182 inappropriate or highly inefficient for the client to send the body 2183 if the server will reject the message without looking at the body. 2185 Requirements for HTTP/1.1 clients: 2187 o If a client will wait for a 100 (Continue) response before sending 2188 the request body, it MUST send an Expect header field (Section 9.2 2189 of [Part2]) with the "100-continue" expectation. 2191 o A client MUST NOT send an Expect header field (Section 9.2 of 2192 [Part2]) with the "100-continue" expectation if it does not intend 2193 to send a request body. 2195 Because of the presence of older implementations, the protocol allows 2196 ambiguous situations in which a client might send "Expect: 100- 2197 continue" without receiving either a 417 (Expectation Failed) or a 2198 100 (Continue) status code. Therefore, when a client sends this 2199 header field to an origin server (possibly via a proxy) from which it 2200 has never seen a 100 (Continue) status code, the client SHOULD NOT 2201 wait for an indefinite period before sending the request body. 2203 Requirements for HTTP/1.1 origin servers: 2205 o Upon receiving a request which includes an Expect header field 2206 with the "100-continue" expectation, an origin server MUST either 2207 respond with 100 (Continue) status code and continue to read from 2208 the input stream, or respond with a final status code. The origin 2209 server MUST NOT wait for the request body before sending the 100 2210 (Continue) response. If it responds with a final status code, it 2211 MAY close the transport connection or it MAY continue to read and 2212 discard the rest of the request. It MUST NOT perform the request 2213 method if it returns a final status code. 2215 o An origin server SHOULD NOT send a 100 (Continue) response if the 2216 request message does not include an Expect header field with the 2217 "100-continue" expectation, and MUST NOT send a 100 (Continue) 2218 response if such a request comes from an HTTP/1.0 (or earlier) 2219 client. There is an exception to this rule: for compatibility 2220 with [RFC2068], a server MAY send a 100 (Continue) status code in 2221 response to an HTTP/1.1 PUT or POST request that does not include 2222 an Expect header field with the "100-continue" expectation. This 2223 exception, the purpose of which is to minimize any client 2224 processing delays associated with an undeclared wait for 100 2225 (Continue) status code, applies only to HTTP/1.1 requests, and not 2226 to requests with any other HTTP-version value. 2228 o An origin server MAY omit a 100 (Continue) response if it has 2229 already received some or all of the request body for the 2230 corresponding request. 2232 o An origin server that sends a 100 (Continue) response MUST 2233 ultimately send a final status code, once the request body is 2234 received and processed, unless it terminates the transport 2235 connection prematurely. 2237 o If an origin server receives a request that does not include an 2238 Expect header field with the "100-continue" expectation, the 2239 request includes a request body, and the server responds with a 2240 final status code before reading the entire request body from the 2241 transport connection, then the server SHOULD NOT close the 2242 transport connection until it has read the entire request, or 2243 until the client closes the connection. Otherwise, the client 2244 might not reliably receive the response message. However, this 2245 requirement is not be construed as preventing a server from 2246 defending itself against denial-of-service attacks, or from badly 2247 broken client implementations. 2249 Requirements for HTTP/1.1 proxies: 2251 o If a proxy receives a request that includes an Expect header field 2252 with the "100-continue" expectation, and the proxy either knows 2253 that the next-hop server complies with HTTP/1.1 or higher, or does 2254 not know the HTTP version of the next-hop server, it MUST forward 2255 the request, including the Expect header field. 2257 o If the proxy knows that the version of the next-hop server is 2258 HTTP/1.0 or lower, it MUST NOT forward the request, and it MUST 2259 respond with a 417 (Expectation Failed) status code. 2261 o Proxies SHOULD maintain a cache recording the HTTP version numbers 2262 received from recently-referenced next-hop servers. 2264 o A proxy MUST NOT forward a 100 (Continue) response if the request 2265 message was received from an HTTP/1.0 (or earlier) client and did 2266 not include an Expect header field with the "100-continue" 2267 expectation. This requirement overrides the general rule for 2268 forwarding of 1xx responses (see Section 8.1 of [Part2]). 2270 7.2.4. Client Behavior if Server Prematurely Closes Connection 2272 If an HTTP/1.1 client sends a request which includes a request body, 2273 but which does not include an Expect header field with the "100- 2274 continue" expectation, and if the client is not directly connected to 2275 an HTTP/1.1 origin server, and if the client sees the connection 2276 close before receiving a status line from the server, the client 2277 SHOULD retry the request. If the client does retry this request, it 2278 MAY use the following "binary exponential backoff" algorithm to be 2279 assured of obtaining a reliable response: 2281 1. Initiate a new connection to the server 2283 2. Transmit the request-line, header fields, and the CRLF that 2284 indicates the end of header fields. 2286 3. Initialize a variable R to the estimated round-trip time to the 2287 server (e.g., based on the time it took to establish the 2288 connection), or to a constant value of 5 seconds if the round- 2289 trip time is not available. 2291 4. Compute T = R * (2**N), where N is the number of previous retries 2292 of this request. 2294 5. Wait either for an error response from the server, or for T 2295 seconds (whichever comes first) 2297 6. If no error response is received, after T seconds transmit the 2298 body of the request. 2300 7. If client sees that the connection is closed prematurely, repeat 2301 from step 1 until the request is accepted, an error response is 2302 received, or the user becomes impatient and terminates the retry 2303 process. 2305 If at any point an error status code is received, the client 2307 o SHOULD NOT continue and 2309 o SHOULD close the connection if it has not completed sending the 2310 request message. 2312 8. Miscellaneous notes that might disappear 2314 8.1. Scheme aliases considered harmful 2316 [[TBD-aliases-harmful: describe why aliases like webcal are 2317 harmful.]] 2319 8.2. Use of HTTP for proxy communication 2321 [[TBD-proxy-other: Configured to use HTTP to proxy HTTP or other 2322 protocols.]] 2324 8.3. Interception of HTTP for access control 2326 [[TBD-intercept: Interception of HTTP traffic for initiating access 2327 control.]] 2329 8.4. Use of HTTP by other protocols 2331 [[TBD-profiles: Profiles of HTTP defined by other protocol. 2332 Extensions of HTTP like WebDAV.]] 2334 8.5. Use of HTTP by media type specification 2336 [[TBD-hypertext: Instructions on composing HTTP requests via 2337 hypertext formats.]] 2339 9. Header Field Definitions 2341 This section defines the syntax and semantics of HTTP header fields 2342 related to message framing and transport protocols. 2344 9.1. Connection 2346 The "Connection" header field allows the sender to specify options 2347 that are desired only for that particular connection. Such 2348 connection options MUST be removed or replaced before the message can 2349 be forwarded downstream by a proxy or gateway. This mechanism also 2350 allows the sender to indicate which HTTP header fields used in the 2351 message are only intended for the immediate recipient ("hop-by-hop"), 2352 as opposed to all recipients on the chain ("end-to-end"), enabling 2353 the message to be self-descriptive and allowing future connection- 2354 specific extensions to be deployed in HTTP without fear that they 2355 will be blindly forwarded by previously deployed intermediaries. 2357 The Connection header field's value has the following grammar: 2359 Connection = "Connection" ":" OWS Connection-v 2360 Connection-v = 1#connection-token 2361 connection-token = token 2363 A proxy or gateway MUST parse a received Connection header field 2364 before a message is forwarded and, for each connection-token in this 2365 field, remove any header field(s) from the message with the same name 2366 as the connection-token, and then remove the Connection header field 2367 itself or replace it with the sender's own connection options for the 2368 forwarded message. 2370 A sender MUST NOT include field-names in the Connection header field- 2371 value for fields that are defined as expressing constraints for all 2372 recipients in the request or response chain, such as the Cache- 2373 Control header field (Section 3.2 of [Part6]). 2375 The connection options do not have to correspond to a header field 2376 present in the message, since a connection-specific header field 2377 might not be needed if there are no parameters associated with that 2378 connection option. Recipients that trigger certain connection 2379 behavior based on the presence of connection options MUST do so based 2380 on the presence of the connection-token rather than only the presence 2381 of the optional header field. In other words, if the connection 2382 option is received as a header field but not indicated within the 2383 Connection field-value, then the recipient MUST ignore the 2384 connection-specific header field because it has likely been forwarded 2385 by an intermediary that is only partially compliant. 2387 When defining new connection options, specifications ought to 2388 carefully consider existing deployed header fields and ensure that 2389 the new connection-token does not share the same name as an unrelated 2390 header field that might already be deployed. Defining a new 2391 connection-token essentially reserves that potential field-name for 2392 carrying additional information related to the connection option, 2393 since it would be unwise for senders to use that field-name for 2394 anything else. 2396 HTTP/1.1 defines the "close" connection option for the sender to 2397 signal that the connection will be closed after completion of the 2398 response. For example, 2400 Connection: close 2402 in either the request or the response header fields indicates that 2403 the connection SHOULD NOT be considered "persistent" (Section 7.1) 2404 after the current request/response is complete. 2406 An HTTP/1.1 client that does not support persistent connections MUST 2407 include the "close" connection option in every request message. 2409 An HTTP/1.1 server that does not support persistent connections MUST 2410 include the "close" connection option in every response message that 2411 does not have a 1xx (Informational) status code. 2413 9.2. Content-Length 2415 The "Content-Length" header field indicates the size of the message- 2416 body, in decimal number of octets, for any message other than a 2417 response to a HEAD request or a response with a status code of 304. 2418 In the case of a response to a HEAD request, Content-Length indicates 2419 the size of the payload body (not including any potential transfer- 2420 coding) that would have been sent had the request been a GET. In the 2421 case of a 304 (Not Modified) response to a GET request, Content- 2422 Length indicates the size of the payload body (not including any 2423 potential transfer-coding) that would have been sent in a 200 (OK) 2424 response. 2426 Content-Length = "Content-Length" ":" OWS 1*Content-Length-v 2427 Content-Length-v = 1*DIGIT 2429 An example is 2431 Content-Length: 3495 2433 Implementations SHOULD use this field to indicate the message-body 2434 length when no transfer-coding is being applied and the payload's 2435 body length can be determined prior to being transferred. 2436 Section 3.3 describes how recipients determine the length of a 2437 message-body. 2439 Any Content-Length greater than or equal to zero is a valid value. 2441 Note that the use of this field in HTTP is significantly different 2442 from the corresponding definition in MIME, where it is an optional 2443 field used within the "message/external-body" content-type. 2445 9.3. Date 2447 The "Date" header field represents the date and time at which the 2448 message was originated, having the same semantics as the Origination 2449 Date Field (orig-date) defined in Section 3.6.1 of [RFC5322]. The 2450 field value is an HTTP-date, as described in Section 6.1; it MUST be 2451 sent in rfc1123-date format. 2453 Date = "Date" ":" OWS Date-v 2454 Date-v = HTTP-date 2456 An example is 2458 Date: Tue, 15 Nov 1994 08:12:31 GMT 2460 Origin servers MUST include a Date header field in all responses, 2461 except in these cases: 2463 1. If the response status code is 100 (Continue) or 101 (Switching 2464 Protocols), the response MAY include a Date header field, at the 2465 server's option. 2467 2. If the response status code conveys a server error, e.g., 500 2468 (Internal Server Error) or 503 (Service Unavailable), and it is 2469 inconvenient or impossible to generate a valid Date. 2471 3. If the server does not have a clock that can provide a reasonable 2472 approximation of the current time, its responses MUST NOT include 2473 a Date header field. In this case, the rules in Section 9.3.1 2474 MUST be followed. 2476 A received message that does not have a Date header field MUST be 2477 assigned one by the recipient if the message will be cached by that 2478 recipient. 2480 Clients can use the Date header field as well; in order to keep 2481 request messages small, they are advised not to include it when it 2482 doesn't convey any useful information (as it is usually the case for 2483 requests that do not contain a payload). 2485 The HTTP-date sent in a Date header field SHOULD NOT represent a date 2486 and time subsequent to the generation of the message. It SHOULD 2487 represent the best available approximation of the date and time of 2488 message generation, unless the implementation has no means of 2489 generating a reasonably accurate date and time. In theory, the date 2490 ought to represent the moment just before the payload is generated. 2491 In practice, the date can be generated at any time during the message 2492 origination without affecting its semantic value. 2494 9.3.1. Clockless Origin Server Operation 2496 Some origin server implementations might not have a clock available. 2497 An origin server without a clock MUST NOT assign Expires or Last- 2498 Modified values to a response, unless these values were associated 2499 with the resource by a system or user with a reliable clock. It MAY 2500 assign an Expires value that is known, at or before server 2501 configuration time, to be in the past (this allows "pre-expiration" 2502 of responses without storing separate Expires values for each 2503 resource). 2505 9.4. Host 2507 The "Host" header field in a request provides the host and port 2508 information from the target resource's URI, enabling the origin 2509 server to distinguish between resources while servicing requests for 2510 multiple host names on a single IP address. Since the Host field- 2511 value is critical information for handling a request, it SHOULD be 2512 sent as the first header field following the Request-Line. 2514 Host = "Host" ":" OWS Host-v 2515 Host-v = uri-host [ ":" port ] ; Section 2.6.1 2517 A client MUST send a Host header field in all HTTP/1.1 request 2518 messages. If the target resource's URI includes an authority 2519 component, then the Host field-value MUST be identical to that 2520 authority component after excluding any userinfo (Section 2.6.1). If 2521 the authority component is missing or undefined for the target 2522 resource's URI, then the Host header field MUST be sent with an empty 2523 field-value. 2525 For example, a GET request to the origin server for 2526 would begin with: 2528 GET /pub/WWW/ HTTP/1.1 2529 Host: www.example.org 2531 The Host header field MUST be sent in an HTTP/1.1 request even if the 2532 request-target is in the form of an absolute-URI, since this allows 2533 the Host information to be forwarded through ancient HTTP/1.0 proxies 2534 that might not have implemented Host. 2536 When an HTTP/1.1 proxy receives a request with a request-target in 2537 the form of an absolute-URI, the proxy MUST ignore the received Host 2538 header field (if any) and instead replace it with the host 2539 information of the request-target. When a proxy forwards a request, 2540 it MUST generate the Host header field based on the received 2541 absolute-URI rather than the received Host. 2543 Since the Host header field acts as an application-level routing 2544 mechanism, it is a frequent target for malware seeking to poison a 2545 shared cache or redirect a request to an unintended server. An 2546 interception proxy is particularly vulnerable if it relies on the 2547 Host header field value for redirecting requests to internal servers, 2548 or for use as a cache key in a shared cache, without first verifying 2549 that the intercepted connection is targeting a valid IP address for 2550 that host. 2552 A server MUST respond with a 400 (Bad Request) status code to any 2553 HTTP/1.1 request message that lacks a Host header field and to any 2554 request message that contains more than one Host header field or a 2555 Host header field with an invalid field-value. 2557 See Sections 4.2 and B.1.1 for other requirements relating to Host. 2559 9.5. TE 2561 The "TE" header field indicates what extension transfer-codings it is 2562 willing to accept in the response, and whether or not it is willing 2563 to accept trailer fields in a chunked transfer-coding. 2565 Its value consists of the keyword "trailers" and/or a comma-separated 2566 list of extension transfer-coding names with optional accept 2567 parameters (as described in Section 6.2). 2569 TE = "TE" ":" OWS TE-v 2570 TE-v = #t-codings 2571 t-codings = "trailers" / ( transfer-extension [ te-params ] ) 2572 te-params = OWS ";" OWS "q=" qvalue *( te-ext ) 2573 te-ext = OWS ";" OWS token [ "=" word ] 2575 The presence of the keyword "trailers" indicates that the client is 2576 willing to accept trailer fields in a chunked transfer-coding, as 2577 defined in Section 6.2.1. This keyword is reserved for use with 2578 transfer-coding values even though it does not itself represent a 2579 transfer-coding. 2581 Examples of its use are: 2583 TE: deflate 2584 TE: 2585 TE: trailers, deflate;q=0.5 2587 The TE header field only applies to the immediate connection. 2588 Therefore, the keyword MUST be supplied within a Connection header 2589 field (Section 9.1) whenever TE is present in an HTTP/1.1 message. 2591 A server tests whether a transfer-coding is acceptable, according to 2592 a TE field, using these rules: 2594 1. The "chunked" transfer-coding is always acceptable. If the 2595 keyword "trailers" is listed, the client indicates that it is 2596 willing to accept trailer fields in the chunked response on 2597 behalf of itself and any downstream clients. The implication is 2598 that, if given, the client is stating that either all downstream 2599 clients are willing to accept trailer fields in the forwarded 2600 response, or that it will attempt to buffer the response on 2601 behalf of downstream recipients. 2603 Note: HTTP/1.1 does not define any means to limit the size of a 2604 chunked response such that a client can be assured of buffering 2605 the entire response. 2607 2. If the transfer-coding being tested is one of the transfer- 2608 codings listed in the TE field, then it is acceptable unless it 2609 is accompanied by a qvalue of 0. (As defined in Section 6.4, a 2610 qvalue of 0 means "not acceptable".) 2612 3. If multiple transfer-codings are acceptable, then the acceptable 2613 transfer-coding with the highest non-zero qvalue is preferred. 2614 The "chunked" transfer-coding always has a qvalue of 1. 2616 If the TE field-value is empty or if no TE field is present, the only 2617 transfer-coding is "chunked". A message with no transfer-coding is 2618 always acceptable. 2620 9.6. Trailer 2622 The "Trailer" header field indicates that the given set of header 2623 fields is present in the trailer of a message encoded with chunked 2624 transfer-coding. 2626 Trailer = "Trailer" ":" OWS Trailer-v 2627 Trailer-v = 1#field-name 2629 An HTTP/1.1 message SHOULD include a Trailer header field in a 2630 message using chunked transfer-coding with a non-empty trailer. 2631 Doing so allows the recipient to know which header fields to expect 2632 in the trailer. 2634 If no Trailer header field is present, the trailer SHOULD NOT include 2635 any header fields. See Section 6.2.1 for restrictions on the use of 2636 trailer fields in a "chunked" transfer-coding. 2638 Message header fields listed in the Trailer header field MUST NOT 2639 include the following header fields: 2641 o Transfer-Encoding 2643 o Content-Length 2645 o Trailer 2647 9.7. Transfer-Encoding 2649 The "Transfer-Encoding" header field indicates what transfer-codings 2650 (if any) have been applied to the message body. It differs from 2651 Content-Encoding (Section 2.2 of [Part3]) in that transfer-codings 2652 are a property of the message (and therefore are removed by 2653 intermediaries), whereas content-codings are not. 2655 Transfer-Encoding = "Transfer-Encoding" ":" OWS 2656 Transfer-Encoding-v 2657 Transfer-Encoding-v = 1#transfer-coding 2659 Transfer-codings are defined in Section 6.2. An example is: 2661 Transfer-Encoding: chunked 2663 If multiple encodings have been applied to a representation, the 2664 transfer-codings MUST be listed in the order in which they were 2665 applied. Additional information about the encoding parameters MAY be 2666 provided by other header fields not defined by this specification. 2668 Many older HTTP/1.0 applications do not understand the Transfer- 2669 Encoding header field. 2671 9.8. Upgrade 2673 The "Upgrade" header field allows the client to specify what 2674 additional communication protocols it would like to use, if the 2675 server chooses to switch protocols. Servers can use it to indicate 2676 what protocols they are willing to switch to. 2678 Upgrade = "Upgrade" ":" OWS Upgrade-v 2679 Upgrade-v = 1#product 2681 For example, 2683 Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11 2685 The Upgrade header field is intended to provide a simple mechanism 2686 for transition from HTTP/1.1 to some other, incompatible protocol. 2687 It does so by allowing the client to advertise its desire to use 2688 another protocol, such as a later version of HTTP with a higher major 2689 version number, even though the current request has been made using 2690 HTTP/1.1. This eases the difficult transition between incompatible 2691 protocols by allowing the client to initiate a request in the more 2692 commonly supported protocol while indicating to the server that it 2693 would like to use a "better" protocol if available (where "better" is 2694 determined by the server, possibly according to the nature of the 2695 request method or target resource). 2697 The Upgrade header field only applies to switching application-layer 2698 protocols upon the existing transport-layer connection. Upgrade 2699 cannot be used to insist on a protocol change; its acceptance and use 2700 by the server is optional. The capabilities and nature of the 2701 application-layer communication after the protocol change is entirely 2702 dependent upon the new protocol chosen, although the first action 2703 after changing the protocol MUST be a response to the initial HTTP 2704 request containing the Upgrade header field. 2706 The Upgrade header field only applies to the immediate connection. 2707 Therefore, the upgrade keyword MUST be supplied within a Connection 2708 header field (Section 9.1) whenever Upgrade is present in an HTTP/1.1 2709 message. 2711 The Upgrade header field cannot be used to indicate a switch to a 2712 protocol on a different connection. For that purpose, it is more 2713 appropriate to use a 3xx redirection response (Section 8.3 of 2714 [Part2]). 2716 Servers MUST include the "Upgrade" header field in 101 (Switching 2717 Protocols) responses to indicate which protocol(s) are being switched 2718 to, and MUST include it in 426 (Upgrade Required) responses to 2719 indicate acceptable protocols to upgrade to. Servers MAY include it 2720 in any other response to indicate that they are willing to upgrade to 2721 one of the specified protocols. 2723 This specification only defines the protocol name "HTTP" for use by 2724 the family of Hypertext Transfer Protocols, as defined by the HTTP 2725 version rules of Section 2.5 and future updates to this 2726 specification. Additional tokens can be registered with IANA using 2727 the registration procedure defined below. 2729 9.8.1. Upgrade Token Registry 2731 The HTTP Upgrade Token Registry defines the name space for product 2732 tokens used to identify protocols in the Upgrade header field. Each 2733 registered token is associated with contact information and an 2734 optional set of specifications that details how the connection will 2735 be processed after it has been upgraded. 2737 Registrations are allowed on a First Come First Served basis as 2738 described in Section 4.1 of [RFC5226]. The specifications need not 2739 be IETF documents or be subject to IESG review. Registrations are 2740 subject to the following rules: 2742 1. A token, once registered, stays registered forever. 2744 2. The registration MUST name a responsible party for the 2745 registration. 2747 3. The registration MUST name a point of contact. 2749 4. The registration MAY name a set of specifications associated with 2750 that token. Such specifications need not be publicly available. 2752 5. The responsible party MAY change the registration at any time. 2753 The IANA will keep a record of all such changes, and make them 2754 available upon request. 2756 6. The responsible party for the first registration of a "product" 2757 token MUST approve later registrations of a "version" token 2758 together with that "product" token before they can be registered. 2760 7. If absolutely required, the IESG MAY reassign the responsibility 2761 for a token. This will normally only be used in the case when a 2762 responsible party cannot be contacted. 2764 9.9. Via 2766 The "Via" header field MUST be sent by a proxy or gateway to indicate 2767 the intermediate protocols and recipients between the user agent and 2768 the server on requests, and between the origin server and the client 2769 on responses. It is analogous to the "Received" field used by email 2770 systems (Section 3.6.7 of [RFC5322]) and is intended to be used for 2771 tracking message forwards, avoiding request loops, and identifying 2772 the protocol capabilities of all senders along the request/response 2773 chain. 2775 Via = "Via" ":" OWS Via-v 2776 Via-v = 1#( received-protocol RWS received-by 2777 [ RWS comment ] ) 2778 received-protocol = [ protocol-name "/" ] protocol-version 2779 protocol-name = token 2780 protocol-version = token 2781 received-by = ( uri-host [ ":" port ] ) / pseudonym 2782 pseudonym = token 2784 The received-protocol indicates the protocol version of the message 2785 received by the server or client along each segment of the request/ 2786 response chain. The received-protocol version is appended to the Via 2787 field value when the message is forwarded so that information about 2788 the protocol capabilities of upstream applications remains visible to 2789 all recipients. 2791 The protocol-name is excluded if and only if it would be "HTTP". The 2792 received-by field is normally the host and optional port number of a 2793 recipient server or client that subsequently forwarded the message. 2794 However, if the real host is considered to be sensitive information, 2795 it MAY be replaced by a pseudonym. If the port is not given, it MAY 2796 be assumed to be the default port of the received-protocol. 2798 Multiple Via field values represent each proxy or gateway that has 2799 forwarded the message. Each recipient MUST append its information 2800 such that the end result is ordered according to the sequence of 2801 forwarding applications. 2803 Comments MAY be used in the Via header field to identify the software 2804 of each recipient, analogous to the User-Agent and Server header 2805 fields. However, all comments in the Via field are optional and MAY 2806 be removed by any recipient prior to forwarding the message. 2808 For example, a request message could be sent from an HTTP/1.0 user 2809 agent to an internal proxy code-named "fred", which uses HTTP/1.1 to 2810 forward the request to a public proxy at p.example.net, which 2811 completes the request by forwarding it to the origin server at 2812 www.example.com. The request received by www.example.com would then 2813 have the following Via header field: 2815 Via: 1.0 fred, 1.1 p.example.net (Apache/1.1) 2817 A proxy or gateway used as a portal through a network firewall SHOULD 2818 NOT forward the names and ports of hosts within the firewall region 2819 unless it is explicitly enabled to do so. If not enabled, the 2820 received-by host of any host behind the firewall SHOULD be replaced 2821 by an appropriate pseudonym for that host. 2823 For organizations that have strong privacy requirements for hiding 2824 internal structures, a proxy or gateway MAY combine an ordered 2825 subsequence of Via header field entries with identical received- 2826 protocol values into a single such entry. For example, 2828 Via: 1.0 ricky, 1.1 ethel, 1.1 fred, 1.0 lucy 2830 could be collapsed to 2832 Via: 1.0 ricky, 1.1 mertz, 1.0 lucy 2834 Senders SHOULD NOT combine multiple entries unless they are all under 2835 the same organizational control and the hosts have already been 2836 replaced by pseudonyms. Senders MUST NOT combine entries which have 2837 different received-protocol values. 2839 10. IANA Considerations 2841 10.1. Header Field Registration 2843 The Message Header Field Registry located at shall be 2845 updated with the permanent registrations below (see [RFC3864]): 2847 +-------------------+----------+----------+-------------+ 2848 | Header Field Name | Protocol | Status | Reference | 2849 +-------------------+----------+----------+-------------+ 2850 | Connection | http | standard | Section 9.1 | 2851 | Content-Length | http | standard | Section 9.2 | 2852 | Date | http | standard | Section 9.3 | 2853 | Host | http | standard | Section 9.4 | 2854 | TE | http | standard | Section 9.5 | 2855 | Trailer | http | standard | Section 9.6 | 2856 | Transfer-Encoding | http | standard | Section 9.7 | 2857 | Upgrade | http | standard | Section 9.8 | 2858 | Via | http | standard | Section 9.9 | 2859 +-------------------+----------+----------+-------------+ 2861 The change controller is: "IETF (iesg@ietf.org) - Internet 2862 Engineering Task Force". 2864 10.2. URI Scheme Registration 2866 The entries for the "http" and "https" URI Schemes in the registry 2867 located at shall 2868 be updated to point to Sections 2.6.1 and 2.6.2 of this document (see 2869 [RFC4395]). 2871 10.3. Internet Media Type Registrations 2873 This document serves as the specification for the Internet media 2874 types "message/http" and "application/http". The following is to be 2875 registered with IANA (see [RFC4288]). 2877 10.3.1. Internet Media Type message/http 2879 The message/http type can be used to enclose a single HTTP request or 2880 response message, provided that it obeys the MIME restrictions for 2881 all "message" types regarding line length and encodings. 2883 Type name: message 2885 Subtype name: http 2887 Required parameters: none 2889 Optional parameters: version, msgtype 2891 version: The HTTP-Version number of the enclosed message (e.g., 2892 "1.1"). If not present, the version can be determined from the 2893 first line of the body. 2895 msgtype: The message type -- "request" or "response". If not 2896 present, the type can be determined from the first line of the 2897 body. 2899 Encoding considerations: only "7bit", "8bit", or "binary" are 2900 permitted 2902 Security considerations: none 2904 Interoperability considerations: none 2906 Published specification: This specification (see Section 10.3.1). 2908 Applications that use this media type: 2910 Additional information: 2912 Magic number(s): none 2914 File extension(s): none 2916 Macintosh file type code(s): none 2918 Person and email address to contact for further information: See 2919 Authors Section. 2921 Intended usage: COMMON 2923 Restrictions on usage: none 2925 Author/Change controller: IESG 2927 10.3.2. Internet Media Type application/http 2929 The application/http type can be used to enclose a pipeline of one or 2930 more HTTP request or response messages (not intermixed). 2932 Type name: application 2934 Subtype name: http 2936 Required parameters: none 2938 Optional parameters: version, msgtype 2940 version: The HTTP-Version number of the enclosed messages (e.g., 2941 "1.1"). If not present, the version can be determined from the 2942 first line of the body. 2944 msgtype: The message type -- "request" or "response". If not 2945 present, the type can be determined from the first line of the 2946 body. 2948 Encoding considerations: HTTP messages enclosed by this type are in 2949 "binary" format; use of an appropriate Content-Transfer-Encoding 2950 is required when transmitted via E-mail. 2952 Security considerations: none 2954 Interoperability considerations: none 2956 Published specification: This specification (see Section 10.3.2). 2958 Applications that use this media type: 2960 Additional information: 2962 Magic number(s): none 2964 File extension(s): none 2966 Macintosh file type code(s): none 2968 Person and email address to contact for further information: See 2969 Authors Section. 2971 Intended usage: COMMON 2972 Restrictions on usage: none 2974 Author/Change controller: IESG 2976 10.4. Transfer Coding Registry 2978 The registration procedure for HTTP Transfer Codings is now defined 2979 by Section 6.2.3 of this document. 2981 The HTTP Transfer Codings Registry located at 2982 shall be updated 2983 with the registrations below: 2985 +----------+--------------------------------------+-----------------+ 2986 | Name | Description | Reference | 2987 +----------+--------------------------------------+-----------------+ 2988 | chunked | Transfer in a series of chunks | Section 6.2.1 | 2989 | compress | UNIX "compress" program method | Section 6.2.2.1 | 2990 | deflate | "deflate" compression mechanism | Section 6.2.2.2 | 2991 | | ([RFC1951]) used inside the "zlib" | | 2992 | | data format ([RFC1950]) | | 2993 | gzip | Same as GNU zip [RFC1952] | Section 6.2.2.3 | 2994 +----------+--------------------------------------+-----------------+ 2996 10.5. Upgrade Token Registration 2998 The registration procedure for HTTP Upgrade Tokens -- previously 2999 defined in Section 7.2 of [RFC2817] -- is now defined by 3000 Section 9.8.1 of this document. 3002 The HTTP Status Code Registry located at 3003 shall be 3004 updated with the registration below: 3006 +-------+---------------------------+-------------------------------+ 3007 | Value | Description | Reference | 3008 +-------+---------------------------+-------------------------------+ 3009 | HTTP | Hypertext Transfer | Section 2.5 of this | 3010 | | Protocol | specification | 3011 +-------+---------------------------+-------------------------------+ 3013 11. Security Considerations 3015 This section is meant to inform application developers, information 3016 providers, and users of the security limitations in HTTP/1.1 as 3017 described by this document. The discussion does not include 3018 definitive solutions to the problems revealed, though it does make 3019 some suggestions for reducing security risks. 3021 11.1. Personal Information 3023 HTTP clients are often privy to large amounts of personal information 3024 (e.g., the user's name, location, mail address, passwords, encryption 3025 keys, etc.), and SHOULD be very careful to prevent unintentional 3026 leakage of this information. We very strongly recommend that a 3027 convenient interface be provided for the user to control 3028 dissemination of such information, and that designers and 3029 implementors be particularly careful in this area. History shows 3030 that errors in this area often create serious security and/or privacy 3031 problems and generate highly adverse publicity for the implementor's 3032 company. 3034 11.2. Abuse of Server Log Information 3036 A server is in the position to save personal data about a user's 3037 requests which might identify their reading patterns or subjects of 3038 interest. This information is clearly confidential in nature and its 3039 handling can be constrained by law in certain countries. People 3040 using HTTP to provide data are responsible for ensuring that such 3041 material is not distributed without the permission of any individuals 3042 that are identifiable by the published results. 3044 11.3. Attacks Based On File and Path Names 3046 Implementations of HTTP origin servers SHOULD be careful to restrict 3047 the documents returned by HTTP requests to be only those that were 3048 intended by the server administrators. If an HTTP server translates 3049 HTTP URIs directly into file system calls, the server MUST take 3050 special care not to serve files that were not intended to be 3051 delivered to HTTP clients. For example, UNIX, Microsoft Windows, and 3052 other operating systems use ".." as a path component to indicate a 3053 directory level above the current one. On such a system, an HTTP 3054 server MUST disallow any such construct in the request-target if it 3055 would otherwise allow access to a resource outside those intended to 3056 be accessible via the HTTP server. Similarly, files intended for 3057 reference only internally to the server (such as access control 3058 files, configuration files, and script code) MUST be protected from 3059 inappropriate retrieval, since they might contain sensitive 3060 information. Experience has shown that minor bugs in such HTTP 3061 server implementations have turned into security risks. 3063 11.4. DNS Spoofing 3065 Clients using HTTP rely heavily on the Domain Name Service, and are 3066 thus generally prone to security attacks based on the deliberate mis- 3067 association of IP addresses and DNS names. Clients need to be 3068 cautious in assuming the continuing validity of an IP number/DNS name 3069 association. 3071 In particular, HTTP clients SHOULD rely on their name resolver for 3072 confirmation of an IP number/DNS name association, rather than 3073 caching the result of previous host name lookups. Many platforms 3074 already can cache host name lookups locally when appropriate, and 3075 they SHOULD be configured to do so. It is proper for these lookups 3076 to be cached, however, only when the TTL (Time To Live) information 3077 reported by the name server makes it likely that the cached 3078 information will remain useful. 3080 If HTTP clients cache the results of host name lookups in order to 3081 achieve a performance improvement, they MUST observe the TTL 3082 information reported by DNS. 3084 If HTTP clients do not observe this rule, they could be spoofed when 3085 a previously-accessed server's IP address changes. As network 3086 renumbering is expected to become increasingly common [RFC1900], the 3087 possibility of this form of attack will grow. Observing this 3088 requirement thus reduces this potential security vulnerability. 3090 This requirement also improves the load-balancing behavior of clients 3091 for replicated servers using the same DNS name and reduces the 3092 likelihood of a user's experiencing failure in accessing sites which 3093 use that strategy. 3095 11.5. Proxies and Caching 3097 By their very nature, HTTP proxies are men-in-the-middle, and 3098 represent an opportunity for man-in-the-middle attacks. Compromise 3099 of the systems on which the proxies run can result in serious 3100 security and privacy problems. Proxies have access to security- 3101 related information, personal information about individual users and 3102 organizations, and proprietary information belonging to users and 3103 content providers. A compromised proxy, or a proxy implemented or 3104 configured without regard to security and privacy considerations, 3105 might be used in the commission of a wide range of potential attacks. 3107 Proxy operators need to protect the systems on which proxies run as 3108 they would protect any system that contains or transports sensitive 3109 information. In particular, log information gathered at proxies 3110 often contains highly sensitive personal information, and/or 3111 information about organizations. Log information needs to be 3112 carefully guarded, and appropriate guidelines for use need to be 3113 developed and followed. (Section 11.2). 3115 Proxy implementors need to consider the privacy and security 3116 implications of their design and coding decisions, and of the 3117 configuration options they provide to proxy operators (especially the 3118 default configuration). 3120 Users of a proxy need to be aware that proxies are no trustworthier 3121 than the people who run them; HTTP itself cannot solve this problem. 3123 The judicious use of cryptography, when appropriate, might suffice to 3124 protect against a broad range of security and privacy attacks. Such 3125 cryptography is beyond the scope of the HTTP/1.1 specification. 3127 11.6. Denial of Service Attacks on Proxies 3129 They exist. They are hard to defend against. Research continues. 3130 Beware. 3132 12. Acknowledgments 3134 HTTP has evolved considerably over the years. It has benefited from 3135 a large and active developer community -- the many people who have 3136 participated on the www-talk mailing list -- and it is that community 3137 which has been most responsible for the success of HTTP and of the 3138 World-Wide Web in general. Marc Andreessen, Robert Cailliau, Daniel 3139 W. Connolly, Bob Denny, John Franks, Jean-Francois Groff, Phillip M. 3140 Hallam-Baker, Hakon W. Lie, Ari Luotonen, Rob McCool, Lou Montulli, 3141 Dave Raggett, Tony Sanders, and Marc VanHeyningen deserve special 3142 recognition for their efforts in defining early aspects of the 3143 protocol. 3145 This document has benefited greatly from the comments of all those 3146 participating in the HTTP-WG. In addition to those already 3147 mentioned, the following individuals have contributed to this 3148 specification: 3150 Gary Adams, Harald Tveit Alvestrand, Keith Ball, Brian Behlendorf, 3151 Paul Burchard, Maurizio Codogno, Josh Cohen, Mike Cowlishaw, Roman 3152 Czyborra, Michael A. Dolan, Daniel DuBois, David J. Fiander, Alan 3153 Freier, Marc Hedlund, Greg Herlihy, Koen Holtman, Alex Hopmann, Bob 3154 Jernigan, Shel Kaphan, Rohit Khare, John Klensin, Martijn Koster, 3155 Alexei Kosut, David M. Kristol, Daniel LaLiberte, Ben Laurie, Paul J. 3156 Leach, Albert Lunde, John C. Mallery, Jean-Philippe Martin-Flatin, 3157 Mitra, David Morris, Gavin Nicol, Ross Patterson, Bill Perry, Jeffrey 3158 Perry, Scott Powers, Owen Rees, Luigi Rizzo, David Robinson, Marc 3159 Salomon, Rich Salz, Allan M. Schiffman, Jim Seidman, Chuck Shotton, 3160 Eric W. Sink, Simon E. Spero, Richard N. Taylor, Robert S. Thau, Bill 3161 (BearHeart) Weinman, Francois Yergeau, Mary Ellen Zurko. 3163 Thanks to the "cave men" of Palo Alto. You know who you are. 3165 Jim Gettys (the editor of [RFC2616]) wishes particularly to thank Roy 3166 Fielding, the editor of [RFC2068], along with John Klensin, Jeff 3167 Mogul, Paul Leach, Dave Kristol, Koen Holtman, John Franks, Josh 3168 Cohen, Alex Hopmann, Scott Lawrence, and Larry Masinter for their 3169 help. And thanks go particularly to Jeff Mogul and Scott Lawrence 3170 for performing the "MUST/MAY/SHOULD" audit. 3172 The Apache Group, Anselm Baird-Smith, author of Jigsaw, and Henrik 3173 Frystyk implemented RFC 2068 early, and we wish to thank them for the 3174 discovery of many of the problems that this document attempts to 3175 rectify. 3177 This specification makes heavy use of the augmented BNF and generic 3178 constructs defined by David H. Crocker for [RFC5234]. Similarly, it 3179 reuses many of the definitions provided by Nathaniel Borenstein and 3180 Ned Freed for MIME [RFC2045]. We hope that their inclusion in this 3181 specification will help reduce past confusion over the relationship 3182 between HTTP and Internet mail message formats. 3184 13. References 3186 13.1. Normative References 3188 [ISO-8859-1] International Organization for 3189 Standardization, "Information 3190 technology -- 8-bit single-byte coded 3191 graphic character sets -- Part 1: 3192 Latin alphabet No. 1", ISO/ 3193 IEC 8859-1:1998, 1998. 3195 [Part2] Fielding, R., Ed., Gettys, J., Mogul, 3196 J., Frystyk, H., Masinter, L., Leach, 3197 P., Berners-Lee, T., Lafon, Y., Ed., 3198 and J. Reschke, Ed., "HTTP/1.1, part 3199 2: Message Semantics", 3200 draft-ietf-httpbis-p2-semantics-13 3201 (work in progress), March 2011. 3203 [Part3] Fielding, R., Ed., Gettys, J., Mogul, 3204 J., Frystyk, H., Masinter, L., Leach, 3205 P., Berners-Lee, T., Lafon, Y., Ed., 3206 and J. Reschke, Ed., "HTTP/1.1, part 3207 3: Message Payload and Content 3208 Negotiation", 3209 draft-ietf-httpbis-p3-payload-13 (work 3210 in progress), March 2011. 3212 [Part6] Fielding, R., Ed., Gettys, J., Mogul, 3213 J., Frystyk, H., Masinter, L., Leach, 3214 P., Berners-Lee, T., Lafon, Y., Ed., 3215 Nottingham, M., Ed., and J. Reschke, 3216 Ed., "HTTP/1.1, part 6: Caching", 3217 draft-ietf-httpbis-p6-cache-13 (work 3218 in progress), March 2011. 3220 [RFC1950] Deutsch, L. and J-L. Gailly, "ZLIB 3221 Compressed Data Format Specification 3222 version 3.3", RFC 1950, May 1996. 3224 RFC 1950 is an Informational RFC, thus 3225 it might be less stable than this 3226 specification. On the other hand, 3227 this downward reference was present 3228 since the publication of RFC 2068 in 3229 1997 ([RFC2068]), therefore it is 3230 unlikely to cause problems in 3231 practice. See also [BCP97]. 3233 [RFC1951] Deutsch, P., "DEFLATE Compressed Data 3234 Format Specification version 1.3", 3235 RFC 1951, May 1996. 3237 RFC 1951 is an Informational RFC, thus 3238 it might be less stable than this 3239 specification. On the other hand, 3240 this downward reference was present 3241 since the publication of RFC 2068 in 3242 1997 ([RFC2068]), therefore it is 3243 unlikely to cause problems in 3244 practice. See also [BCP97]. 3246 [RFC1952] Deutsch, P., Gailly, J-L., Adler, M., 3247 Deutsch, L., and G. Randers-Pehrson, 3248 "GZIP file format specification 3249 version 4.3", RFC 1952, May 1996. 3251 RFC 1952 is an Informational RFC, thus 3252 it might be less stable than this 3253 specification. On the other hand, 3254 this downward reference was present 3255 since the publication of RFC 2068 in 3256 1997 ([RFC2068]), therefore it is 3257 unlikely to cause problems in 3258 practice. See also [BCP97]. 3260 [RFC2119] Bradner, S., "Key words for use in 3261 RFCs to Indicate Requirement Levels", 3262 BCP 14, RFC 2119, March 1997. 3264 [RFC3986] Berners-Lee, T., Fielding, R., and L. 3265 Masinter, "Uniform Resource Identifier 3266 (URI): Generic Syntax", STD 66, 3267 RFC 3986, January 2005. 3269 [RFC5234] Crocker, D., Ed. and P. Overell, 3270 "Augmented BNF for Syntax 3271 Specifications: ABNF", STD 68, 3272 RFC 5234, January 2008. 3274 [USASCII] American National Standards Institute, 3275 "Coded Character Set -- 7-bit American 3276 Standard Code for Information 3277 Interchange", ANSI X3.4, 1986. 3279 13.2. Informative References 3281 [BCP97] Klensin, J. and S. Hartman, "Handling 3282 Normative References to Standards- 3283 Track Documents", BCP 97, RFC 4897, 3284 June 2007. 3286 [Kri2001] Kristol, D., "HTTP Cookies: Standards, 3287 Privacy, and Politics", ACM 3288 Transactions on Internet 3289 Technology Vol. 1, #2, November 2001, 3290 . 3292 [Nie1997] Frystyk, H., Gettys, J., 3293 Prud'hommeaux, E., Lie, H., and C. 3294 Lilley, "Network Performance Effects 3295 of HTTP/1.1, CSS1, and PNG", 3296 ACM Proceedings of the ACM SIGCOMM '97 3297 conference on Applications, 3298 technologies, architectures, and 3299 protocols for computer communication 3300 SIGCOMM '97, September 1997, . 3303 [Pad1995] Padmanabhan, V. and J. Mogul, 3304 "Improving HTTP Latency", Computer 3305 Networks and ISDN Systems v. 28, pp. 3306 25-35, December 1995, . 3310 [RFC1123] Braden, R., "Requirements for Internet 3311 Hosts - Application and Support", 3312 STD 3, RFC 1123, October 1989. 3314 [RFC1900] Carpenter, B. and Y. Rekhter, 3315 "Renumbering Needs Work", RFC 1900, 3316 February 1996. 3318 [RFC1919] Chatel, M., "Classical versus 3319 Transparent IP Proxies", RFC 1919, 3320 March 1996. 3322 [RFC1945] Berners-Lee, T., Fielding, R., and H. 3323 Nielsen, "Hypertext Transfer Protocol 3324 -- HTTP/1.0", RFC 1945, May 1996. 3326 [RFC2045] Freed, N. and N. Borenstein, 3327 "Multipurpose Internet Mail Extensions 3328 (MIME) Part One: Format of Internet 3329 Message Bodies", RFC 2045, 3330 November 1996. 3332 [RFC2047] Moore, K., "MIME (Multipurpose 3333 Internet Mail Extensions) Part Three: 3334 Message Header Extensions for Non- 3335 ASCII Text", RFC 2047, November 1996. 3337 [RFC2068] Fielding, R., Gettys, J., Mogul, J., 3338 Nielsen, H., and T. Berners-Lee, 3339 "Hypertext Transfer Protocol -- 3340 HTTP/1.1", RFC 2068, January 1997. 3342 [RFC2145] Mogul, J., Fielding, R., Gettys, J., 3343 and H. Nielsen, "Use and 3344 Interpretation of HTTP Version 3345 Numbers", RFC 2145, May 1997. 3347 [RFC2616] Fielding, R., Gettys, J., Mogul, J., 3348 Frystyk, H., Masinter, L., Leach, P., 3349 and T. Berners-Lee, "Hypertext 3350 Transfer Protocol -- HTTP/1.1", 3351 RFC 2616, June 1999. 3353 [RFC2817] Khare, R. and S. Lawrence, "Upgrading 3354 to TLS Within HTTP/1.1", RFC 2817, 3355 May 2000. 3357 [RFC2818] Rescorla, E., "HTTP Over TLS", 3358 RFC 2818, May 2000. 3360 [RFC2965] Kristol, D. and L. Montulli, "HTTP 3361 State Management Mechanism", RFC 2965, 3362 October 2000. 3364 [RFC3040] Cooper, I., Melve, I., and G. 3365 Tomlinson, "Internet Web Replication 3366 and Caching Taxonomy", RFC 3040, 3367 January 2001. 3369 [RFC3864] Klyne, G., Nottingham, M., and J. 3370 Mogul, "Registration Procedures for 3371 Message Header Fields", BCP 90, 3372 RFC 3864, September 2004. 3374 [RFC4288] Freed, N. and J. Klensin, "Media Type 3375 Specifications and Registration 3376 Procedures", BCP 13, RFC 4288, 3377 December 2005. 3379 [RFC4395] Hansen, T., Hardie, T., and L. 3380 Masinter, "Guidelines and Registration 3381 Procedures for New URI Schemes", 3382 BCP 115, RFC 4395, February 2006. 3384 [RFC5226] Narten, T. and H. Alvestrand, 3385 "Guidelines for Writing an IANA 3386 Considerations Section in RFCs", 3387 BCP 26, RFC 5226, May 2008. 3389 [RFC5322] Resnick, P., "Internet Message 3390 Format", RFC 5322, October 2008. 3392 [Spe] Spero, S., "Analysis of HTTP 3393 Performance Problems", . 3397 [Tou1998] Touch, J., Heidemann, J., and K. 3398 Obraczka, "Analysis of HTTP 3399 Performance", ISI Research Report ISI/ 3400 RR-98-463, Aug 1998, . 3403 (original report dated Aug. 1996) 3405 [draft-ietf-httpstate-cookie] Barth, A., "HTTP State Management 3406 Mechanism", 3407 draft-ietf-httpstate-cookie-23 (work 3408 in progress), March 2011. 3410 Appendix A. Tolerant Applications 3412 Although this document specifies the requirements for the generation 3413 of HTTP/1.1 messages, not all applications will be correct in their 3414 implementation. We therefore recommend that operational applications 3415 be tolerant of deviations whenever those deviations can be 3416 interpreted unambiguously. 3418 The line terminator for header fields is the sequence CRLF. However, 3419 we recommend that applications, when parsing such headers fields, 3420 recognize a single LF as a line terminator and ignore the leading CR. 3422 The character encoding of a representation SHOULD be labeled as the 3423 lowest common denominator of the character codes used within that 3424 representation, with the exception that not labeling the 3425 representation is preferred over labeling the representation with the 3426 labels US-ASCII or ISO-8859-1. See [Part3]. 3428 Additional rules for requirements on parsing and encoding of dates 3429 and other potential problems with date encodings include: 3431 o HTTP/1.1 clients and caches SHOULD assume that an RFC-850 date 3432 which appears to be more than 50 years in the future is in fact in 3433 the past (this helps solve the "year 2000" problem). 3435 o Although all date formats are specified to be case-sensitive, 3436 recipients SHOULD match day, week and timezone names case- 3437 insensitively. 3439 o An HTTP/1.1 implementation MAY internally represent a parsed 3440 Expires date as earlier than the proper value, but MUST NOT 3441 internally represent a parsed Expires date as later than the 3442 proper value. 3444 o All expiration-related calculations MUST be done in GMT. The 3445 local time zone MUST NOT influence the calculation or comparison 3446 of an age or expiration time. 3448 o If an HTTP header field incorrectly carries a date value with a 3449 time zone other than GMT, it MUST be converted into GMT using the 3450 most conservative possible conversion. 3452 Appendix B. HTTP Version History 3454 HTTP has been in use by the World-Wide Web global information 3455 initiative since 1990. The first version of HTTP, later referred to 3456 as HTTP/0.9, was a simple protocol for hypertext data transfer across 3457 the Internet with only a single request method (GET) and no metadata. 3458 HTTP/1.0, as defined by [RFC1945], added a range of request methods 3459 and MIME-like messaging that could include metadata about the data 3460 transferred and modifiers on the request/response semantics. 3461 However, HTTP/1.0 did not sufficiently take into consideration the 3462 effects of hierarchical proxies, caching, the need for persistent 3463 connections, or name-based virtual hosts. The proliferation of 3464 incompletely-implemented applications calling themselves "HTTP/1.0" 3465 further necessitated a protocol version change in order for two 3466 communicating applications to determine each other's true 3467 capabilities. 3469 HTTP/1.1 remains compatible with HTTP/1.0 by including more stringent 3470 requirements that enable reliable implementations, adding only those 3471 new features that will either be safely ignored by an HTTP/1.0 3472 recipient or only sent when communicating with a party advertising 3473 compliance with HTTP/1.1. 3475 It is beyond the scope of a protocol specification to mandate 3476 compliance with previous versions. HTTP/1.1 was deliberately 3477 designed, however, to make supporting previous versions easy. We 3478 would expect a general-purpose HTTP/1.1 server to understand any 3479 valid request in the format of HTTP/1.0 and respond appropriately 3480 with an HTTP/1.1 message that only uses features understood (or 3481 safely ignored) by HTTP/1.0 clients. Likewise, would expect an 3482 HTTP/1.1 client to understand any valid HTTP/1.0 response. 3484 Since HTTP/0.9 did not support header fields in a request, there is 3485 no mechanism for it to support name-based virtual hosts (selection of 3486 resource by inspection of the Host header field). Any server that 3487 implements name-based virtual hosts ought to disable support for 3488 HTTP/0.9. Most requests that appear to be HTTP/0.9 are, in fact, 3489 badly constructed HTTP/1.x requests wherein a buggy client failed to 3490 properly encode linear whitespace found in a URI reference and placed 3491 in the request-target. 3493 B.1. Changes from HTTP/1.0 3495 This section summarizes major differences between versions HTTP/1.0 3496 and HTTP/1.1. 3498 B.1.1. Multi-homed Web Servers 3500 The requirements that clients and servers support the Host header 3501 field (Section 9.4), report an error if it is missing from an 3502 HTTP/1.1 request, and accept absolute URIs (Section 4.1.2) are among 3503 the most important changes defined by HTTP/1.1. 3505 Older HTTP/1.0 clients assumed a one-to-one relationship of IP 3506 addresses and servers; there was no other established mechanism for 3507 distinguishing the intended server of a request than the IP address 3508 to which that request was directed. The Host header field was 3509 introduced during the development of HTTP/1.1 and, though it was 3510 quickly implemented by most HTTP/1.0 browsers, additional 3511 requirements were placed on all HTTP/1.1 requests in order to ensure 3512 complete adoption. At the time of this writing, most HTTP-based 3513 services are dependent upon the Host header field for targeting 3514 requests. 3516 B.1.2. Keep-Alive Connections 3518 For most implementations of HTTP/1.0, each connection is established 3519 by the client prior to the request and closed by the server after 3520 sending the response. However, some implementations implement the 3521 Keep-Alive version of persistent connections described in Section 3522 19.7.1 of [RFC2068]. 3524 Some clients and servers might wish to be compatible with some 3525 previous implementations of persistent connections in HTTP/1.0 3526 clients and servers. Persistent connections in HTTP/1.0 are 3527 explicitly negotiated as they are not the default behavior. HTTP/1.0 3528 experimental implementations of persistent connections are faulty, 3529 and the new facilities in HTTP/1.1 are designed to rectify these 3530 problems. The problem was that some existing HTTP/1.0 clients might 3531 send Keep-Alive to a proxy server that doesn't understand Connection, 3532 which would then erroneously forward it to the next inbound server, 3533 which would establish the Keep-Alive connection and result in a hung 3534 HTTP/1.0 proxy waiting for the close on the response. The result is 3535 that HTTP/1.0 clients must be prevented from using Keep-Alive when 3536 talking to proxies. 3538 However, talking to proxies is the most important use of persistent 3539 connections, so that prohibition is clearly unacceptable. Therefore, 3540 we need some other mechanism for indicating a persistent connection 3541 is desired, which is safe to use even when talking to an old proxy 3542 that ignores Connection. Persistent connections are the default for 3543 HTTP/1.1 messages; we introduce a new keyword (Connection: close) for 3544 declaring non-persistence. See Section 9.1. 3546 B.2. Changes from RFC 2616 3548 Empty list elements in list productions have been deprecated. 3549 (Section 1.2.1) 3551 Rules about implicit linear whitespace between certain grammar 3552 productions have been removed; now it's only allowed when 3553 specifically pointed out in the ABNF. The NUL octet is no longer 3554 allowed in comment and quoted-string text. The quoted-pair rule no 3555 longer allows escaping control characters other than HTAB. Non-ASCII 3556 content in header fields and reason phrase has been obsoleted and 3557 made opaque (the TEXT rule was removed) (Section 1.2.2) 3559 Clarify that HTTP-Version is case sensitive. (Section 2.5) 3561 Require that invalid whitespace around field-names be rejected. 3562 (Section 3.2) 3564 Require recipients to handle bogus Content-Length header fields as 3565 errors. (Section 3.3) 3567 Remove reference to non-existent identity transfer-coding value 3568 tokens. (Sections 3.3 and 6.2) 3570 Update use of abs_path production from RFC 1808 to the path-absolute 3571 + query components of RFC 3986. State that the asterisk form is 3572 allowed for the OPTIONS request method only. (Section 4.1.2) 3574 Clarification that the chunk length does not include the count of the 3575 octets in the chunk header and trailer. Furthermore disallowed line 3576 folding in chunk extensions. (Section 6.2.1) 3578 Remove hard limit of two connections per server. (Section 7.1.4) 3580 Clarify exactly when close connection options must be sent. 3581 (Section 9.1) 3583 Define the semantics of the "Upgrade" header field in responses other 3584 than 101 (this was incorporated from [RFC2817]). (Section 9.8) 3586 Appendix C. Collected ABNF 3588 BWS = OWS 3590 Chunked-Body = *chunk last-chunk trailer-part CRLF 3591 Connection = "Connection:" OWS Connection-v 3592 Connection-v = *( "," OWS ) connection-token *( OWS "," [ OWS 3593 connection-token ] ) 3595 Content-Length = "Content-Length:" OWS 1*Content-Length-v 3596 Content-Length-v = 1*DIGIT 3598 Date = "Date:" OWS Date-v 3599 Date-v = HTTP-date 3601 GMT = %x47.4D.54 ; GMT 3603 HTTP-Prot-Name = %x48.54.54.50 ; HTTP 3604 HTTP-Version = HTTP-Prot-Name "/" 1*DIGIT "." 1*DIGIT 3605 HTTP-date = rfc1123-date / obs-date 3606 HTTP-message = start-line *( header-field CRLF ) CRLF [ message-body 3607 ] 3608 Host = "Host:" OWS Host-v 3609 Host-v = uri-host [ ":" port ] 3611 Method = token 3613 OWS = *( [ obs-fold ] WSP ) 3615 RWS = 1*( [ obs-fold ] WSP ) 3616 Reason-Phrase = *( WSP / VCHAR / obs-text ) 3617 Request = Request-Line *( header-field CRLF ) CRLF [ message-body ] 3618 Request-Line = Method SP request-target SP HTTP-Version CRLF 3619 Response = Status-Line *( header-field CRLF ) CRLF [ message-body ] 3621 Status-Code = 3DIGIT 3622 Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF 3624 TE = "TE:" OWS TE-v 3625 TE-v = [ ( "," / t-codings ) *( OWS "," [ OWS t-codings ] ) ] 3626 Trailer = "Trailer:" OWS Trailer-v 3627 Trailer-v = *( "," OWS ) field-name *( OWS "," [ OWS field-name ] ) 3628 Transfer-Encoding = "Transfer-Encoding:" OWS Transfer-Encoding-v 3629 Transfer-Encoding-v = *( "," OWS ) transfer-coding *( OWS "," [ OWS 3630 transfer-coding ] ) 3632 URI-reference = 3633 Upgrade = "Upgrade:" OWS Upgrade-v 3634 Upgrade-v = *( "," OWS ) product *( OWS "," [ OWS product ] ) 3636 Via = "Via:" OWS Via-v 3637 Via-v = *( "," OWS ) received-protocol RWS received-by [ RWS comment 3638 ] *( OWS "," [ OWS received-protocol RWS received-by [ RWS comment ] 3639 ] ) 3641 absolute-URI = 3642 asctime-date = day-name SP date3 SP time-of-day SP year 3643 attribute = token 3644 authority = 3646 chunk = chunk-size *WSP [ chunk-ext ] CRLF chunk-data CRLF 3647 chunk-data = 1*OCTET 3648 chunk-ext = *( ";" *WSP chunk-ext-name [ "=" chunk-ext-val ] *WSP ) 3649 chunk-ext-name = token 3650 chunk-ext-val = token / quoted-str-nf 3651 chunk-size = 1*HEXDIG 3652 comment = "(" *( ctext / quoted-cpair / comment ) ")" 3653 connection-token = token 3654 ctext = OWS / %x21-27 ; '!'-''' 3655 / %x2A-5B ; '*'-'[' 3656 / %x5D-7E ; ']'-'~' 3657 / obs-text 3659 date1 = day SP month SP year 3660 date2 = day "-" month "-" 2DIGIT 3661 date3 = month SP ( 2DIGIT / ( SP DIGIT ) ) 3662 day = 2DIGIT 3663 day-name = %x4D.6F.6E ; Mon 3664 / %x54.75.65 ; Tue 3665 / %x57.65.64 ; Wed 3666 / %x54.68.75 ; Thu 3667 / %x46.72.69 ; Fri 3668 / %x53.61.74 ; Sat 3669 / %x53.75.6E ; Sun 3670 day-name-l = %x4D.6F.6E.64.61.79 ; Monday 3671 / %x54.75.65.73.64.61.79 ; Tuesday 3672 / %x57.65.64.6E.65.73.64.61.79 ; Wednesday 3673 / %x54.68.75.72.73.64.61.79 ; Thursday 3674 / %x46.72.69.64.61.79 ; Friday 3675 / %x53.61.74.75.72.64.61.79 ; Saturday 3676 / %x53.75.6E.64.61.79 ; Sunday 3678 field-content = *( WSP / VCHAR / obs-text ) 3679 field-name = token 3680 field-value = *( field-content / OWS ) 3682 header-field = field-name ":" OWS [ field-value ] OWS 3683 hour = 2DIGIT 3684 http-URI = "http://" authority path-abempty [ "?" query ] 3685 https-URI = "https://" authority path-abempty [ "?" query ] 3687 last-chunk = 1*"0" *WSP [ chunk-ext ] CRLF 3689 message-body = *OCTET 3690 minute = 2DIGIT 3691 month = %x4A.61.6E ; Jan 3692 / %x46.65.62 ; Feb 3693 / %x4D.61.72 ; Mar 3694 / %x41.70.72 ; Apr 3695 / %x4D.61.79 ; May 3696 / %x4A.75.6E ; Jun 3697 / %x4A.75.6C ; Jul 3698 / %x41.75.67 ; Aug 3699 / %x53.65.70 ; Sep 3700 / %x4F.63.74 ; Oct 3701 / %x4E.6F.76 ; Nov 3702 / %x44.65.63 ; Dec 3704 obs-date = rfc850-date / asctime-date 3705 obs-fold = CRLF 3706 obs-text = %x80-FF 3708 partial-URI = relative-part [ "?" query ] 3709 path-abempty = 3710 path-absolute = 3711 port = 3712 product = token [ "/" product-version ] 3713 product-version = token 3714 protocol-name = token 3715 protocol-version = token 3716 pseudonym = token 3718 qdtext = OWS / "!" / %x23-5B ; '#'-'[' 3719 / %x5D-7E ; ']'-'~' 3720 / obs-text 3721 qdtext-nf = WSP / "!" / %x23-5B ; '#'-'[' 3722 / %x5D-7E ; ']'-'~' 3723 / obs-text 3724 query = 3725 quoted-cpair = "\" ( WSP / VCHAR / obs-text ) 3726 quoted-pair = "\" ( WSP / VCHAR / obs-text ) 3727 quoted-str-nf = DQUOTE *( qdtext-nf / quoted-pair ) DQUOTE 3728 quoted-string = DQUOTE *( qdtext / quoted-pair ) DQUOTE 3729 qvalue = ( "0" [ "." *3DIGIT ] ) / ( "1" [ "." *3"0" ] ) 3731 received-by = ( uri-host [ ":" port ] ) / pseudonym 3732 received-protocol = [ protocol-name "/" ] protocol-version 3733 relative-part = 3734 request-target = "*" / absolute-URI / ( path-absolute [ "?" query ] ) 3735 / authority 3736 rfc1123-date = day-name "," SP date1 SP time-of-day SP GMT 3737 rfc850-date = day-name-l "," SP date2 SP time-of-day SP GMT 3738 second = 2DIGIT 3739 special = "(" / ")" / "<" / ">" / "@" / "," / ";" / ":" / "\" / 3740 DQUOTE / "/" / "[" / "]" / "?" / "=" / "{" / "}" 3741 start-line = Request-Line / Status-Line 3743 t-codings = "trailers" / ( transfer-extension [ te-params ] ) 3744 tchar = "!" / "#" / "$" / "%" / "&" / "'" / "*" / "+" / "-" / "." / 3745 "^" / "_" / "`" / "|" / "~" / DIGIT / ALPHA 3746 te-ext = OWS ";" OWS token [ "=" word ] 3747 te-params = OWS ";" OWS "q=" qvalue *te-ext 3748 time-of-day = hour ":" minute ":" second 3749 token = 1*tchar 3750 trailer-part = *( header-field CRLF ) 3751 transfer-coding = "chunked" / "compress" / "deflate" / "gzip" / 3752 transfer-extension 3753 transfer-extension = token *( OWS ";" OWS transfer-parameter ) 3754 transfer-parameter = attribute BWS "=" BWS value 3756 uri-host = 3758 value = word 3760 word = token / quoted-string 3762 year = 4DIGIT 3764 ABNF diagnostics: 3766 ; Chunked-Body defined but not used 3767 ; Connection defined but not used 3768 ; Content-Length defined but not used 3769 ; Date defined but not used 3770 ; HTTP-message defined but not used 3771 ; Host defined but not used 3772 ; Request defined but not used 3773 ; Response defined but not used 3774 ; TE defined but not used 3775 ; Trailer defined but not used 3776 ; Transfer-Encoding defined but not used 3777 ; URI-reference defined but not used 3778 ; Upgrade defined but not used 3779 ; Via defined but not used 3780 ; http-URI defined but not used 3781 ; https-URI defined but not used 3782 ; partial-URI defined but not used 3783 ; special defined but not used 3785 Appendix D. Change Log (to be removed by RFC Editor before publication) 3787 D.1. Since RFC 2616 3789 Extracted relevant partitions from [RFC2616]. 3791 D.2. Since draft-ietf-httpbis-p1-messaging-00 3793 Closed issues: 3795 o : "HTTP Version 3796 should be case sensitive" 3797 () 3799 o : "'unsafe' 3800 characters" () 3802 o : "Chunk Size 3803 Definition" () 3805 o : "Message Length" 3806 () 3808 o : "Media Type 3809 Registrations" () 3811 o : "URI includes 3812 query" () 3814 o : "No close on 3815 1xx responses" () 3817 o : "Remove 3818 'identity' token references" 3819 () 3821 o : "Import query 3822 BNF" 3824 o : "qdtext BNF" 3826 o : "Normative and 3827 Informative references" 3829 o : "RFC2606 3830 Compliance" 3832 o : "RFC977 3833 reference" 3835 o : "RFC1700 3836 references" 3838 o : "inconsistency 3839 in date format explanation" 3841 o : "Date reference 3842 typo" 3844 o : "Informative 3845 references" 3847 o : "ISO-8859-1 3848 Reference" 3850 o : "Normative up- 3851 to-date references" 3853 Other changes: 3855 o Update media type registrations to use RFC4288 template. 3857 o Use names of RFC4234 core rules DQUOTE and WSP, fix broken ABNF 3858 for chunk-data (work in progress on 3859 ) 3861 D.3. Since draft-ietf-httpbis-p1-messaging-01 3863 Closed issues: 3865 o : "Bodies on GET 3866 (and other) requests" 3868 o : "Updating to 3869 RFC4288" 3871 o : "Status Code 3872 and Reason Phrase" 3874 o : "rel_path not 3875 used" 3877 Ongoing work on ABNF conversion 3878 (): 3880 o Get rid of duplicate BNF rule names ("host" -> "uri-host", 3881 "trailer" -> "trailer-part"). 3883 o Avoid underscore character in rule names ("http_URL" -> "http- 3884 URL", "abs_path" -> "path-absolute"). 3886 o Add rules for terms imported from URI spec ("absoluteURI", 3887 "authority", "path-absolute", "port", "query", "relativeURI", 3888 "host) -- these will have to be updated when switching over to 3889 RFC3986. 3891 o Synchronize core rules with RFC5234. 3893 o Get rid of prose rules that span multiple lines. 3895 o Get rid of unused rules LOALPHA and UPALPHA. 3897 o Move "Product Tokens" section (back) into Part 1, as "token" is 3898 used in the definition of the Upgrade header field. 3900 o Add explicit references to BNF syntax and rules imported from 3901 other parts of the specification. 3903 o Rewrite prose rule "token" in terms of "tchar", rewrite prose rule 3904 "TEXT". 3906 D.4. Since draft-ietf-httpbis-p1-messaging-02 3908 Closed issues: 3910 o : "HTTP-date vs. 3911 rfc1123-date" 3913 o : "WS in quoted- 3914 pair" 3916 Ongoing work on IANA Message Header Field Registration 3917 (): 3919 o Reference RFC 3984, and update header field registrations for 3920 headers defined in this document. 3922 Ongoing work on ABNF conversion 3923 (): 3925 o Replace string literals when the string really is case-sensitive 3926 (HTTP-Version). 3928 D.5. Since draft-ietf-httpbis-p1-messaging-03 3930 Closed issues: 3932 o : "Connection 3933 closing" 3935 o : "Move 3936 registrations and registry information to IANA Considerations" 3938 o : "need new URL 3939 for PAD1995 reference" 3941 o : "IANA 3942 Considerations: update HTTP URI scheme registration" 3944 o : "Cite HTTPS 3945 URI scheme definition" 3947 o : "List-type 3948 headers vs Set-Cookie" 3950 Ongoing work on ABNF conversion 3951 (): 3953 o Replace string literals when the string really is case-sensitive 3954 (HTTP-Date). 3956 o Replace HEX by HEXDIG for future consistence with RFC 5234's core 3957 rules. 3959 D.6. Since draft-ietf-httpbis-p1-messaging-04 3961 Closed issues: 3963 o : "Out-of-date 3964 reference for URIs" 3966 o : "RFC 2822 is 3967 updated by RFC 5322" 3969 Ongoing work on ABNF conversion 3970 (): 3972 o Use "/" instead of "|" for alternatives. 3974 o Get rid of RFC822 dependency; use RFC5234 plus extensions instead. 3976 o Only reference RFC 5234's core rules. 3978 o Introduce new ABNF rules for "bad" whitespace ("BWS"), optional 3979 whitespace ("OWS") and required whitespace ("RWS"). 3981 o Rewrite ABNFs to spell out whitespace rules, factor out header 3982 field value format definitions. 3984 D.7. Since draft-ietf-httpbis-p1-messaging-05 3986 Closed issues: 3988 o : "Header LWS" 3990 o : "Sort 1.3 3991 Terminology" 3993 o : "RFC2047 3994 encoded words" 3996 o : "Character 3997 Encodings in TEXT" 3999 o : "Line Folding" 4001 o : "OPTIONS * and 4002 proxies" 4004 o : "Reason-Phrase 4005 BNF" 4007 o : "Use of TEXT" 4009 o : "Join 4010 "Differences Between HTTP Entities and RFC 2045 Entities"?" 4012 o : "RFC822 4013 reference left in discussion of date formats" 4015 Final work on ABNF conversion 4016 (): 4018 o Rewrite definition of list rules, deprecate empty list elements. 4020 o Add appendix containing collected and expanded ABNF. 4022 Other changes: 4024 o Rewrite introduction; add mostly new Architecture Section. 4026 o Move definition of quality values from Part 3 into Part 1; make TE 4027 request header field grammar independent of accept-params (defined 4028 in Part 3). 4030 D.8. Since draft-ietf-httpbis-p1-messaging-06 4032 Closed issues: 4034 o : "base for 4035 numeric protocol elements" 4037 o : "comment ABNF" 4039 Partly resolved issues: 4041 o : "205 Bodies" 4042 (took out language that implied that there might be methods for 4043 which a request body MUST NOT be included) 4045 o : "editorial 4046 improvements around HTTP-date" 4048 D.9. Since draft-ietf-httpbis-p1-messaging-07 4050 Closed issues: 4052 o : "Repeating 4053 single-value headers" 4055 o : "increase 4056 connection limit" 4058 o : "IP addresses 4059 in URLs" 4061 o : "take over 4062 HTTP Upgrade Token Registry" 4064 o : "CR and LF in 4065 chunk extension values" 4067 o : "HTTP/0.9 4068 support" 4070 o : "pick IANA 4071 policy (RFC5226) for Transfer Coding / Content Coding" 4073 o : "move 4074 definitions of gzip/deflate/compress to part 1" 4076 o : "disallow 4077 control characters in quoted-pair" 4079 Partly resolved issues: 4081 o : "update IANA 4082 requirements wrt Transfer-Coding values" (add the IANA 4083 Considerations subsection) 4085 D.10. Since draft-ietf-httpbis-p1-messaging-08 4087 Closed issues: 4089 o : "header 4090 parsing, treatment of leading and trailing OWS" 4092 Partly resolved issues: 4094 o : "Placement of 4095 13.5.1 and 13.5.2" 4097 o : "use of term 4098 "word" when talking about header structure" 4100 D.11. Since draft-ietf-httpbis-p1-messaging-09 4102 Closed issues: 4104 o : "Clarification 4105 of the term 'deflate'" 4107 o : "OPTIONS * and 4108 proxies" 4110 o : "MIME-Version 4111 not listed in P1, general header fields" 4113 o : "IANA registry 4114 for content/transfer encodings" 4116 o : "Case- 4117 sensitivity of HTTP-date" 4119 o : "use of term 4120 "word" when talking about header structure" 4122 Partly resolved issues: 4124 o : "Term for the 4125 requested resource's URI" 4127 D.12. Since draft-ietf-httpbis-p1-messaging-10 4129 Closed issues: 4131 o : "Connection 4132 Closing" 4134 o : "Delimiting 4135 messages with multipart/byteranges" 4137 o : "Handling 4138 multiple Content-Length headers" 4140 o : "Clarify 4141 entity / representation / variant terminology" 4143 o : "consider 4144 removing the 'changes from 2068' sections" 4146 Partly resolved issues: 4148 o : "HTTP(s) URI 4149 scheme definitions" 4151 D.13. Since draft-ietf-httpbis-p1-messaging-11 4153 Closed issues: 4155 o : "Trailer 4156 requirements" 4158 o : "Text about 4159 clock requirement for caches belongs in p6" 4161 o : "effective 4162 request URI: handling of missing host in HTTP/1.0" 4164 o : "confusing 4165 Date requirements for clients" 4167 Partly resolved issues: 4169 o : "Handling 4170 multiple Content-Length headers" 4172 D.14. Since draft-ietf-httpbis-p1-messaging-12 4174 Closed issues: 4176 o : "RFC2145 4177 Normative" 4179 o : "HTTP(s) URI 4180 scheme definitions" (tune the requirements on userinfo) 4182 o : "define 4183 'transparent' proxy" 4185 o : "Header 4186 Classification" 4188 o : "Is * usable 4189 as a request-uri for new methods?" 4191 o : "Migrate 4192 Upgrade details from RFC2817" 4194 o : "untangle 4195 ABNFs for header fields" 4197 o : "update RFC 4198 2109 reference" 4200 Index 4202 A 4203 absolute-URI form (of request-target) 29 4204 accelerator 13 4205 application/http Media Type 64 4206 asterisk form (of request-target) 28 4207 authority form (of request-target) 29 4209 B 4210 browser 10 4212 C 4213 cache 14 4214 cacheable 14 4215 captive portal 14 4216 chunked (Coding Format) 37 4217 client 10 4218 Coding Format 4219 chunked 37 4220 compress 40 4221 deflate 40 4222 gzip 40 4223 compress (Coding Format) 40 4224 connection 10 4225 Connection header field 51 4226 Content-Length header field 53 4228 D 4229 Date header field 53 4230 deflate (Coding Format) 40 4231 downstream 12 4233 E 4234 effective request URI 31 4236 G 4237 gateway 13 4238 Grammar 4239 absolute-URI 17 4240 ALPHA 7 4241 asctime-date 36 4242 attribute 36 4243 authority 17 4244 BWS 9 4245 chunk 37 4246 chunk-data 37 4247 chunk-ext 37 4248 chunk-ext-name 37 4249 chunk-ext-val 37 4250 chunk-size 37 4251 Chunked-Body 37 4252 comment 23 4253 Connection 52 4254 connection-token 52 4255 Connection-v 52 4256 Content-Length 53 4257 Content-Length-v 53 4258 CR 7 4259 CRLF 7 4260 ctext 23 4261 CTL 7 4262 Date 53 4263 Date-v 53 4264 date1 35 4265 date2 36 4266 date3 36 4267 day 35 4268 day-name 35 4269 day-name-l 35 4270 DIGIT 7 4271 DQUOTE 7 4272 field-content 22 4273 field-name 22 4274 field-value 22 4275 GMT 35 4276 header-field 22 4277 HEXDIG 7 4278 Host 55 4279 Host-v 55 4280 hour 35 4281 HTTP-date 34 4282 HTTP-message 21 4283 HTTP-Prot-Name 15 4284 http-URI 18 4285 HTTP-Version 15 4286 https-URI 19 4287 last-chunk 37 4288 LF 7 4289 message-body 24 4290 Method 28 4291 minute 35 4292 month 35 4293 obs-date 35 4294 obs-text 10 4295 OCTET 7 4296 OWS 9 4297 path-absolute 17 4298 port 17 4299 product 41 4300 product-version 41 4301 protocol-name 60 4302 protocol-version 60 4303 pseudonym 60 4304 qdtext 10 4305 qdtext-nf 37 4306 query 17 4307 quoted-cpair 24 4308 quoted-pair 10 4309 quoted-str-nf 37 4310 quoted-string 10 4311 qvalue 41 4312 Reason-Phrase 33 4313 received-by 60 4314 received-protocol 60 4315 Request 28 4316 Request-Line 28 4317 request-target 28 4318 Response 32 4319 rfc850-date 36 4320 rfc1123-date 35 4321 RWS 9 4322 second 35 4323 SP 7 4324 special 9 4325 Status-Code 33 4326 Status-Line 33 4327 t-codings 56 4328 tchar 9 4329 TE 56 4330 te-ext 56 4331 te-params 56 4332 TE-v 56 4333 time-of-day 35 4334 token 9 4335 Trailer 57 4336 trailer-part 37 4337 Trailer-v 57 4338 transfer-coding 36 4339 Transfer-Encoding 58 4340 Transfer-Encoding-v 58 4341 transfer-extension 36 4342 transfer-parameter 36 4343 Upgrade 58 4344 Upgrade-v 58 4345 uri-host 17 4346 URI-reference 17 4347 value 36 4348 VCHAR 7 4349 Via 60 4350 Via-v 60 4351 word 9 4352 WSP 7 4353 year 35 4354 gzip (Coding Format) 40 4356 H 4357 header field 20 4358 Header Fields 4359 Connection 51 4360 Content-Length 53 4361 Date 53 4362 Host 55 4363 TE 56 4364 Trailer 57 4365 Transfer-Encoding 58 4366 Upgrade 58 4367 Via 60 4368 header section 20 4369 headers 20 4370 Host header field 55 4371 http URI scheme 18 4372 https URI scheme 19 4374 I 4375 inbound 12 4376 interception proxy 14 4377 intermediary 12 4379 M 4380 Media Type 4381 application/http 64 4382 message/http 62 4383 message 11 4384 message/http Media Type 62 4386 N 4387 non-transforming proxy 13 4389 O 4390 origin form (of request-target) 29 4391 origin server 10 4392 outbound 12 4394 P 4395 proxy 13 4397 R 4398 request 11 4399 resource 17 4400 response 11 4401 reverse proxy 13 4403 S 4404 server 10 4405 spider 10 4407 T 4408 target resource 31 4409 TE header field 56 4410 Trailer header field 57 4411 Transfer-Encoding header field 58 4412 transforming proxy 13 4413 transparent proxy 14 4414 tunnel 14 4416 U 4417 Upgrade header field 58 4418 upstream 12 4419 URI scheme 4420 http 18 4421 https 19 4422 user agent 10 4424 V 4425 Via header field 60 4427 Authors' Addresses 4429 Roy T. Fielding (editor) 4430 Adobe Systems Incorporated 4431 345 Park Ave 4432 San Jose, CA 95110 4433 USA 4435 EMail: fielding@gbiv.com 4436 URI: http://roy.gbiv.com/ 4438 Jim Gettys 4439 Alcatel-Lucent Bell Labs 4440 21 Oak Knoll Road 4441 Carlisle, MA 01741 4442 USA 4444 EMail: jg@freedesktop.org 4445 URI: http://gettys.wordpress.com/ 4446 Jeffrey C. Mogul 4447 Hewlett-Packard Company 4448 HP Labs, Large Scale Systems Group 4449 1501 Page Mill Road, MS 1177 4450 Palo Alto, CA 94304 4451 USA 4453 EMail: JeffMogul@acm.org 4455 Henrik Frystyk Nielsen 4456 Microsoft Corporation 4457 1 Microsoft Way 4458 Redmond, WA 98052 4459 USA 4461 EMail: henrikn@microsoft.com 4463 Larry Masinter 4464 Adobe Systems Incorporated 4465 345 Park Ave 4466 San Jose, CA 95110 4467 USA 4469 EMail: LMM@acm.org 4470 URI: http://larry.masinter.net/ 4472 Paul J. Leach 4473 Microsoft Corporation 4474 1 Microsoft Way 4475 Redmond, WA 98052 4477 EMail: paulle@microsoft.com 4479 Tim Berners-Lee 4480 World Wide Web Consortium 4481 MIT Computer Science and Artificial Intelligence Laboratory 4482 The Stata Center, Building 32 4483 32 Vassar Street 4484 Cambridge, MA 02139 4485 USA 4487 EMail: timbl@w3.org 4488 URI: http://www.w3.org/People/Berners-Lee/ 4489 Yves Lafon (editor) 4490 World Wide Web Consortium 4491 W3C / ERCIM 4492 2004, rte des Lucioles 4493 Sophia-Antipolis, AM 06902 4494 France 4496 EMail: ylafon@w3.org 4497 URI: http://www.raubacapeu.net/people/yves/ 4499 Julian F. Reschke (editor) 4500 greenbytes GmbH 4501 Hafenweg 16 4502 Muenster, NW 48155 4503 Germany 4505 Phone: +49 251 2807760 4506 Fax: +49 251 2807761 4507 EMail: julian.reschke@greenbytes.de 4508 URI: http://greenbytes.de/tech/webdav/