idnits 2.17.1 draft-ietf-httpbis-p1-messaging-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 30. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 3298. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 3309. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 3316. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 3322. 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 16, 2008) is 5639 days in the past. Is this intentional? 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-05 == Outdated reference: A later version (-20) exists of draft-ietf-httpbis-p3-payload-05 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p5-range-05 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p6-cache-05 -- Possible downref: Non-RFC (?) normative reference: ref. 'USASCII' -- Obsolete informational reference (is this intentional?): RFC 1305 (Obsoleted by RFC 5905) -- Obsolete informational reference (is this intentional?): RFC 2068 (Obsoleted by RFC 2616) -- Obsolete informational reference (is this intentional?): RFC 2109 (Obsoleted by RFC 2965) -- Obsolete informational reference (is this intentional?): RFC 2145 (Obsoleted by RFC 7230) -- Obsolete informational reference (is this intentional?): RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) -- Obsolete informational reference (is this intentional?): RFC 2818 (Obsoleted by RFC 9110) -- Obsolete informational reference (is this intentional?): RFC 2965 (Obsoleted by RFC 6265) -- Obsolete informational reference (is this intentional?): RFC 4288 (Obsoleted by RFC 6838) -- Obsolete informational reference (is this intentional?): RFC 4395 (Obsoleted by RFC 7595) -- Obsolete informational reference (is this intentional?): RFC 822 (Obsoleted by RFC 2822) Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 19 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Fielding, Ed. 3 Internet-Draft Day Software 4 Obsoletes: 2616 (if approved) J. Gettys 5 Intended status: Standards Track One Laptop per Child 6 Expires: May 20, 2009 J. Mogul 7 HP 8 H. Frystyk 9 Microsoft 10 L. Masinter 11 Adobe Systems 12 P. Leach 13 Microsoft 14 T. Berners-Lee 15 W3C/MIT 16 Y. Lafon, Ed. 17 W3C 18 J. Reschke, Ed. 19 greenbytes 20 November 16, 2008 22 HTTP/1.1, part 1: URIs, Connections, and Message Parsing 23 draft-ietf-httpbis-p1-messaging-05 25 Status of this Memo 27 By submitting this Internet-Draft, each author represents that any 28 applicable patent or other IPR claims of which he or she is aware 29 have been or will be disclosed, and any of which he or she becomes 30 aware will be disclosed, in accordance with Section 6 of BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF), its areas, and its working groups. Note that 34 other groups may also distribute working documents as Internet- 35 Drafts. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 The list of current Internet-Drafts can be accessed at 43 http://www.ietf.org/ietf/1id-abstracts.txt. 45 The list of Internet-Draft Shadow Directories can be accessed at 46 http://www.ietf.org/shadow.html. 48 This Internet-Draft will expire on May 20, 2009. 50 Abstract 52 The Hypertext Transfer Protocol (HTTP) is an application-level 53 protocol for distributed, collaborative, hypermedia information 54 systems. HTTP has been in use by the World Wide Web global 55 information initiative since 1990. This document is Part 1 of the 56 seven-part specification that defines the protocol referred to as 57 "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 1 provides 58 an overview of HTTP and its associated terminology, defines the 59 "http" and "https" Uniform Resource Identifier (URI) schemes, defines 60 the generic message syntax and parsing requirements for HTTP message 61 frames, and describes general security concerns for implementations. 63 Editorial Note (To be removed by RFC Editor) 65 Discussion of this draft should take place on the HTTPBIS working 66 group mailing list (ietf-http-wg@w3.org). The current issues list is 67 at and related 68 documents (including fancy diffs) can be found at 69 . 71 The changes in this draft are summarized in Appendix E.6. 73 Table of Contents 75 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 76 1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 5 77 1.2. Overall Operation . . . . . . . . . . . . . . . . . . . . 6 78 2. Notational Conventions and Generic Grammar . . . . . . . . . . 8 79 2.1. ABNF Extension: #rule . . . . . . . . . . . . . . . . . . 8 80 2.2. Basic Rules . . . . . . . . . . . . . . . . . . . . . . . 8 81 2.3. ABNF Rules defined in other Parts of the Specification . . 10 82 3. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 11 83 3.1. HTTP Version . . . . . . . . . . . . . . . . . . . . . . . 11 84 3.2. Uniform Resource Identifiers . . . . . . . . . . . . . . . 12 85 3.2.1. http URI scheme . . . . . . . . . . . . . . . . . . . 13 86 3.2.2. URI Comparison . . . . . . . . . . . . . . . . . . . . 13 87 3.3. Date/Time Formats . . . . . . . . . . . . . . . . . . . . 14 88 3.3.1. Full Date . . . . . . . . . . . . . . . . . . . . . . 14 89 3.4. Transfer Codings . . . . . . . . . . . . . . . . . . . . . 16 90 3.4.1. Chunked Transfer Coding . . . . . . . . . . . . . . . 17 91 3.5. Product Tokens . . . . . . . . . . . . . . . . . . . . . . 18 92 4. HTTP Message . . . . . . . . . . . . . . . . . . . . . . . . . 19 93 4.1. Message Types . . . . . . . . . . . . . . . . . . . . . . 19 94 4.2. Message Headers . . . . . . . . . . . . . . . . . . . . . 20 95 4.3. Message Body . . . . . . . . . . . . . . . . . . . . . . . 21 96 4.4. Message Length . . . . . . . . . . . . . . . . . . . . . . 22 97 4.5. General Header Fields . . . . . . . . . . . . . . . . . . 23 98 5. Request . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 99 5.1. Request-Line . . . . . . . . . . . . . . . . . . . . . . . 24 100 5.1.1. Method . . . . . . . . . . . . . . . . . . . . . . . . 24 101 5.1.2. Request-URI . . . . . . . . . . . . . . . . . . . . . 24 102 5.2. The Resource Identified by a Request . . . . . . . . . . . 26 103 6. Response . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 104 6.1. Status-Line . . . . . . . . . . . . . . . . . . . . . . . 27 105 6.1.1. Status Code and Reason Phrase . . . . . . . . . . . . 27 106 7. Connections . . . . . . . . . . . . . . . . . . . . . . . . . 27 107 7.1. Persistent Connections . . . . . . . . . . . . . . . . . . 28 108 7.1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . 28 109 7.1.2. Overall Operation . . . . . . . . . . . . . . . . . . 28 110 7.1.3. Proxy Servers . . . . . . . . . . . . . . . . . . . . 30 111 7.1.4. Practical Considerations . . . . . . . . . . . . . . . 30 112 7.2. Message Transmission Requirements . . . . . . . . . . . . 31 113 7.2.1. Persistent Connections and Flow Control . . . . . . . 31 114 7.2.2. Monitoring Connections for Error Status Messages . . . 31 115 7.2.3. Use of the 100 (Continue) Status . . . . . . . . . . . 32 116 7.2.4. Client Behavior if Server Prematurely Closes 117 Connection . . . . . . . . . . . . . . . . . . . . . . 34 118 8. Header Field Definitions . . . . . . . . . . . . . . . . . . . 34 119 8.1. Connection . . . . . . . . . . . . . . . . . . . . . . . . 35 120 8.2. Content-Length . . . . . . . . . . . . . . . . . . . . . . 36 121 8.3. Date . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 122 8.3.1. Clockless Origin Server Operation . . . . . . . . . . 37 123 8.4. Host . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 124 8.5. TE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 125 8.6. Trailer . . . . . . . . . . . . . . . . . . . . . . . . . 39 126 8.7. Transfer-Encoding . . . . . . . . . . . . . . . . . . . . 40 127 8.8. Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . 41 128 8.9. Via . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 129 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43 130 9.1. Message Header Registration . . . . . . . . . . . . . . . 43 131 9.2. URI Scheme Registration . . . . . . . . . . . . . . . . . 44 132 9.3. Internet Media Type Registrations . . . . . . . . . . . . 44 133 9.3.1. Internet Media Type message/http . . . . . . . . . . . 44 134 9.3.2. Internet Media Type application/http . . . . . . . . . 45 135 10. Security Considerations . . . . . . . . . . . . . . . . . . . 46 136 10.1. Personal Information . . . . . . . . . . . . . . . . . . . 47 137 10.2. Abuse of Server Log Information . . . . . . . . . . . . . 47 138 10.3. Attacks Based On File and Path Names . . . . . . . . . . . 47 139 10.4. DNS Spoofing . . . . . . . . . . . . . . . . . . . . . . . 47 140 10.5. Proxies and Caching . . . . . . . . . . . . . . . . . . . 48 141 10.6. Denial of Service Attacks on Proxies . . . . . . . . . . . 49 142 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 49 143 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 50 144 12.1. Normative References . . . . . . . . . . . . . . . . . . . 50 145 12.2. Informative References . . . . . . . . . . . . . . . . . . 51 146 Appendix A. Tolerant Applications . . . . . . . . . . . . . . . . 53 147 Appendix B. Conversion of Date Formats . . . . . . . . . . . . . 54 148 Appendix C. Compatibility with Previous Versions . . . . . . . . 54 149 C.1. Changes from HTTP/1.0 . . . . . . . . . . . . . . . . . . 55 150 C.1.1. Changes to Simplify Multi-homed Web Servers and 151 Conserve IP Addresses . . . . . . . . . . . . . . . . 55 152 C.2. Compatibility with HTTP/1.0 Persistent Connections . . . . 56 153 C.3. Changes from RFC 2068 . . . . . . . . . . . . . . . . . . 57 154 C.4. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 57 155 Appendix D. Terminology . . . . . . . . . . . . . . . . . . . . . 58 156 Appendix E. Change Log (to be removed by RFC Editor before 157 publication) . . . . . . . . . . . . . . . . . . . . 61 158 E.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 61 159 E.2. Since draft-ietf-httpbis-p1-messaging-00 . . . . . . . . . 61 160 E.3. Since draft-ietf-httpbis-p1-messaging-01 . . . . . . . . . 62 161 E.4. Since draft-ietf-httpbis-p1-messaging-02 . . . . . . . . . 63 162 E.5. Since draft-ietf-httpbis-p1-messaging-03 . . . . . . . . . 64 163 E.6. Since draft-ietf-httpbis-p1-messaging-04 . . . . . . . . . 64 164 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 165 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 69 166 Intellectual Property and Copyright Statements . . . . . . . . . . 72 168 1. Introduction 170 The Hypertext Transfer Protocol (HTTP) is an application-level 171 request/response protocol that uses extensible semantics and MIME- 172 like message payloads for flexible interaction with network-based 173 hypermedia information systems. HTTP relies upon the Uniform 174 Resource Identifier (URI) standard [RFC3986] to indicate resource 175 targets for interaction and to identify other resources. Messages 176 are passed in a format similar to that used by Internet mail 177 [RFC5322] and the Multipurpose Internet Mail Extensions (MIME) 178 [RFC2045] (see Appendix A of [Part3] for the differences between HTTP 179 and MIME messages). 181 HTTP is also designed for use as a generic protocol for translating 182 communication to and from other Internet information systems, such as 183 USENET news services via NNTP [RFC3977], file services via FTP 184 [RFC959], Gopher [RFC1436], and WAIS [WAIS]. HTTP proxies and 185 gateways provide access to alternative information services by 186 translating their diverse protocols into a hypermedia format that can 187 be viewed and manipulated by clients in the same way as HTTP 188 services. 190 This document is Part 1 of the seven-part specification of HTTP, 191 defining the protocol referred to as "HTTP/1.1" and obsoleting 192 [RFC2616]. Part 1 defines how clients determine when to use HTTP, 193 the URI schemes specific to HTTP-based resources, overall network 194 operation with transport protocol connection management, and HTTP 195 message framing. Our goal is to define all of the mechanisms 196 necessary for HTTP message handling that are independent of message 197 semantics, thereby defining the complete set of requirements for an 198 HTTP message relay or generic message parser. 200 1.1. Requirements 202 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 203 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 204 document are to be interpreted as described in [RFC2119]. 206 An implementation is not compliant if it fails to satisfy one or more 207 of the MUST or REQUIRED level requirements for the protocols it 208 implements. An implementation that satisfies all the MUST or 209 REQUIRED level and all the SHOULD level requirements for its 210 protocols is said to be "unconditionally compliant"; one that 211 satisfies all the MUST level requirements but not all the SHOULD 212 level requirements for its protocols is said to be "conditionally 213 compliant." 215 1.2. Overall Operation 217 HTTP is a request/response protocol. A client sends a request to the 218 server in the form of a request method, URI, and protocol version, 219 followed by a MIME-like message containing request modifiers, client 220 information, and possible body content over a connection with a 221 server. The server responds with a status line, including the 222 message's protocol version and a success or error code, followed by a 223 MIME-like message containing server information, entity 224 metainformation, and possible entity-body content. The relationship 225 between HTTP and MIME is described in Appendix A of [Part3]. 227 Most HTTP communication is initiated by a user agent and consists of 228 a request to be applied to a resource on some origin server. In the 229 simplest case, this may be accomplished via a single connection (v) 230 between the user agent (UA) and the origin server (O). 232 request chain ------------------------> 233 UA -------------------v------------------- O 234 <----------------------- response chain 236 A more complicated situation occurs when one or more intermediaries 237 are present in the request/response chain. There are three common 238 forms of intermediary: proxy, gateway, and tunnel. A proxy is a 239 forwarding agent, receiving requests for a URI in its absolute form, 240 rewriting all or part of the message, and forwarding the reformatted 241 request toward the server identified by the URI. A gateway is a 242 receiving agent, acting as a layer above some other server(s) and, if 243 necessary, translating the requests to the underlying server's 244 protocol. A tunnel acts as a relay point between two connections 245 without changing the messages; tunnels are used when the 246 communication needs to pass through an intermediary (such as a 247 firewall) even when the intermediary cannot understand the contents 248 of the messages. 250 request chain --------------------------------------> 251 UA -----v----- A -----v----- B -----v----- C -----v----- O 252 <------------------------------------- response chain 254 The figure above shows three intermediaries (A, B, and C) between the 255 user agent and origin server. A request or response message that 256 travels the whole chain will pass through four separate connections. 257 This distinction is important because some HTTP communication options 258 may apply only to the connection with the nearest, non-tunnel 259 neighbor, only to the end-points of the chain, or to all connections 260 along the chain. Although the diagram is linear, each participant 261 may be engaged in multiple, simultaneous communications. For 262 example, B may be receiving requests from many clients other than A, 263 and/or forwarding requests to servers other than C, at the same time 264 that it is handling A's request. 266 Any party to the communication which is not acting as a tunnel may 267 employ an internal cache for handling requests. The effect of a 268 cache is that the request/response chain is shortened if one of the 269 participants along the chain has a cached response applicable to that 270 request. The following illustrates the resulting chain if B has a 271 cached copy of an earlier response from O (via C) for a request which 272 has not been cached by UA or A. 274 request chain ----------> 275 UA -----v----- A -----v----- B - - - - - - C - - - - - - O 276 <--------- response chain 278 Not all responses are usefully cacheable, and some requests may 279 contain modifiers which place special requirements on cache behavior. 280 HTTP requirements for cache behavior and cacheable responses are 281 defined in Section 1 of [Part6]. 283 In fact, there are a wide variety of architectures and configurations 284 of caches and proxies currently being experimented with or deployed 285 across the World Wide Web. These systems include national hierarchies 286 of proxy caches to save transoceanic bandwidth, systems that 287 broadcast or multicast cache entries, organizations that distribute 288 subsets of cached data via CD-ROM, and so on. HTTP systems are used 289 in corporate intranets over high-bandwidth links, and for access via 290 PDAs with low-power radio links and intermittent connectivity. The 291 goal of HTTP/1.1 is to support the wide diversity of configurations 292 already deployed while introducing protocol constructs that meet the 293 needs of those who build web applications that require high 294 reliability and, failing that, at least reliable indications of 295 failure. 297 HTTP communication usually takes place over TCP/IP connections. The 298 default port is TCP 80 299 (), but other ports can 300 be used. This does not preclude HTTP from being implemented on top 301 of any other protocol on the Internet, or on other networks. HTTP 302 only presumes a reliable transport; any protocol that provides such 303 guarantees can be used; the mapping of the HTTP/1.1 request and 304 response structures onto the transport data units of the protocol in 305 question is outside the scope of this specification. 307 In HTTP/1.0, most implementations used a new connection for each 308 request/response exchange. In HTTP/1.1, a connection may be used for 309 one or more request/response exchanges, although connections may be 310 closed for a variety of reasons (see Section 7.1). 312 2. Notational Conventions and Generic Grammar 314 2.1. ABNF Extension: #rule 316 One extension to the ABNF rules of [RFC5234] is used to improve 317 readability. 319 A construct "#" is defined, similar to "*", for defining lists of 320 elements. The full form is "#element" indicating at least 321 and at most elements, each separated by one or more commas (",") 322 and OPTIONAL linear white space (OWS). This makes the usual form of 323 lists very easy; a rule such as 325 ( *OWS element *( *OWS "," *OWS element )) 327 can be shown as 329 1#element 331 Wherever this construct is used, null elements are allowed, but do 332 not contribute to the count of elements present. That is, 333 "(element), , (element) " is permitted, but counts as only two 334 elements. Therefore, where at least one element is required, at 335 least one non-null element MUST be present. Default values are 0 and 336 infinity so that "#element" allows any number, including zero; 337 "1#element" requires at least one; and "1#2element" allows one or 338 two. 340 [[abnf.list: At a later point of time, we may want to add an appendix 341 containing the whole ABNF, with the list rules expanded to strict RFC 342 5234 notation.]] 344 2.2. Basic Rules 346 This specification uses the Augmented Backus-Naur Form (ABNF) 347 notation of [RFC5234]. The following core rules are included by 348 reference, as defined in [RFC5234], Appendix B.1: ALPHA (letters), 349 CHAR (any [USASCII] character, excluding NUL), CR (carriage return), 350 CRLF (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double 351 quote), HEXDIG (hexadecimal 0-9/A-F/a-f), HTAB (horizontal tab), LF 352 (line feed), OCTET (any 8-bit sequence of data), SP (space) and WSP 353 (white space). 355 HTTP/1.1 defines the sequence CR LF as the end-of-line marker for all 356 protocol elements except the entity-body (see Appendix A for tolerant 357 applications). The end-of-line marker within an entity-body is 358 defined by its associated media type, as described in Section 3.3 of 359 [Part3]. 361 All linear white space (LWS) in header field-values has the same 362 semantics as SP. A recipient MAY replace any such linear white space 363 with a single SP before interpreting the field value or forwarding 364 the message downstream. 366 Historically, HTTP/1.1 header field values allow linear white space 367 folding across multiple lines. However, this specification 368 deprecates its use; senders MUST NOT produce messages that include 369 LWS folding (i.e., use the obs-fold rule), except within the message/ 370 http media type (Section 9.3.1). Receivers SHOULD still parse folded 371 linear white space. 373 This specification uses three rules to denote the use of linear white 374 space; BWS ("Bad" White Space), OWS (Optional White Space), and RWS 375 (Required White Space). 377 "Bad" white space is allowed by the BNF, but senders SHOULD NOT 378 produce it in messages. Receivers MUST accept it in incoming 379 messages. 381 Required white space is used when at least one linear white space 382 character is required to separate field tokens. In all such cases, a 383 single SP character SHOULD be used. 385 OWS = *( [ obs-fold ] WSP ) 386 ; "optional" white space 387 RWS = 1*( [ obs-fold ] WSP ) 388 ; "required" white space 389 BWS = OWS 390 ; "bad" white space 391 obs-fold = CRLF 393 The TEXT rule is only used for descriptive field contents and values 394 that are not intended to be interpreted by the message parser. Words 395 of *TEXT MAY contain characters from character sets other than ISO- 396 8859-1 [ISO-8859-1] only when encoded according to the rules of 397 [RFC2047]. 399 TEXT = %x20-7E / %x80-FF / OWS 400 ; any OCTET except CTLs, but including OWS 402 A CRLF is allowed in the definition of TEXT only as part of a header 403 field continuation. It is expected that the folding LWS will be 404 replaced with a single SP before interpretation of the TEXT value. 406 Many HTTP/1.1 header field values consist of words separated by LWS 407 or special characters. These special characters MUST be in a quoted 408 string to be used within a parameter value (as defined in 409 Section 3.4). 411 tchar = "!" / "#" / "$" / "%" / "&" / "'" / "*" 412 / "+" / "-" / "." / "^" / "_" / "`" / "|" / "~" 413 / DIGIT / ALPHA 415 token = 1*tchar 417 Comments can be included in some HTTP header fields by surrounding 418 the comment text with parentheses. Comments are only allowed in 419 fields containing "comment" as part of their field value definition. 420 In all other fields, parentheses are considered part of the field 421 value. 423 comment = "(" *( ctext / quoted-pair / comment ) ")" 424 ctext = 426 A string of text is parsed as a single word if it is quoted using 427 double-quote marks. 429 quoted-string = DQUOTE *(qdtext / quoted-pair ) DQUOTE 430 qdtext = 432 The backslash character ("\") MAY be used as a single-character 433 quoting mechanism only within quoted-string and comment constructs. 435 quoted-text = %x01-09 / 436 %x0B-0C / 437 %x0E-FF ; Characters excluding NUL, CR and LF 438 quoted-pair = "\" quoted-text 440 2.3. ABNF Rules defined in other Parts of the Specification 442 The ABNF rules below are defined in other parts: 444 request-header = 445 response-header = 447 accept-params = 448 entity-body = 449 entity-header = 451 Cache-Control = 452 Pragma = 453 Warning = 455 3. Protocol Parameters 457 3.1. HTTP Version 459 HTTP uses a "." numbering scheme to indicate versions 460 of the protocol. The protocol versioning policy is intended to allow 461 the sender to indicate the format of a message and its capacity for 462 understanding further HTTP communication, rather than the features 463 obtained via that communication. No change is made to the version 464 number for the addition of message components which do not affect 465 communication behavior or which only add to extensible field values. 466 The number is incremented when the changes made to the 467 protocol add features which do not change the general message parsing 468 algorithm, but which may add to the message semantics and imply 469 additional capabilities of the sender. The number is 470 incremented when the format of a message within the protocol is 471 changed. See [RFC2145] for a fuller explanation. 473 The version of an HTTP message is indicated by an HTTP-Version field 474 in the first line of the message. HTTP-Version is case-sensitive. 476 HTTP-Version = HTTP-Prot-Name "/" 1*DIGIT "." 1*DIGIT 477 HTTP-Prot-Name = %x48.54.54.50 ; "HTTP", case-sensitive 479 Note that the major and minor numbers MUST be treated as separate 480 integers and that each MAY be incremented higher than a single digit. 481 Thus, HTTP/2.4 is a lower version than HTTP/2.13, which in turn is 482 lower than HTTP/12.3. Leading zeros MUST be ignored by recipients 483 and MUST NOT be sent. 485 An application that sends a request or response message that includes 486 HTTP-Version of "HTTP/1.1" MUST be at least conditionally compliant 487 with this specification. Applications that are at least 488 conditionally compliant with this specification SHOULD use an HTTP- 489 Version of "HTTP/1.1" in their messages, and MUST do so for any 490 message that is not compatible with HTTP/1.0. For more details on 491 when to send specific HTTP-Version values, see [RFC2145]. 493 The HTTP version of an application is the highest HTTP version for 494 which the application is at least conditionally compliant. 496 Proxy and gateway applications need to be careful when forwarding 497 messages in protocol versions different from that of the application. 498 Since the protocol version indicates the protocol capability of the 499 sender, a proxy/gateway MUST NOT send a message with a version 500 indicator which is greater than its actual version. If a higher 501 version request is received, the proxy/gateway MUST either downgrade 502 the request version, or respond with an error, or switch to tunnel 503 behavior. 505 Due to interoperability problems with HTTP/1.0 proxies discovered 506 since the publication of [RFC2068], caching proxies MUST, gateways 507 MAY, and tunnels MUST NOT upgrade the request to the highest version 508 they support. The proxy/gateway's response to that request MUST be 509 in the same major version as the request. 511 Note: Converting between versions of HTTP may involve modification 512 of header fields required or forbidden by the versions involved. 514 3.2. Uniform Resource Identifiers 516 Uniform Resource Identifiers (URIs) [RFC3986] are used in HTTP to 517 indicate the target of a request and to identify additional resources 518 related to that resource, the request, or the response. Each 519 protocol element in HTTP that allows a URI reference will indicate in 520 its ABNF whether the element allows only a URI in absolute form, any 521 relative reference, or some limited subset of the URI-reference 522 grammar. Unless otherwise indicated, relative URI references are to 523 be parsed relative to the URI corresponding to the request target 524 (the base URI). 526 This specification adopts the definitions of "URI-reference", 527 "absolute-URI", "fragment", "port", "host", "path-abempty", "path- 528 absolute", "query", and "authority" from [RFC3986]: 530 absolute-URI = 531 authority = 532 fragment = 533 path-abempty = 534 path-absolute = 535 port = 536 query = 537 uri-host = 539 relative-part = 540 relativeURI = relative-part [ "?" query ] 542 HTTP does not place an a priori limit on the length of a URI. 543 Servers MUST be able to handle the URI of any resource they serve, 544 and SHOULD be able to handle URIs of unbounded length if they provide 545 GET-based forms that could generate such URIs. A server SHOULD 546 return 414 (Request-URI Too Long) status if a URI is longer than the 547 server can handle (see Section 9.4.15 of [Part2]). 549 Note: Servers ought to be cautious about depending on URI lengths 550 above 255 bytes, because some older client or proxy 551 implementations might not properly support these lengths. 553 3.2.1. http URI scheme 555 The "http" scheme is used to locate network resources via the HTTP 556 protocol. This section defines the syntax and semantics for 557 identifiers using the http or https URI schemes. 559 http-URI = "http:" "//" authority path-abempty [ "?" query ] 561 If the port is empty or not given, port 80 is assumed. The semantics 562 are that the identified resource is located at the server listening 563 for TCP connections on that port of that host, and the Request-URI 564 for the resource is path-absolute (Section 5.1.2). The use of IP 565 addresses in URLs SHOULD be avoided whenever possible (see 566 [RFC1900]). If the path-absolute is not present in the URL, it MUST 567 be given as "/" when used as a Request-URI for a resource 568 (Section 5.1.2). If a proxy receives a host name which is not a 569 fully qualified domain name, it MAY add its domain to the host name 570 it received. If a proxy receives a fully qualified domain name, the 571 proxy MUST NOT change the host name. 573 Note: the "https" scheme is defined in [RFC2818]. 575 3.2.2. URI Comparison 577 When comparing two URIs to decide if they match or not, a client 578 SHOULD use a case-sensitive octet-by-octet comparison of the entire 579 URIs, with these exceptions: 581 o A port that is empty or not given is equivalent to the default 582 port for that URI-reference; 584 o Comparisons of host names MUST be case-insensitive; 586 o Comparisons of scheme names MUST be case-insensitive; 588 o An empty path-absolute is equivalent to an path-absolute of "/". 590 Characters other than those in the "reserved" set (see [RFC3986], 591 Section 2.2) are equivalent to their ""%" HEXDIG HEXDIG" encoding. 593 For example, the following three URIs are equivalent: 595 http://example.com:80/~smith/home.html 596 http://EXAMPLE.com/%7Esmith/home.html 597 http://EXAMPLE.com:/%7esmith/home.html 599 3.3. Date/Time Formats 601 3.3.1. Full Date 603 HTTP applications have historically allowed three different formats 604 for the representation of date/time stamps: 606 Sun, 06 Nov 1994 08:49:37 GMT ; RFC 822, updated by RFC 1123 607 Sunday, 06-Nov-94 08:49:37 GMT ; obsolete RFC 850 format 608 Sun Nov 6 08:49:37 1994 ; ANSI C's asctime() format 610 The first format is preferred as an Internet standard and represents 611 a fixed-length subset of that defined by [RFC1123] (an update to 612 [RFC822]). The other formats are described here only for 613 compatibility with obsolete implementations. HTTP/1.1 clients and 614 servers that parse the date value MUST accept all three formats (for 615 compatibility with HTTP/1.0), though they MUST only generate the RFC 616 1123 format for representing HTTP-date values in header fields. See 617 Appendix A for further information. 619 Note: Recipients of date values are encouraged to be robust in 620 accepting date values that may have been sent by non-HTTP 621 applications, as is sometimes the case when retrieving or posting 622 messages via proxies/gateways to SMTP or NNTP. 624 All HTTP date/time stamps MUST be represented in Greenwich Mean Time 625 (GMT), without exception. For the purposes of HTTP, GMT is exactly 626 equal to UTC (Coordinated Universal Time). This is indicated in the 627 first two formats by the inclusion of "GMT" as the three-letter 628 abbreviation for time zone, and MUST be assumed when reading the 629 asctime format. HTTP-date is case sensitive and MUST NOT include 630 additional LWS beyond that specifically included as SP in the 631 grammar. 633 HTTP-date = rfc1123-date / obsolete-date 634 obsolete-date = rfc850-date / asctime-date 635 rfc1123-date = wkday "," SP date1 SP time SP GMT 636 rfc850-date = weekday "," SP date2 SP time SP GMT 637 asctime-date = wkday SP date3 SP time SP 4DIGIT 638 date1 = 2DIGIT SP month SP 4DIGIT 639 ; day month year (e.g., 02 Jun 1982) 640 date2 = 2DIGIT "-" month "-" 2DIGIT 641 ; day-month-year (e.g., 02-Jun-82) 642 date3 = month SP ( 2DIGIT / ( SP 1DIGIT )) 643 ; month day (e.g., Jun 2) 644 time = 2DIGIT ":" 2DIGIT ":" 2DIGIT 645 ; 00:00:00 - 23:59:59 646 wkday = s-Mon / s-Tue / s-Wed 647 / s-Thu / s-Fri / s-Sat / s-Sun 648 weekday = l-Mon / l-Tue / l-Wed 649 / l-Thu / l-Fri / l-Sat / l-Sun 650 month = s-Jan / s-Feb / s-Mar / s-Apr 651 / s-May / s-Jun / s-Jul / s-Aug 652 / s-Sep / s-Oct / s-Nov / s-Dec 654 GMT = %x47.4D.54 ; "GMT", case-sensitive 656 s-Mon = %x4D.6F.6E ; "Mon", case-sensitive 657 s-Tue = %x54.75.65 ; "Tue", case-sensitive 658 s-Wed = %x57.65.64 ; "Wed", case-sensitive 659 s-Thu = %x54.68.75 ; "Thu", case-sensitive 660 s-Fri = %x46.72.69 ; "Fri", case-sensitive 661 s-Sat = %x53.61.74 ; "Sat", case-sensitive 662 s-Sun = %x53.75.6E ; "Sun", case-sensitive 664 l-Mon = %x4D.6F.6E.64.61.79 ; "Monday", case-sensitive 665 l-Tue = %x54.75.65.73.64.61.79 ; "Tuesday", case-sensitive 666 l-Wed = %x57.65.64.6E.65.73.64.61.79 ; "Wednesday", case-sensitive 667 l-Thu = %x54.68.75.72.73.64.61.79 ; "Thursday", case-sensitive 668 l-Fri = %x46.72.69.64.61.79 ; "Friday", case-sensitive 669 l-Sat = %x53.61.74.75.72.64.61.79 ; "Saturday", case-sensitive 670 l-Sun = %x53.75.6E.64.61.79 ; "Sunday", case-sensitive 672 s-Jan = %x4A.61.6E ; "Jan", case-sensitive 673 s-Feb = %x46.65.62 ; "Feb", case-sensitive 674 s-Mar = %x4D.61.72 ; "Mar", case-sensitive 675 s-Apr = %x41.70.72 ; "Apr", case-sensitive 676 s-May = %x4D.61.79 ; "May", case-sensitive 677 s-Jun = %x4A.75.6E ; "Jun", case-sensitive 678 s-Jul = %x4A.75.6C ; "Jul", case-sensitive 679 s-Aug = %x41.75.67 ; "Aug", case-sensitive 680 s-Sep = %x53.65.70 ; "Sep", case-sensitive 681 s-Oct = %x4F.63.74 ; "Oct", case-sensitive 682 s-Nov = %x4E.6F.76 ; "Nov", case-sensitive 683 s-Dec = %x44.65.63 ; "Dec", case-sensitive 685 Note: HTTP requirements for the date/time stamp format apply only to 686 their usage within the protocol stream. Clients and servers are not 687 required to use these formats for user presentation, request logging, 688 etc. 690 3.4. Transfer Codings 692 Transfer-coding values are used to indicate an encoding 693 transformation that has been, can be, or may need to be applied to an 694 entity-body in order to ensure "safe transport" through the network. 695 This differs from a content coding in that the transfer-coding is a 696 property of the message, not of the original entity. 698 transfer-coding = "chunked" / transfer-extension 699 transfer-extension = token *( OWS ";" OWS parameter ) 701 Parameters are in the form of attribute/value pairs. 703 parameter = attribute BWS "=" BWS value 704 attribute = token 705 value = token / quoted-string 707 All transfer-coding values are case-insensitive. HTTP/1.1 uses 708 transfer-coding values in the TE header field (Section 8.5) and in 709 the Transfer-Encoding header field (Section 8.7). 711 Whenever a transfer-coding is applied to a message-body, the set of 712 transfer-codings MUST include "chunked", unless the message indicates 713 it is terminated by closing the connection. When the "chunked" 714 transfer-coding is used, it MUST be the last transfer-coding applied 715 to the message-body. The "chunked" transfer-coding MUST NOT be 716 applied more than once to a message-body. These rules allow the 717 recipient to determine the transfer-length of the message 718 (Section 4.4). 720 Transfer-codings are analogous to the Content-Transfer-Encoding 721 values of MIME [RFC2045], which were designed to enable safe 722 transport of binary data over a 7-bit transport service. However, 723 safe transport has a different focus for an 8bit-clean transfer 724 protocol. In HTTP, the only unsafe characteristic of message-bodies 725 is the difficulty in determining the exact body length (Section 4.4), 726 or the desire to encrypt data over a shared transport. 728 The Internet Assigned Numbers Authority (IANA) acts as a registry for 729 transfer-coding value tokens. Initially, the registry contains the 730 following tokens: "chunked" (Section 3.4.1), "gzip", "compress", and 731 "deflate" (Section 3.2 of [Part3]). 733 New transfer-coding value tokens SHOULD be registered in the same way 734 as new content-coding value tokens (Section 3.2 of [Part3]). 736 A server which receives an entity-body with a transfer-coding it does 737 not understand SHOULD return 501 (Not Implemented), and close the 738 connection. A server MUST NOT send transfer-codings to an HTTP/1.0 739 client. 741 3.4.1. Chunked Transfer Coding 743 The chunked encoding modifies the body of a message in order to 744 transfer it as a series of chunks, each with its own size indicator, 745 followed by an OPTIONAL trailer containing entity-header fields. 746 This allows dynamically produced content to be transferred along with 747 the information necessary for the recipient to verify that it has 748 received the full message. 750 Chunked-Body = *chunk 751 last-chunk 752 trailer-part 753 CRLF 755 chunk = chunk-size *WSP [ chunk-ext ] CRLF 756 chunk-data CRLF 757 chunk-size = 1*HEXDIG 758 last-chunk = 1*("0") *WSP [ chunk-ext ] CRLF 760 chunk-ext = *( ";" *WSP chunk-ext-name 761 [ "=" chunk-ext-val ] *WSP ) 762 chunk-ext-name = token 763 chunk-ext-val = token / quoted-string 764 chunk-data = 1*OCTET ; a sequence of chunk-size octets 765 trailer-part = *(entity-header CRLF) 767 The chunk-size field is a string of hex digits indicating the size of 768 the chunk-data in octets. The chunked encoding is ended by any chunk 769 whose size is zero, followed by the trailer, which is terminated by 770 an empty line. 772 The trailer allows the sender to include additional HTTP header 773 fields at the end of the message. The Trailer header field can be 774 used to indicate which header fields are included in a trailer (see 775 Section 8.6). 777 A server using chunked transfer-coding in a response MUST NOT use the 778 trailer for any header fields unless at least one of the following is 779 true: 781 1. the request included a TE header field that indicates "trailers" 782 is acceptable in the transfer-coding of the response, as 783 described in Section 8.5; or, 785 2. the server is the origin server for the response, the trailer 786 fields consist entirely of optional metadata, and the recipient 787 could use the message (in a manner acceptable to the origin 788 server) without receiving this metadata. In other words, the 789 origin server is willing to accept the possibility that the 790 trailer fields might be silently discarded along the path to the 791 client. 793 This requirement prevents an interoperability failure when the 794 message is being received by an HTTP/1.1 (or later) proxy and 795 forwarded to an HTTP/1.0 recipient. It avoids a situation where 796 compliance with the protocol would have necessitated a possibly 797 infinite buffer on the proxy. 799 A process for decoding the "chunked" transfer-coding can be 800 represented in pseudo-code as: 802 length := 0 803 read chunk-size, chunk-ext (if any) and CRLF 804 while (chunk-size > 0) { 805 read chunk-data and CRLF 806 append chunk-data to entity-body 807 length := length + chunk-size 808 read chunk-size and CRLF 809 } 810 read entity-header 811 while (entity-header not empty) { 812 append entity-header to existing header fields 813 read entity-header 814 } 815 Content-Length := length 816 Remove "chunked" from Transfer-Encoding 818 All HTTP/1.1 applications MUST be able to receive and decode the 819 "chunked" transfer-coding, and MUST ignore chunk-ext extensions they 820 do not understand. 822 3.5. Product Tokens 824 Product tokens are used to allow communicating applications to 825 identify themselves by software name and version. Most fields using 826 product tokens also allow sub-products which form a significant part 827 of the application to be listed, separated by white space. By 828 convention, the products are listed in order of their significance 829 for identifying the application. 831 product = token ["/" product-version] 832 product-version = token 834 Examples: 836 User-Agent: CERN-LineMode/2.15 libwww/2.17b3 837 Server: Apache/0.8.4 839 Product tokens SHOULD be short and to the point. They MUST NOT be 840 used for advertising or other non-essential information. Although 841 any token character MAY appear in a product-version, this token 842 SHOULD only be used for a version identifier (i.e., successive 843 versions of the same product SHOULD only differ in the product- 844 version portion of the product value). 846 4. HTTP Message 848 4.1. Message Types 850 HTTP messages consist of requests from client to server and responses 851 from server to client. 853 HTTP-message = Request / Response ; HTTP/1.1 messages 855 Request (Section 5) and Response (Section 6) messages use the generic 856 message format of [RFC5322] for transferring entities (the payload of 857 the message). Both types of message consist of a start-line, zero or 858 more header fields (also known as "headers"), an empty line (i.e., a 859 line with nothing preceding the CRLF) indicating the end of the 860 header fields, and possibly a message-body. 862 generic-message = start-line 863 *(message-header CRLF) 864 CRLF 865 [ message-body ] 866 start-line = Request-Line / Status-Line 868 In the interest of robustness, servers SHOULD ignore any empty 869 line(s) received where a Request-Line is expected. In other words, 870 if the server is reading the protocol stream at the beginning of a 871 message and receives a CRLF first, it should ignore the CRLF. 873 Certain buggy HTTP/1.0 client implementations generate extra CRLF's 874 after a POST request. To restate what is explicitly forbidden by the 875 BNF, an HTTP/1.1 client MUST NOT preface or follow a request with an 876 extra CRLF. 878 4.2. Message Headers 880 HTTP header fields, which include general-header (Section 4.5), 881 request-header (Section 4 of [Part2]), response-header (Section 6 of 882 [Part2]), and entity-header (Section 4.1 of [Part3]) fields, follow 883 the same generic format as that given in Section 2.1 of [RFC5322]. 884 Each header field consists of a name followed by a colon (":") and 885 the field value. Field names are case-insensitive. The field value 886 MAY be preceded by any amount of LWS, though a single SP is 887 preferred. Header fields can be extended over multiple lines by 888 preceding each extra line with at least one SP or HTAB. Applications 889 ought to follow "common form", where one is known or indicated, when 890 generating HTTP constructs, since there might exist some 891 implementations that fail to accept anything beyond the common forms. 893 message-header = field-name ":" [ field-value ] 894 field-name = token 895 field-value = *( field-content / OWS ) 896 field-content = 898 [[anchor1: whitespace between field-name and colon is an error and 899 MUST NOT be accepted]] 901 The field-content does not include any leading or trailing LWS: 902 linear white space occurring before the first non-whitespace 903 character of the field-value or after the last non-whitespace 904 character of the field-value. Such leading or trailing LWS MAY be 905 removed without changing the semantics of the field value. Any LWS 906 that occurs between field-content MAY be replaced with a single SP 907 before interpreting the field value or forwarding the message 908 downstream. 910 The order in which header fields with differing field names are 911 received is not significant. However, it is "good practice" to send 912 general-header fields first, followed by request-header or response- 913 header fields, and ending with the entity-header fields. 915 Multiple message-header fields with the same field-name MAY be 916 present in a message if and only if the entire field-value for that 917 header field is defined as a comma-separated list [i.e., #(values)]. 918 It MUST be possible to combine the multiple header fields into one 919 "field-name: field-value" pair, without changing the semantics of the 920 message, by appending each subsequent field-value to the first, each 921 separated by a comma. The order in which header fields with the same 922 field-name are received is therefore significant to the 923 interpretation of the combined field value, and thus a proxy MUST NOT 924 change the order of these field values when a message is forwarded. 926 Note: the "Set-Cookie" header as implemented in practice (as 927 opposed to how it is specified in [RFC2109]) can occur multiple 928 times, but does not use the list syntax, and thus cannot be 929 combined into a single line. (See Appendix A.2.3 of [Kri2001] for 930 details.) Also note that the Set-Cookie2 header specified in 931 [RFC2965] does not share this problem. 933 4.3. Message Body 935 The message-body (if any) of an HTTP message is used to carry the 936 entity-body associated with the request or response. The message- 937 body differs from the entity-body only when a transfer-coding has 938 been applied, as indicated by the Transfer-Encoding header field 939 (Section 8.7). 941 message-body = entity-body 942 / 944 Transfer-Encoding MUST be used to indicate any transfer-codings 945 applied by an application to ensure safe and proper transfer of the 946 message. Transfer-Encoding is a property of the message, not of the 947 entity, and thus MAY be added or removed by any application along the 948 request/response chain. (However, Section 3.4 places restrictions on 949 when certain transfer-codings may be used.) 951 The rules for when a message-body is allowed in a message differ for 952 requests and responses. 954 The presence of a message-body in a request is signaled by the 955 inclusion of a Content-Length or Transfer-Encoding header field in 956 the request's message-headers. A message-body MUST NOT be included 957 in a request if the specification of the request method (Section 3 of 958 [Part2]) explicitly disallows an entity-body in requests. When a 959 request message contains both a message-body of non-zero length and a 960 method that does not define any semantics for that request message- 961 body, then an origin server SHOULD either ignore the message-body or 962 respond with an appropriate error message (e.g., 413). A proxy or 963 gateway, when presented the same request, SHOULD either forward the 964 request inbound with the message-body or ignore the message-body when 965 determining a response. 967 For response messages, whether or not a message-body is included with 968 a message is dependent on both the request method and the response 969 status code (Section 6.1.1). All responses to the HEAD request 970 method MUST NOT include a message-body, even though the presence of 971 entity-header fields might lead one to believe they do. All 1xx 972 (informational), 204 (No Content), and 304 (Not Modified) responses 973 MUST NOT include a message-body. All other responses do include a 974 message-body, although it MAY be of zero length. 976 4.4. Message Length 978 The transfer-length of a message is the length of the message-body as 979 it appears in the message; that is, after any transfer-codings have 980 been applied. When a message-body is included with a message, the 981 transfer-length of that body is determined by one of the following 982 (in order of precedence): 984 1. Any response message which "MUST NOT" include a message-body 985 (such as the 1xx, 204, and 304 responses and any response to a 986 HEAD request) is always terminated by the first empty line after 987 the header fields, regardless of the entity-header fields present 988 in the message. 990 2. If a Transfer-Encoding header field (Section 8.7) is present and 991 the "chunked" transfer-coding (Section 3.4) is used, the 992 transfer-length is defined by the use of this transfer-coding. 993 If a Transfer-Encoding header field is present and the "chunked" 994 transfer-coding is not present, the transfer-length is defined by 995 the sender closing the connection. 997 3. If a Content-Length header field (Section 8.2) is present, its 998 decimal value in OCTETs represents both the entity-length and the 999 transfer-length. The Content-Length header field MUST NOT be 1000 sent if these two lengths are different (i.e., if a Transfer- 1001 Encoding header field is present). If a message is received with 1002 both a Transfer-Encoding header field and a Content-Length header 1003 field, the latter MUST be ignored. 1005 4. If the message uses the media type "multipart/byteranges", and 1006 the transfer-length is not otherwise specified, then this self- 1007 delimiting media type defines the transfer-length. This media 1008 type MUST NOT be used unless the sender knows that the recipient 1009 can parse it; the presence in a request of a Range header with 1010 multiple byte-range specifiers from a 1.1 client implies that the 1011 client can parse multipart/byteranges responses. 1013 A range header might be forwarded by a 1.0 proxy that does not 1014 understand multipart/byteranges; in this case the server MUST 1015 delimit the message using methods defined in items 1, 3 or 5 1016 of this section. 1018 5. By the server closing the connection. (Closing the connection 1019 cannot be used to indicate the end of a request body, since that 1020 would leave no possibility for the server to send back a 1021 response.) 1023 For compatibility with HTTP/1.0 applications, HTTP/1.1 requests 1024 containing a message-body MUST include a valid Content-Length header 1025 field unless the server is known to be HTTP/1.1 compliant. If a 1026 request contains a message-body and a Content-Length is not given, 1027 the server SHOULD respond with 400 (Bad Request) if it cannot 1028 determine the length of the message, or with 411 (Length Required) if 1029 it wishes to insist on receiving a valid Content-Length. 1031 All HTTP/1.1 applications that receive entities MUST accept the 1032 "chunked" transfer-coding (Section 3.4), thus allowing this mechanism 1033 to be used for messages when the message length cannot be determined 1034 in advance. 1036 Messages MUST NOT include both a Content-Length header field and a 1037 transfer-coding. If the message does include a transfer-coding, the 1038 Content-Length MUST be ignored. 1040 When a Content-Length is given in a message where a message-body is 1041 allowed, its field value MUST exactly match the number of OCTETs in 1042 the message-body. HTTP/1.1 user agents MUST notify the user when an 1043 invalid length is received and detected. 1045 4.5. General Header Fields 1047 There are a few header fields which have general applicability for 1048 both request and response messages, but which do not apply to the 1049 entity being transferred. These header fields apply only to the 1050 message being transmitted. 1052 general-header = Cache-Control ; [Part6], Section 16.2 1053 / Connection ; Section 8.1 1054 / Date ; Section 8.3 1055 / Pragma ; [Part6], Section 16.4 1056 / Trailer ; Section 8.6 1057 / Transfer-Encoding ; Section 8.7 1058 / Upgrade ; Section 8.8 1059 / Via ; Section 8.9 1060 / Warning ; [Part6], Section 16.6 1062 General-header field names can be extended reliably only in 1063 combination with a change in the protocol version. However, new or 1064 experimental header fields may be given the semantics of general 1065 header fields if all parties in the communication recognize them to 1066 be general-header fields. Unrecognized header fields are treated as 1067 entity-header fields. 1069 5. Request 1071 A request message from a client to a server includes, within the 1072 first line of that message, the method to be applied to the resource, 1073 the identifier of the resource, and the protocol version in use. 1075 Request = Request-Line ; Section 5.1 1076 *(( general-header ; Section 4.5 1077 / request-header ; [Part2], Section 4 1078 / entity-header ) CRLF) ; [Part3], Section 4.1 1079 CRLF 1080 [ message-body ] ; Section 4.3 1082 5.1. Request-Line 1084 The Request-Line begins with a method token, followed by the Request- 1085 URI and the protocol version, and ending with CRLF. The elements are 1086 separated by SP characters. No CR or LF is allowed except in the 1087 final CRLF sequence. 1089 Request-Line = Method SP Request-URI SP HTTP-Version CRLF 1091 5.1.1. Method 1093 The Method token indicates the method to be performed on the resource 1094 identified by the Request-URI. The method is case-sensitive. 1096 Method = token 1098 5.1.2. Request-URI 1100 The Request-URI is a Uniform Resource Identifier (Section 3.2) and 1101 identifies the resource upon which to apply the request. 1103 Request-URI = "*" 1104 / absolute-URI 1105 / ( path-absolute [ "?" query ] ) 1106 / authority 1108 The four options for Request-URI are dependent on the nature of the 1109 request. The asterisk "*" means that the request does not apply to a 1110 particular resource, but to the server itself, and is only allowed 1111 when the method used does not necessarily apply to a resource. One 1112 example would be 1114 OPTIONS * HTTP/1.1 1116 The absolute-URI form is REQUIRED when the request is being made to a 1117 proxy. The proxy is requested to forward the request or service it 1118 from a valid cache, and return the response. Note that the proxy MAY 1119 forward the request on to another proxy or directly to the server 1120 specified by the absolute-URI. In order to avoid request loops, a 1121 proxy MUST be able to recognize all of its server names, including 1122 any aliases, local variations, and the numeric IP address. An 1123 example Request-Line would be: 1125 GET http://www.example.org/pub/WWW/TheProject.html HTTP/1.1 1127 To allow for transition to absolute-URIs in all requests in future 1128 versions of HTTP, all HTTP/1.1 servers MUST accept the absolute-URI 1129 form in requests, even though HTTP/1.1 clients will only generate 1130 them in requests to proxies. 1132 The authority form is only used by the CONNECT method (Section 8.9 of 1133 [Part2]). 1135 The most common form of Request-URI is that used to identify a 1136 resource on an origin server or gateway. In this case the absolute 1137 path of the URI MUST be transmitted (see Section 3.2.1, path- 1138 absolute) as the Request-URI, and the network location of the URI 1139 (authority) MUST be transmitted in a Host header field. For example, 1140 a client wishing to retrieve the resource above directly from the 1141 origin server would create a TCP connection to port 80 of the host 1142 "www.example.org" and send the lines: 1144 GET /pub/WWW/TheProject.html HTTP/1.1 1145 Host: www.example.org 1147 followed by the remainder of the Request. Note that the absolute 1148 path cannot be empty; if none is present in the original URI, it MUST 1149 be given as "/" (the server root). 1151 The Request-URI is transmitted in the format specified in 1152 Section 3.2.1. If the Request-URI is encoded using the "% HEXDIG 1153 HEXDIG" encoding ([RFC3986], Section 2.4), the origin server MUST 1154 decode the Request-URI in order to properly interpret the request. 1155 Servers SHOULD respond to invalid Request-URIs with an appropriate 1156 status code. 1158 A transparent proxy MUST NOT rewrite the "path-absolute" part of the 1159 received Request-URI when forwarding it to the next inbound server, 1160 except as noted above to replace a null path-absolute with "/". 1162 Note: The "no rewrite" rule prevents the proxy from changing the 1163 meaning of the request when the origin server is improperly using 1164 a non-reserved URI character for a reserved purpose. Implementors 1165 should be aware that some pre-HTTP/1.1 proxies have been known to 1166 rewrite the Request-URI. 1168 5.2. The Resource Identified by a Request 1170 The exact resource identified by an Internet request is determined by 1171 examining both the Request-URI and the Host header field. 1173 An origin server that does not allow resources to differ by the 1174 requested host MAY ignore the Host header field value when 1175 determining the resource identified by an HTTP/1.1 request. (But see 1176 Appendix C.1.1 for other requirements on Host support in HTTP/1.1.) 1178 An origin server that does differentiate resources based on the host 1179 requested (sometimes referred to as virtual hosts or vanity host 1180 names) MUST use the following rules for determining the requested 1181 resource on an HTTP/1.1 request: 1183 1. If Request-URI is an absolute-URI, the host is part of the 1184 Request-URI. Any Host header field value in the request MUST be 1185 ignored. 1187 2. If the Request-URI is not an absolute-URI, and the request 1188 includes a Host header field, the host is determined by the Host 1189 header field value. 1191 3. If the host as determined by rule 1 or 2 is not a valid host on 1192 the server, the response MUST be a 400 (Bad Request) error 1193 message. 1195 Recipients of an HTTP/1.0 request that lacks a Host header field MAY 1196 attempt to use heuristics (e.g., examination of the URI path for 1197 something unique to a particular host) in order to determine what 1198 exact resource is being requested. 1200 6. Response 1202 After receiving and interpreting a request message, a server responds 1203 with an HTTP response message. 1205 Response = Status-Line ; Section 6.1 1206 *(( general-header ; Section 4.5 1207 / response-header ; [Part2], Section 6 1208 / entity-header ) CRLF) ; [Part3], Section 4.1 1209 CRLF 1210 [ message-body ] ; Section 4.3 1212 6.1. Status-Line 1214 The first line of a Response message is the Status-Line, consisting 1215 of the protocol version followed by a numeric status code and its 1216 associated textual phrase, with each element separated by SP 1217 characters. No CR or LF is allowed except in the final CRLF 1218 sequence. 1220 Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF 1222 6.1.1. Status Code and Reason Phrase 1224 The Status-Code element is a 3-digit integer result code of the 1225 attempt to understand and satisfy the request. These codes are fully 1226 defined in Section 9 of [Part2]. The Reason Phrase exists for the 1227 sole purpose of providing a textual description associated with the 1228 numeric status code, out of deference to earlier Internet application 1229 protocols that were more frequently used with interactive text 1230 clients. A client SHOULD ignore the content of the Reason Phrase. 1232 The first digit of the Status-Code defines the class of response. 1233 The last two digits do not have any categorization role. There are 5 1234 values for the first digit: 1236 o 1xx: Informational - Request received, continuing process 1238 o 2xx: Success - The action was successfully received, understood, 1239 and accepted 1241 o 3xx: Redirection - Further action must be taken in order to 1242 complete the request 1244 o 4xx: Client Error - The request contains bad syntax or cannot be 1245 fulfilled 1247 o 5xx: Server Error - The server failed to fulfill an apparently 1248 valid request 1250 Status-Code = 3DIGIT 1251 Reason-Phrase = * 1253 7. Connections 1254 7.1. Persistent Connections 1256 7.1.1. Purpose 1258 Prior to persistent connections, a separate TCP connection was 1259 established to fetch each URL, increasing the load on HTTP servers 1260 and causing congestion on the Internet. The use of inline images and 1261 other associated data often require a client to make multiple 1262 requests of the same server in a short amount of time. Analysis of 1263 these performance problems and results from a prototype 1264 implementation are available [Pad1995] [Spe]. Implementation 1265 experience and measurements of actual HTTP/1.1 (RFC 2068) 1266 implementations show good results [Nie1997]. Alternatives have also 1267 been explored, for example, T/TCP [Tou1998]. 1269 Persistent HTTP connections have a number of advantages: 1271 o By opening and closing fewer TCP connections, CPU time is saved in 1272 routers and hosts (clients, servers, proxies, gateways, tunnels, 1273 or caches), and memory used for TCP protocol control blocks can be 1274 saved in hosts. 1276 o HTTP requests and responses can be pipelined on a connection. 1277 Pipelining allows a client to make multiple requests without 1278 waiting for each response, allowing a single TCP connection to be 1279 used much more efficiently, with much lower elapsed time. 1281 o Network congestion is reduced by reducing the number of packets 1282 caused by TCP opens, and by allowing TCP sufficient time to 1283 determine the congestion state of the network. 1285 o Latency on subsequent requests is reduced since there is no time 1286 spent in TCP's connection opening handshake. 1288 o HTTP can evolve more gracefully, since errors can be reported 1289 without the penalty of closing the TCP connection. Clients using 1290 future versions of HTTP might optimistically try a new feature, 1291 but if communicating with an older server, retry with old 1292 semantics after an error is reported. 1294 HTTP implementations SHOULD implement persistent connections. 1296 7.1.2. Overall Operation 1298 A significant difference between HTTP/1.1 and earlier versions of 1299 HTTP is that persistent connections are the default behavior of any 1300 HTTP connection. That is, unless otherwise indicated, the client 1301 SHOULD assume that the server will maintain a persistent connection, 1302 even after error responses from the server. 1304 Persistent connections provide a mechanism by which a client and a 1305 server can signal the close of a TCP connection. This signaling 1306 takes place using the Connection header field (Section 8.1). Once a 1307 close has been signaled, the client MUST NOT send any more requests 1308 on that connection. 1310 7.1.2.1. Negotiation 1312 An HTTP/1.1 server MAY assume that a HTTP/1.1 client intends to 1313 maintain a persistent connection unless a Connection header including 1314 the connection-token "close" was sent in the request. If the server 1315 chooses to close the connection immediately after sending the 1316 response, it SHOULD send a Connection header including the 1317 connection-token close. 1319 An HTTP/1.1 client MAY expect a connection to remain open, but would 1320 decide to keep it open based on whether the response from a server 1321 contains a Connection header with the connection-token close. In 1322 case the client does not want to maintain a connection for more than 1323 that request, it SHOULD send a Connection header including the 1324 connection-token close. 1326 If either the client or the server sends the close token in the 1327 Connection header, that request becomes the last one for the 1328 connection. 1330 Clients and servers SHOULD NOT assume that a persistent connection is 1331 maintained for HTTP versions less than 1.1 unless it is explicitly 1332 signaled. See Appendix C.2 for more information on backward 1333 compatibility with HTTP/1.0 clients. 1335 In order to remain persistent, all messages on the connection MUST 1336 have a self-defined message length (i.e., one not defined by closure 1337 of the connection), as described in Section 4.4. 1339 7.1.2.2. Pipelining 1341 A client that supports persistent connections MAY "pipeline" its 1342 requests (i.e., send multiple requests without waiting for each 1343 response). A server MUST send its responses to those requests in the 1344 same order that the requests were received. 1346 Clients which assume persistent connections and pipeline immediately 1347 after connection establishment SHOULD be prepared to retry their 1348 connection if the first pipelined attempt fails. If a client does 1349 such a retry, it MUST NOT pipeline before it knows the connection is 1350 persistent. Clients MUST also be prepared to resend their requests 1351 if the server closes the connection before sending all of the 1352 corresponding responses. 1354 Clients SHOULD NOT pipeline requests using non-idempotent methods or 1355 non-idempotent sequences of methods (see Section 8.1.2 of [Part2]). 1356 Otherwise, a premature termination of the transport connection could 1357 lead to indeterminate results. A client wishing to send a non- 1358 idempotent request SHOULD wait to send that request until it has 1359 received the response status for the previous request. 1361 7.1.3. Proxy Servers 1363 It is especially important that proxies correctly implement the 1364 properties of the Connection header field as specified in 1365 Section 8.1. 1367 The proxy server MUST signal persistent connections separately with 1368 its clients and the origin servers (or other proxy servers) that it 1369 connects to. Each persistent connection applies to only one 1370 transport link. 1372 A proxy server MUST NOT establish a HTTP/1.1 persistent connection 1373 with an HTTP/1.0 client (but see [RFC2068] for information and 1374 discussion of the problems with the Keep-Alive header implemented by 1375 many HTTP/1.0 clients). 1377 7.1.4. Practical Considerations 1379 Servers will usually have some time-out value beyond which they will 1380 no longer maintain an inactive connection. Proxy servers might make 1381 this a higher value since it is likely that the client will be making 1382 more connections through the same server. The use of persistent 1383 connections places no requirements on the length (or existence) of 1384 this time-out for either the client or the server. 1386 When a client or server wishes to time-out it SHOULD issue a graceful 1387 close on the transport connection. Clients and servers SHOULD both 1388 constantly watch for the other side of the transport close, and 1389 respond to it as appropriate. If a client or server does not detect 1390 the other side's close promptly it could cause unnecessary resource 1391 drain on the network. 1393 A client, server, or proxy MAY close the transport connection at any 1394 time. For example, a client might have started to send a new request 1395 at the same time that the server has decided to close the "idle" 1396 connection. From the server's point of view, the connection is being 1397 closed while it was idle, but from the client's point of view, a 1398 request is in progress. 1400 This means that clients, servers, and proxies MUST be able to recover 1401 from asynchronous close events. Client software SHOULD reopen the 1402 transport connection and retransmit the aborted sequence of requests 1403 without user interaction so long as the request sequence is 1404 idempotent (see Section 8.1.2 of [Part2]). Non-idempotent methods or 1405 sequences MUST NOT be automatically retried, although user agents MAY 1406 offer a human operator the choice of retrying the request(s). 1407 Confirmation by user-agent software with semantic understanding of 1408 the application MAY substitute for user confirmation. The automatic 1409 retry SHOULD NOT be repeated if the second sequence of requests 1410 fails. 1412 Servers SHOULD always respond to at least one request per connection, 1413 if at all possible. Servers SHOULD NOT close a connection in the 1414 middle of transmitting a response, unless a network or client failure 1415 is suspected. 1417 Clients that use persistent connections SHOULD limit the number of 1418 simultaneous connections that they maintain to a given server. A 1419 single-user client SHOULD NOT maintain more than 2 connections with 1420 any server or proxy. A proxy SHOULD use up to 2*N connections to 1421 another server or proxy, where N is the number of simultaneously 1422 active users. These guidelines are intended to improve HTTP response 1423 times and avoid congestion. 1425 7.2. Message Transmission Requirements 1427 7.2.1. Persistent Connections and Flow Control 1429 HTTP/1.1 servers SHOULD maintain persistent connections and use TCP's 1430 flow control mechanisms to resolve temporary overloads, rather than 1431 terminating connections with the expectation that clients will retry. 1432 The latter technique can exacerbate network congestion. 1434 7.2.2. Monitoring Connections for Error Status Messages 1436 An HTTP/1.1 (or later) client sending a message-body SHOULD monitor 1437 the network connection for an error status while it is transmitting 1438 the request. If the client sees an error status, it SHOULD 1439 immediately cease transmitting the body. If the body is being sent 1440 using a "chunked" encoding (Section 3.4), a zero length chunk and 1441 empty trailer MAY be used to prematurely mark the end of the message. 1442 If the body was preceded by a Content-Length header, the client MUST 1443 close the connection. 1445 7.2.3. Use of the 100 (Continue) Status 1447 The purpose of the 100 (Continue) status (see Section 9.1.1 of 1448 [Part2]) is to allow a client that is sending a request message with 1449 a request body to determine if the origin server is willing to accept 1450 the request (based on the request headers) before the client sends 1451 the request body. In some cases, it might either be inappropriate or 1452 highly inefficient for the client to send the body if the server will 1453 reject the message without looking at the body. 1455 Requirements for HTTP/1.1 clients: 1457 o If a client will wait for a 100 (Continue) response before sending 1458 the request body, it MUST send an Expect request-header field 1459 (Section 10.2 of [Part2]) with the "100-continue" expectation. 1461 o A client MUST NOT send an Expect request-header field (Section 1462 10.2 of [Part2]) with the "100-continue" expectation if it does 1463 not intend to send a request body. 1465 Because of the presence of older implementations, the protocol allows 1466 ambiguous situations in which a client may send "Expect: 100- 1467 continue" without receiving either a 417 (Expectation Failed) status 1468 or a 100 (Continue) status. Therefore, when a client sends this 1469 header field to an origin server (possibly via a proxy) from which it 1470 has never seen a 100 (Continue) status, the client SHOULD NOT wait 1471 for an indefinite period before sending the request body. 1473 Requirements for HTTP/1.1 origin servers: 1475 o Upon receiving a request which includes an Expect request-header 1476 field with the "100-continue" expectation, an origin server MUST 1477 either respond with 100 (Continue) status and continue to read 1478 from the input stream, or respond with a final status code. The 1479 origin server MUST NOT wait for the request body before sending 1480 the 100 (Continue) response. If it responds with a final status 1481 code, it MAY close the transport connection or it MAY continue to 1482 read and discard the rest of the request. It MUST NOT perform the 1483 requested method if it returns a final status code. 1485 o An origin server SHOULD NOT send a 100 (Continue) response if the 1486 request message does not include an Expect request-header field 1487 with the "100-continue" expectation, and MUST NOT send a 100 1488 (Continue) response if such a request comes from an HTTP/1.0 (or 1489 earlier) client. There is an exception to this rule: for 1490 compatibility with [RFC2068], a server MAY send a 100 (Continue) 1491 status in response to an HTTP/1.1 PUT or POST request that does 1492 not include an Expect request-header field with the "100-continue" 1493 expectation. This exception, the purpose of which is to minimize 1494 any client processing delays associated with an undeclared wait 1495 for 100 (Continue) status, applies only to HTTP/1.1 requests, and 1496 not to requests with any other HTTP-version value. 1498 o An origin server MAY omit a 100 (Continue) response if it has 1499 already received some or all of the request body for the 1500 corresponding request. 1502 o An origin server that sends a 100 (Continue) response MUST 1503 ultimately send a final status code, once the request body is 1504 received and processed, unless it terminates the transport 1505 connection prematurely. 1507 o If an origin server receives a request that does not include an 1508 Expect request-header field with the "100-continue" expectation, 1509 the request includes a request body, and the server responds with 1510 a final status code before reading the entire request body from 1511 the transport connection, then the server SHOULD NOT close the 1512 transport connection until it has read the entire request, or 1513 until the client closes the connection. Otherwise, the client 1514 might not reliably receive the response message. However, this 1515 requirement is not be construed as preventing a server from 1516 defending itself against denial-of-service attacks, or from badly 1517 broken client implementations. 1519 Requirements for HTTP/1.1 proxies: 1521 o If a proxy receives a request that includes an Expect request- 1522 header field with the "100-continue" expectation, and the proxy 1523 either knows that the next-hop server complies with HTTP/1.1 or 1524 higher, or does not know the HTTP version of the next-hop server, 1525 it MUST forward the request, including the Expect header field. 1527 o If the proxy knows that the version of the next-hop server is 1528 HTTP/1.0 or lower, it MUST NOT forward the request, and it MUST 1529 respond with a 417 (Expectation Failed) status. 1531 o Proxies SHOULD maintain a cache recording the HTTP version numbers 1532 received from recently-referenced next-hop servers. 1534 o A proxy MUST NOT forward a 100 (Continue) response if the request 1535 message was received from an HTTP/1.0 (or earlier) client and did 1536 not include an Expect request-header field with the "100-continue" 1537 expectation. This requirement overrides the general rule for 1538 forwarding of 1xx responses (see Section 9.1 of [Part2]). 1540 7.2.4. Client Behavior if Server Prematurely Closes Connection 1542 If an HTTP/1.1 client sends a request which includes a request body, 1543 but which does not include an Expect request-header field with the 1544 "100-continue" expectation, and if the client is not directly 1545 connected to an HTTP/1.1 origin server, and if the client sees the 1546 connection close before receiving any status from the server, the 1547 client SHOULD retry the request. If the client does retry this 1548 request, it MAY use the following "binary exponential backoff" 1549 algorithm to be assured of obtaining a reliable response: 1551 1. Initiate a new connection to the server 1553 2. Transmit the request-headers 1555 3. Initialize a variable R to the estimated round-trip time to the 1556 server (e.g., based on the time it took to establish the 1557 connection), or to a constant value of 5 seconds if the round- 1558 trip time is not available. 1560 4. Compute T = R * (2**N), where N is the number of previous retries 1561 of this request. 1563 5. Wait either for an error response from the server, or for T 1564 seconds (whichever comes first) 1566 6. If no error response is received, after T seconds transmit the 1567 body of the request. 1569 7. If client sees that the connection is closed prematurely, repeat 1570 from step 1 until the request is accepted, an error response is 1571 received, or the user becomes impatient and terminates the retry 1572 process. 1574 If at any point an error status is received, the client 1576 o SHOULD NOT continue and 1578 o SHOULD close the connection if it has not completed sending the 1579 request message. 1581 8. Header Field Definitions 1583 This section defines the syntax and semantics of HTTP/1.1 header 1584 fields related to message framing and transport protocols. 1586 For entity-header fields, both sender and recipient refer to either 1587 the client or the server, depending on who sends and who receives the 1588 entity. 1590 8.1. Connection 1592 The general-header field "Connection" allows the sender to specify 1593 options that are desired for that particular connection and MUST NOT 1594 be communicated by proxies over further connections. 1596 The Connection header's value has the following grammar: 1598 Connection = "Connection" ":" OWS Connection-v 1599 Connection-v = 1#connection-token 1600 connection-token = token 1602 HTTP/1.1 proxies MUST parse the Connection header field before a 1603 message is forwarded and, for each connection-token in this field, 1604 remove any header field(s) from the message with the same name as the 1605 connection-token. Connection options are signaled by the presence of 1606 a connection-token in the Connection header field, not by any 1607 corresponding additional header field(s), since the additional header 1608 field may not be sent if there are no parameters associated with that 1609 connection option. 1611 Message headers listed in the Connection header MUST NOT include end- 1612 to-end headers, such as Cache-Control. 1614 HTTP/1.1 defines the "close" connection option for the sender to 1615 signal that the connection will be closed after completion of the 1616 response. For example, 1618 Connection: close 1620 in either the request or the response header fields indicates that 1621 the connection SHOULD NOT be considered `persistent' (Section 7.1) 1622 after the current request/response is complete. 1624 An HTTP/1.1 client that does not support persistent connections MUST 1625 include the "close" connection option in every request message. 1627 An HTTP/1.1 server that does not support persistent connections MUST 1628 include the "close" connection option in every response message that 1629 does not have a 1xx (informational) status code. 1631 A system receiving an HTTP/1.0 (or lower-version) message that 1632 includes a Connection header MUST, for each connection-token in this 1633 field, remove and ignore any header field(s) from the message with 1634 the same name as the connection-token. This protects against 1635 mistaken forwarding of such header fields by pre-HTTP/1.1 proxies. 1636 See Appendix C.2. 1638 8.2. Content-Length 1640 The entity-header field "Content-Length" indicates the size of the 1641 entity-body, in decimal number of OCTETs, sent to the recipient or, 1642 in the case of the HEAD method, the size of the entity-body that 1643 would have been sent had the request been a GET. 1645 Content-Length = "Content-Length" ":" OWS 1*Content-Length-v 1646 Content-Length-v = 1*DIGIT 1648 An example is 1650 Content-Length: 3495 1652 Applications SHOULD use this field to indicate the transfer-length of 1653 the message-body, unless this is prohibited by the rules in 1654 Section 4.4. 1656 Any Content-Length greater than or equal to zero is a valid value. 1657 Section 4.4 describes how to determine the length of a message-body 1658 if a Content-Length is not given. 1660 Note that the meaning of this field is significantly different from 1661 the corresponding definition in MIME, where it is an optional field 1662 used within the "message/external-body" content-type. In HTTP, it 1663 SHOULD be sent whenever the message's length can be determined prior 1664 to being transferred, unless this is prohibited by the rules in 1665 Section 4.4. 1667 8.3. Date 1669 The general-header field "Date" represents the date and time at which 1670 the message was originated, having the same semantics as orig-date in 1671 Section 3.6.1 of [RFC5322]. The field value is an HTTP-date, as 1672 described in Section 3.3.1; it MUST be sent in rfc1123-date format. 1674 Date = "Date" ":" OWS Date-v 1675 Date-v = HTTP-date 1677 An example is 1679 Date: Tue, 15 Nov 1994 08:12:31 GMT 1681 Origin servers MUST include a Date header field in all responses, 1682 except in these cases: 1684 1. If the response status code is 100 (Continue) or 101 (Switching 1685 Protocols), the response MAY include a Date header field, at the 1686 server's option. 1688 2. If the response status code conveys a server error, e.g. 500 1689 (Internal Server Error) or 503 (Service Unavailable), and it is 1690 inconvenient or impossible to generate a valid Date. 1692 3. If the server does not have a clock that can provide a reasonable 1693 approximation of the current time, its responses MUST NOT include 1694 a Date header field. In this case, the rules in Section 8.3.1 1695 MUST be followed. 1697 A received message that does not have a Date header field MUST be 1698 assigned one by the recipient if the message will be cached by that 1699 recipient or gatewayed via a protocol which requires a Date. An HTTP 1700 implementation without a clock MUST NOT cache responses without 1701 revalidating them on every use. An HTTP cache, especially a shared 1702 cache, SHOULD use a mechanism, such as NTP [RFC1305], to synchronize 1703 its clock with a reliable external standard. 1705 Clients SHOULD only send a Date header field in messages that include 1706 an entity-body, as in the case of the PUT and POST requests, and even 1707 then it is optional. A client without a clock MUST NOT send a Date 1708 header field in a request. 1710 The HTTP-date sent in a Date header SHOULD NOT represent a date and 1711 time subsequent to the generation of the message. It SHOULD 1712 represent the best available approximation of the date and time of 1713 message generation, unless the implementation has no means of 1714 generating a reasonably accurate date and time. In theory, the date 1715 ought to represent the moment just before the entity is generated. 1716 In practice, the date can be generated at any time during the message 1717 origination without affecting its semantic value. 1719 8.3.1. Clockless Origin Server Operation 1721 Some origin server implementations might not have a clock available. 1722 An origin server without a clock MUST NOT assign Expires or Last- 1723 Modified values to a response, unless these values were associated 1724 with the resource by a system or user with a reliable clock. It MAY 1725 assign an Expires value that is known, at or before server 1726 configuration time, to be in the past (this allows "pre-expiration" 1727 of responses without storing separate Expires values for each 1728 resource). 1730 8.4. Host 1732 The request-header field "Host" specifies the Internet host and port 1733 number of the resource being requested, as obtained from the original 1734 URI given by the user or referring resource (generally an HTTP URL, 1735 as described in Section 3.2.1). The Host field value MUST represent 1736 the naming authority of the origin server or gateway given by the 1737 original URL. This allows the origin server or gateway to 1738 differentiate between internally-ambiguous URLs, such as the root "/" 1739 URL of a server for multiple host names on a single IP address. 1741 Host = "Host" ":" OWS Host-v 1742 Host-v = uri-host [ ":" port ] ; Section 3.2.1 1744 A "host" without any trailing port information implies the default 1745 port for the service requested (e.g., "80" for an HTTP URL). For 1746 example, a request on the origin server for 1747 would properly include: 1749 GET /pub/WWW/ HTTP/1.1 1750 Host: www.example.org 1752 A client MUST include a Host header field in all HTTP/1.1 request 1753 messages. If the requested URI does not include an Internet host 1754 name for the service being requested, then the Host header field MUST 1755 be given with an empty value. An HTTP/1.1 proxy MUST ensure that any 1756 request message it forwards does contain an appropriate Host header 1757 field that identifies the service being requested by the proxy. All 1758 Internet-based HTTP/1.1 servers MUST respond with a 400 (Bad Request) 1759 status code to any HTTP/1.1 request message which lacks a Host header 1760 field. 1762 See Sections 5.2 and C.1.1 for other requirements relating to Host. 1764 8.5. TE 1766 The request-header field "TE" indicates what extension transfer- 1767 codings it is willing to accept in the response and whether or not it 1768 is willing to accept trailer fields in a chunked transfer-coding. 1769 Its value may consist of the keyword "trailers" and/or a comma- 1770 separated list of extension transfer-coding names with optional 1771 accept parameters (as described in Section 3.4). 1773 TE = "TE" ":" OWS TE-v 1774 TE-v = #t-codings 1775 t-codings = "trailers" / ( transfer-extension [ accept-params ] ) 1777 The presence of the keyword "trailers" indicates that the client is 1778 willing to accept trailer fields in a chunked transfer-coding, as 1779 defined in Section 3.4.1. This keyword is reserved for use with 1780 transfer-coding values even though it does not itself represent a 1781 transfer-coding. 1783 Examples of its use are: 1785 TE: deflate 1786 TE: 1787 TE: trailers, deflate;q=0.5 1789 The TE header field only applies to the immediate connection. 1790 Therefore, the keyword MUST be supplied within a Connection header 1791 field (Section 8.1) whenever TE is present in an HTTP/1.1 message. 1793 A server tests whether a transfer-coding is acceptable, according to 1794 a TE field, using these rules: 1796 1. The "chunked" transfer-coding is always acceptable. If the 1797 keyword "trailers" is listed, the client indicates that it is 1798 willing to accept trailer fields in the chunked response on 1799 behalf of itself and any downstream clients. The implication is 1800 that, if given, the client is stating that either all downstream 1801 clients are willing to accept trailer fields in the forwarded 1802 response, or that it will attempt to buffer the response on 1803 behalf of downstream recipients. 1805 Note: HTTP/1.1 does not define any means to limit the size of a 1806 chunked response such that a client can be assured of buffering 1807 the entire response. 1809 2. If the transfer-coding being tested is one of the transfer- 1810 codings listed in the TE field, then it is acceptable unless it 1811 is accompanied by a qvalue of 0. (As defined in Section 3.4 of 1812 [Part3], a qvalue of 0 means "not acceptable.") 1814 3. If multiple transfer-codings are acceptable, then the acceptable 1815 transfer-coding with the highest non-zero qvalue is preferred. 1816 The "chunked" transfer-coding always has a qvalue of 1. 1818 If the TE field-value is empty or if no TE field is present, the only 1819 transfer-coding is "chunked". A message with no transfer-coding is 1820 always acceptable. 1822 8.6. Trailer 1824 The general field "Trailer" indicates that the given set of header 1825 fields is present in the trailer of a message encoded with chunked 1826 transfer-coding. 1828 Trailer = "Trailer" ":" OWS Trailer-v 1829 Trailer-v = 1#field-name 1831 An HTTP/1.1 message SHOULD include a Trailer header field in a 1832 message using chunked transfer-coding with a non-empty trailer. 1833 Doing so allows the recipient to know which header fields to expect 1834 in the trailer. 1836 If no Trailer header field is present, the trailer SHOULD NOT include 1837 any header fields. See Section 3.4.1 for restrictions on the use of 1838 trailer fields in a "chunked" transfer-coding. 1840 Message header fields listed in the Trailer header field MUST NOT 1841 include the following header fields: 1843 o Transfer-Encoding 1845 o Content-Length 1847 o Trailer 1849 8.7. Transfer-Encoding 1851 The general-header "Transfer-Encoding" field indicates what (if any) 1852 type of transformation has been applied to the message body in order 1853 to safely transfer it between the sender and the recipient. This 1854 differs from the content-coding in that the transfer-coding is a 1855 property of the message, not of the entity. 1857 Transfer-Encoding = "Transfer-Encoding" ":" OWS 1858 Transfer-Encoding-v 1859 Transfer-Encoding-v = 1#transfer-coding 1861 Transfer-codings are defined in Section 3.4. An example is: 1863 Transfer-Encoding: chunked 1865 If multiple encodings have been applied to an entity, the transfer- 1866 codings MUST be listed in the order in which they were applied. 1867 Additional information about the encoding parameters MAY be provided 1868 by other entity-header fields not defined by this specification. 1870 Many older HTTP/1.0 applications do not understand the Transfer- 1871 Encoding header. 1873 8.8. Upgrade 1875 The general-header "Upgrade" allows the client to specify what 1876 additional communication protocols it supports and would like to use 1877 if the server finds it appropriate to switch protocols. The server 1878 MUST use the Upgrade header field within a 101 (Switching Protocols) 1879 response to indicate which protocol(s) are being switched. 1881 Upgrade = "Upgrade" ":" OWS Upgrade-v 1882 Upgrade-v = 1#product 1884 For example, 1886 Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11 1888 The Upgrade header field is intended to provide a simple mechanism 1889 for transition from HTTP/1.1 to some other, incompatible protocol. 1890 It does so by allowing the client to advertise its desire to use 1891 another protocol, such as a later version of HTTP with a higher major 1892 version number, even though the current request has been made using 1893 HTTP/1.1. This eases the difficult transition between incompatible 1894 protocols by allowing the client to initiate a request in the more 1895 commonly supported protocol while indicating to the server that it 1896 would like to use a "better" protocol if available (where "better" is 1897 determined by the server, possibly according to the nature of the 1898 method and/or resource being requested). 1900 The Upgrade header field only applies to switching application-layer 1901 protocols upon the existing transport-layer connection. Upgrade 1902 cannot be used to insist on a protocol change; its acceptance and use 1903 by the server is optional. The capabilities and nature of the 1904 application-layer communication after the protocol change is entirely 1905 dependent upon the new protocol chosen, although the first action 1906 after changing the protocol MUST be a response to the initial HTTP 1907 request containing the Upgrade header field. 1909 The Upgrade header field only applies to the immediate connection. 1910 Therefore, the upgrade keyword MUST be supplied within a Connection 1911 header field (Section 8.1) whenever Upgrade is present in an HTTP/1.1 1912 message. 1914 The Upgrade header field cannot be used to indicate a switch to a 1915 protocol on a different connection. For that purpose, it is more 1916 appropriate to use a 301, 302, 303, or 305 redirection response. 1918 This specification only defines the protocol name "HTTP" for use by 1919 the family of Hypertext Transfer Protocols, as defined by the HTTP 1920 version rules of Section 3.1 and future updates to this 1921 specification. Any token can be used as a protocol name; however, it 1922 will only be useful if both the client and server associate the name 1923 with the same protocol. 1925 8.9. Via 1927 The general-header field "Via" MUST be used by gateways and proxies 1928 to indicate the intermediate protocols and recipients between the 1929 user agent and the server on requests, and between the origin server 1930 and the client on responses. It is analogous to the "Received" field 1931 defined in Section 3.6.7 of [RFC5322] and is intended to be used for 1932 tracking message forwards, avoiding request loops, and identifying 1933 the protocol capabilities of all senders along the request/response 1934 chain. 1936 Via = "Via" ":" OWS Via-v 1937 Via-v = 1#( received-protocol RWS received-by 1938 [ RWS comment ] ) 1939 received-protocol = [ protocol-name "/" ] protocol-version 1940 protocol-name = token 1941 protocol-version = token 1942 received-by = ( uri-host [ ":" port ] ) / pseudonym 1943 pseudonym = token 1945 The received-protocol indicates the protocol version of the message 1946 received by the server or client along each segment of the request/ 1947 response chain. The received-protocol version is appended to the Via 1948 field value when the message is forwarded so that information about 1949 the protocol capabilities of upstream applications remains visible to 1950 all recipients. 1952 The protocol-name is optional if and only if it would be "HTTP". The 1953 received-by field is normally the host and optional port number of a 1954 recipient server or client that subsequently forwarded the message. 1955 However, if the real host is considered to be sensitive information, 1956 it MAY be replaced by a pseudonym. If the port is not given, it MAY 1957 be assumed to be the default port of the received-protocol. 1959 Multiple Via field values represents each proxy or gateway that has 1960 forwarded the message. Each recipient MUST append its information 1961 such that the end result is ordered according to the sequence of 1962 forwarding applications. 1964 Comments MAY be used in the Via header field to identify the software 1965 of the recipient proxy or gateway, analogous to the User-Agent and 1966 Server header fields. However, all comments in the Via field are 1967 optional and MAY be removed by any recipient prior to forwarding the 1968 message. 1970 For example, a request message could be sent from an HTTP/1.0 user 1971 agent to an internal proxy code-named "fred", which uses HTTP/1.1 to 1972 forward the request to a public proxy at p.example.net, which 1973 completes the request by forwarding it to the origin server at 1974 www.example.com. The request received by www.example.com would then 1975 have the following Via header field: 1977 Via: 1.0 fred, 1.1 p.example.net (Apache/1.1) 1979 Proxies and gateways used as a portal through a network firewall 1980 SHOULD NOT, by default, forward the names and ports of hosts within 1981 the firewall region. This information SHOULD only be propagated if 1982 explicitly enabled. If not enabled, the received-by host of any host 1983 behind the firewall SHOULD be replaced by an appropriate pseudonym 1984 for that host. 1986 For organizations that have strong privacy requirements for hiding 1987 internal structures, a proxy MAY combine an ordered subsequence of 1988 Via header field entries with identical received-protocol values into 1989 a single such entry. For example, 1991 Via: 1.0 ricky, 1.1 ethel, 1.1 fred, 1.0 lucy 1993 could be collapsed to 1995 Via: 1.0 ricky, 1.1 mertz, 1.0 lucy 1997 Applications SHOULD NOT combine multiple entries unless they are all 1998 under the same organizational control and the hosts have already been 1999 replaced by pseudonyms. Applications MUST NOT combine entries which 2000 have different received-protocol values. 2002 9. IANA Considerations 2004 9.1. Message Header Registration 2006 The Message Header Registry located at should be 2008 updated with the permanent registrations below (see [RFC3864]): 2010 +-------------------+----------+----------+-------------+ 2011 | Header Field Name | Protocol | Status | Reference | 2012 +-------------------+----------+----------+-------------+ 2013 | Connection | http | standard | Section 8.1 | 2014 | Content-Length | http | standard | Section 8.2 | 2015 | Date | http | standard | Section 8.3 | 2016 | Host | http | standard | Section 8.4 | 2017 | TE | http | standard | Section 8.5 | 2018 | Trailer | http | standard | Section 8.6 | 2019 | Transfer-Encoding | http | standard | Section 8.7 | 2020 | Upgrade | http | standard | Section 8.8 | 2021 | Via | http | standard | Section 8.9 | 2022 +-------------------+----------+----------+-------------+ 2024 The change controller is: "IETF (iesg@ietf.org) - Internet 2025 Engineering Task Force". 2027 9.2. URI Scheme Registration 2029 The entry for the "http" URI Scheme in the registry located at 2030 should be updated 2031 to point to Section 3.2.1 of this document (see [RFC4395]). 2033 9.3. Internet Media Type Registrations 2035 This document serves as the specification for the Internet media 2036 types "message/http" and "application/http". The following is to be 2037 registered with IANA (see [RFC4288]). 2039 9.3.1. Internet Media Type message/http 2041 The message/http type can be used to enclose a single HTTP request or 2042 response message, provided that it obeys the MIME restrictions for 2043 all "message" types regarding line length and encodings. 2045 Type name: message 2047 Subtype name: http 2049 Required parameters: none 2051 Optional parameters: version, msgtype 2053 version: The HTTP-Version number of the enclosed message (e.g., 2054 "1.1"). If not present, the version can be determined from the 2055 first line of the body. 2057 msgtype: The message type -- "request" or "response". If not 2058 present, the type can be determined from the first line of the 2059 body. 2061 Encoding considerations: only "7bit", "8bit", or "binary" are 2062 permitted 2064 Security considerations: none 2066 Interoperability considerations: none 2068 Published specification: This specification (see Section 9.3.1). 2070 Applications that use this media type: 2072 Additional information: 2074 Magic number(s): none 2076 File extension(s): none 2078 Macintosh file type code(s): none 2080 Person and email address to contact for further information: See 2081 Authors Section. 2083 Intended usage: COMMON 2085 Restrictions on usage: none 2087 Author/Change controller: IESG 2089 9.3.2. Internet Media Type application/http 2091 The application/http type can be used to enclose a pipeline of one or 2092 more HTTP request or response messages (not intermixed). 2094 Type name: application 2096 Subtype name: http 2098 Required parameters: none 2100 Optional parameters: version, msgtype 2101 version: The HTTP-Version number of the enclosed messages (e.g., 2102 "1.1"). If not present, the version can be determined from the 2103 first line of the body. 2105 msgtype: The message type -- "request" or "response". If not 2106 present, the type can be determined from the first line of the 2107 body. 2109 Encoding considerations: HTTP messages enclosed by this type are in 2110 "binary" format; use of an appropriate Content-Transfer-Encoding 2111 is required when transmitted via E-mail. 2113 Security considerations: none 2115 Interoperability considerations: none 2117 Published specification: This specification (see Section 9.3.2). 2119 Applications that use this media type: 2121 Additional information: 2123 Magic number(s): none 2125 File extension(s): none 2127 Macintosh file type code(s): none 2129 Person and email address to contact for further information: See 2130 Authors Section. 2132 Intended usage: COMMON 2134 Restrictions on usage: none 2136 Author/Change controller: IESG 2138 10. Security Considerations 2140 This section is meant to inform application developers, information 2141 providers, and users of the security limitations in HTTP/1.1 as 2142 described by this document. The discussion does not include 2143 definitive solutions to the problems revealed, though it does make 2144 some suggestions for reducing security risks. 2146 10.1. Personal Information 2148 HTTP clients are often privy to large amounts of personal information 2149 (e.g. the user's name, location, mail address, passwords, encryption 2150 keys, etc.), and SHOULD be very careful to prevent unintentional 2151 leakage of this information. We very strongly recommend that a 2152 convenient interface be provided for the user to control 2153 dissemination of such information, and that designers and 2154 implementors be particularly careful in this area. History shows 2155 that errors in this area often create serious security and/or privacy 2156 problems and generate highly adverse publicity for the implementor's 2157 company. 2159 10.2. Abuse of Server Log Information 2161 A server is in the position to save personal data about a user's 2162 requests which might identify their reading patterns or subjects of 2163 interest. This information is clearly confidential in nature and its 2164 handling can be constrained by law in certain countries. People 2165 using HTTP to provide data are responsible for ensuring that such 2166 material is not distributed without the permission of any individuals 2167 that are identifiable by the published results. 2169 10.3. Attacks Based On File and Path Names 2171 Implementations of HTTP origin servers SHOULD be careful to restrict 2172 the documents returned by HTTP requests to be only those that were 2173 intended by the server administrators. If an HTTP server translates 2174 HTTP URIs directly into file system calls, the server MUST take 2175 special care not to serve files that were not intended to be 2176 delivered to HTTP clients. For example, UNIX, Microsoft Windows, and 2177 other operating systems use ".." as a path component to indicate a 2178 directory level above the current one. On such a system, an HTTP 2179 server MUST disallow any such construct in the Request-URI if it 2180 would otherwise allow access to a resource outside those intended to 2181 be accessible via the HTTP server. Similarly, files intended for 2182 reference only internally to the server (such as access control 2183 files, configuration files, and script code) MUST be protected from 2184 inappropriate retrieval, since they might contain sensitive 2185 information. Experience has shown that minor bugs in such HTTP 2186 server implementations have turned into security risks. 2188 10.4. DNS Spoofing 2190 Clients using HTTP rely heavily on the Domain Name Service, and are 2191 thus generally prone to security attacks based on the deliberate mis- 2192 association of IP addresses and DNS names. Clients need to be 2193 cautious in assuming the continuing validity of an IP number/DNS name 2194 association. 2196 In particular, HTTP clients SHOULD rely on their name resolver for 2197 confirmation of an IP number/DNS name association, rather than 2198 caching the result of previous host name lookups. Many platforms 2199 already can cache host name lookups locally when appropriate, and 2200 they SHOULD be configured to do so. It is proper for these lookups 2201 to be cached, however, only when the TTL (Time To Live) information 2202 reported by the name server makes it likely that the cached 2203 information will remain useful. 2205 If HTTP clients cache the results of host name lookups in order to 2206 achieve a performance improvement, they MUST observe the TTL 2207 information reported by DNS. 2209 If HTTP clients do not observe this rule, they could be spoofed when 2210 a previously-accessed server's IP address changes. As network 2211 renumbering is expected to become increasingly common [RFC1900], the 2212 possibility of this form of attack will grow. Observing this 2213 requirement thus reduces this potential security vulnerability. 2215 This requirement also improves the load-balancing behavior of clients 2216 for replicated servers using the same DNS name and reduces the 2217 likelihood of a user's experiencing failure in accessing sites which 2218 use that strategy. 2220 10.5. Proxies and Caching 2222 By their very nature, HTTP proxies are men-in-the-middle, and 2223 represent an opportunity for man-in-the-middle attacks. Compromise 2224 of the systems on which the proxies run can result in serious 2225 security and privacy problems. Proxies have access to security- 2226 related information, personal information about individual users and 2227 organizations, and proprietary information belonging to users and 2228 content providers. A compromised proxy, or a proxy implemented or 2229 configured without regard to security and privacy considerations, 2230 might be used in the commission of a wide range of potential attacks. 2232 Proxy operators should protect the systems on which proxies run as 2233 they would protect any system that contains or transports sensitive 2234 information. In particular, log information gathered at proxies 2235 often contains highly sensitive personal information, and/or 2236 information about organizations. Log information should be carefully 2237 guarded, and appropriate guidelines for use developed and followed. 2238 (Section 10.2). 2240 Proxy implementors should consider the privacy and security 2241 implications of their design and coding decisions, and of the 2242 configuration options they provide to proxy operators (especially the 2243 default configuration). 2245 Users of a proxy need to be aware that they are no trustworthier than 2246 the people who run the proxy; HTTP itself cannot solve this problem. 2248 The judicious use of cryptography, when appropriate, may suffice to 2249 protect against a broad range of security and privacy attacks. Such 2250 cryptography is beyond the scope of the HTTP/1.1 specification. 2252 10.6. Denial of Service Attacks on Proxies 2254 They exist. They are hard to defend against. Research continues. 2255 Beware. 2257 11. Acknowledgments 2259 HTTP has evolved considerably over the years. It has benefited from 2260 a large and active developer community--the many people who have 2261 participated on the www-talk mailing list--and it is that community 2262 which has been most responsible for the success of HTTP and of the 2263 World-Wide Web in general. Marc Andreessen, Robert Cailliau, Daniel 2264 W. Connolly, Bob Denny, John Franks, Jean-Francois Groff, Phillip M. 2265 Hallam-Baker, Hakon W. Lie, Ari Luotonen, Rob McCool, Lou Montulli, 2266 Dave Raggett, Tony Sanders, and Marc VanHeyningen deserve special 2267 recognition for their efforts in defining early aspects of the 2268 protocol. 2270 This document has benefited greatly from the comments of all those 2271 participating in the HTTP-WG. In addition to those already 2272 mentioned, the following individuals have contributed to this 2273 specification: 2275 Gary Adams, Harald Tveit Alvestrand, Keith Ball, Brian Behlendorf, 2276 Paul Burchard, Maurizio Codogno, Mike Cowlishaw, Roman Czyborra, 2277 Michael A. Dolan, Daniel DuBois, David J. Fiander, Alan Freier, Marc 2278 Hedlund, Greg Herlihy, Koen Holtman, Alex Hopmann, Bob Jernigan, Shel 2279 Kaphan, Rohit Khare, John Klensin, Martijn Koster, Alexei Kosut, 2280 David M. Kristol, Daniel LaLiberte, Ben Laurie, Paul J. Leach, Albert 2281 Lunde, John C. Mallery, Jean-Philippe Martin-Flatin, Mitra, David 2282 Morris, Gavin Nicol, Ross Patterson, Bill Perry, Jeffrey Perry, Scott 2283 Powers, Owen Rees, Luigi Rizzo, David Robinson, Marc Salomon, Rich 2284 Salz, Allan M. Schiffman, Jim Seidman, Chuck Shotton, Eric W. Sink, 2285 Simon E. Spero, Richard N. Taylor, Robert S. Thau, Bill (BearHeart) 2286 Weinman, Francois Yergeau, Mary Ellen Zurko, Josh Cohen. 2288 Thanks to the "cave men" of Palo Alto. You know who you are. 2290 Jim Gettys (the editor of [RFC2616]) wishes particularly to thank Roy 2291 Fielding, the editor of [RFC2068], along with John Klensin, Jeff 2292 Mogul, Paul Leach, Dave Kristol, Koen Holtman, John Franks, Josh 2293 Cohen, Alex Hopmann, Scott Lawrence, and Larry Masinter for their 2294 help. And thanks go particularly to Jeff Mogul and Scott Lawrence 2295 for performing the "MUST/MAY/SHOULD" audit. 2297 The Apache Group, Anselm Baird-Smith, author of Jigsaw, and Henrik 2298 Frystyk implemented RFC 2068 early, and we wish to thank them for the 2299 discovery of many of the problems that this document attempts to 2300 rectify. 2302 This specification makes heavy use of the augmented BNF and generic 2303 constructs defined by David H. Crocker for [RFC5234]. Similarly, it 2304 reuses many of the definitions provided by Nathaniel Borenstein and 2305 Ned Freed for MIME [RFC2045]. We hope that their inclusion in this 2306 specification will help reduce past confusion over the relationship 2307 between HTTP and Internet mail message formats. 2309 12. References 2311 12.1. Normative References 2313 [ISO-8859-1] 2314 International Organization for Standardization, 2315 "Information technology -- 8-bit single-byte coded graphic 2316 character sets -- Part 1: Latin alphabet No. 1", ISO/ 2317 IEC 8859-1:1998, 1998. 2319 [Part2] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., 2320 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., 2321 and J. Reschke, Ed., "HTTP/1.1, part 2: Message 2322 Semantics", draft-ietf-httpbis-p2-semantics-05 (work in 2323 progress), November 2008. 2325 [Part3] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., 2326 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., 2327 and J. Reschke, Ed., "HTTP/1.1, part 3: Message Payload 2328 and Content Negotiation", draft-ietf-httpbis-p3-payload-05 2329 (work in progress), November 2008. 2331 [Part5] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., 2332 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., 2333 and J. Reschke, Ed., "HTTP/1.1, part 5: Range Requests and 2334 Partial Responses", draft-ietf-httpbis-p5-range-05 (work 2335 in progress), November 2008. 2337 [Part6] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., 2338 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., 2339 and J. Reschke, Ed., "HTTP/1.1, part 6: Caching", 2340 draft-ietf-httpbis-p6-cache-05 (work in progress), 2341 November 2008. 2343 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 2344 Extensions (MIME) Part One: Format of Internet Message 2345 Bodies", RFC 2045, November 1996. 2347 [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) 2348 Part Three: Message Header Extensions for Non-ASCII Text", 2349 RFC 2047, November 1996. 2351 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2352 Requirement Levels", BCP 14, RFC 2119, March 1997. 2354 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 2355 Resource Identifier (URI): Generic Syntax", RFC 3986, 2356 STD 66, January 2005. 2358 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 2359 Specifications: ABNF", STD 68, RFC 5234, January 2008. 2361 [USASCII] American National Standards Institute, "Coded Character 2362 Set -- 7-bit American Standard Code for Information 2363 Interchange", ANSI X3.4, 1986. 2365 12.2. Informative References 2367 [Kri2001] Kristol, D., "HTTP Cookies: Standards, Privacy, and 2368 Politics", ACM Transactions on Internet Technology Vol. 1, 2369 #2, November 2001, . 2371 [Nie1997] Nielsen, H., Gettys, J., Prud'hommeaux, E., Lie, H., and 2372 C. Lilley, "Network Performance Effects of HTTP/1.1, CSS1, 2373 and PNG", ACM Proceedings of the ACM SIGCOMM '97 2374 conference on Applications, technologies, architectures, 2375 and protocols for computer communication SIGCOMM '97, 2376 September 1997, 2377 . 2379 [Pad1995] Padmanabhan, V. and J. Mogul, "Improving HTTP Latency", 2380 Computer Networks and ISDN Systems v. 28, pp. 25-35, 2381 December 1995, 2382 . 2384 [RFC1123] Braden, R., "Requirements for Internet Hosts - Application 2385 and Support", STD 3, RFC 1123, October 1989. 2387 [RFC1305] Mills, D., "Network Time Protocol (Version 3) 2388 Specification, Implementation", RFC 1305, March 1992. 2390 [RFC1436] Anklesaria, F., McCahill, M., Lindner, P., Johnson, D., 2391 Torrey, D., and B. Alberti, "The Internet Gopher Protocol 2392 (a distributed document search and retrieval protocol)", 2393 RFC 1436, March 1993. 2395 [RFC1900] Carpenter, B. and Y. Rekhter, "Renumbering Needs Work", 2396 RFC 1900, February 1996. 2398 [RFC1945] Berners-Lee, T., Fielding, R., and H. Nielsen, "Hypertext 2399 Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996. 2401 [RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and T. 2402 Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", 2403 RFC 2068, January 1997. 2405 [RFC2109] Kristol, D. and L. Montulli, "HTTP State Management 2406 Mechanism", RFC 2109, February 1997. 2408 [RFC2145] Mogul, J., Fielding, R., Gettys, J., and H. Nielsen, "Use 2409 and Interpretation of HTTP Version Numbers", RFC 2145, 2410 May 1997. 2412 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 2413 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 2414 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 2416 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 2418 [RFC2965] Kristol, D. and L. Montulli, "HTTP State Management 2419 Mechanism", RFC 2965, October 2000. 2421 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration 2422 Procedures for Message Header Fields", BCP 90, RFC 3864, 2423 September 2004. 2425 [RFC3977] Feather, C., "Network News Transfer Protocol (NNTP)", 2426 RFC 3977, October 2006. 2428 [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and 2429 Registration Procedures", BCP 13, RFC 4288, December 2005. 2431 [RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and 2432 Registration Procedures for New URI Schemes", BCP 115, 2433 RFC 4395, February 2006. 2435 [RFC5322] Resnick, P., "Internet Message Format", RFC 5322, 2436 October 2008. 2438 [RFC822] Crocker, D., "Standard for the format of ARPA Internet 2439 text messages", STD 11, RFC 822, August 1982. 2441 [RFC959] Postel, J. and J. Reynolds, "File Transfer Protocol", 2442 STD 9, RFC 959, October 1985. 2444 [Spe] Spero, S., "Analysis of HTTP Performance Problems", 2445 . 2447 [Tou1998] Touch, J., Heidemann, J., and K. Obraczka, "Analysis of 2448 HTTP Performance", ISI Research Report ISI/RR-98-463, 2449 Aug 1998, . 2451 (original report dated Aug. 1996) 2453 [WAIS] Davis, F., Kahle, B., Morris, H., Salem, J., Shen, T., 2454 Wang, R., Sui, J., and M. Grinbaum, "WAIS Interface 2455 Protocol Prototype Functional Specification (v1.5)", 2456 Thinking Machines Corporation , April 1990. 2458 Appendix A. Tolerant Applications 2460 Although this document specifies the requirements for the generation 2461 of HTTP/1.1 messages, not all applications will be correct in their 2462 implementation. We therefore recommend that operational applications 2463 be tolerant of deviations whenever those deviations can be 2464 interpreted unambiguously. 2466 Clients SHOULD be tolerant in parsing the Status-Line and servers 2467 tolerant when parsing the Request-Line. In particular, they SHOULD 2468 accept any amount of SP or HTAB characters between fields, even 2469 though only a single SP is required. 2471 The line terminator for message-header fields is the sequence CRLF. 2472 However, we recommend that applications, when parsing such headers, 2473 recognize a single LF as a line terminator and ignore the leading CR. 2475 The character set of an entity-body SHOULD be labeled as the lowest 2476 common denominator of the character codes used within that body, with 2477 the exception that not labeling the entity is preferred over labeling 2478 the entity with the labels US-ASCII or ISO-8859-1. See [Part3]. 2480 Additional rules for requirements on parsing and encoding of dates 2481 and other potential problems with date encodings include: 2483 o HTTP/1.1 clients and caches SHOULD assume that an RFC-850 date 2484 which appears to be more than 50 years in the future is in fact in 2485 the past (this helps solve the "year 2000" problem). 2487 o An HTTP/1.1 implementation MAY internally represent a parsed 2488 Expires date as earlier than the proper value, but MUST NOT 2489 internally represent a parsed Expires date as later than the 2490 proper value. 2492 o All expiration-related calculations MUST be done in GMT. The 2493 local time zone MUST NOT influence the calculation or comparison 2494 of an age or expiration time. 2496 o If an HTTP header incorrectly carries a date value with a time 2497 zone other than GMT, it MUST be converted into GMT using the most 2498 conservative possible conversion. 2500 Appendix B. Conversion of Date Formats 2502 HTTP/1.1 uses a restricted set of date formats (Section 3.3.1) to 2503 simplify the process of date comparison. Proxies and gateways from 2504 other protocols SHOULD ensure that any Date header field present in a 2505 message conforms to one of the HTTP/1.1 formats and rewrite the date 2506 if necessary. 2508 Appendix C. Compatibility with Previous Versions 2510 HTTP has been in use by the World-Wide Web global information 2511 initiative since 1990. The first version of HTTP, later referred to 2512 as HTTP/0.9, was a simple protocol for hypertext data transfer across 2513 the Internet with only a single method and no metadata. HTTP/1.0, as 2514 defined by [RFC1945], added a range of request methods and MIME-like 2515 messaging that could include metadata about the data transferred and 2516 modifiers on the request/response semantics. However, HTTP/1.0 did 2517 not sufficiently take into consideration the effects of hierarchical 2518 proxies, caching, the need for persistent connections, or name-based 2519 virtual hosts. The proliferation of incompletely-implemented 2520 applications calling themselves "HTTP/1.0" further necessitated a 2521 protocol version change in order for two communicating applications 2522 to determine each other's true capabilities. 2524 HTTP/1.1 remains compatible with HTTP/1.0 by including more stringent 2525 requirements that enable reliable implementations, adding only those 2526 new features that will either be safely ignored by an HTTP/1.0 2527 recipient or only sent when communicating with a party advertising 2528 compliance with HTTP/1.1. 2530 It is beyond the scope of a protocol specification to mandate 2531 compliance with previous versions. HTTP/1.1 was deliberately 2532 designed, however, to make supporting previous versions easy. It is 2533 worth noting that, at the time of composing this specification 2534 (1996), we would expect commercial HTTP/1.1 servers to: 2536 o recognize the format of the Request-Line for HTTP/0.9, 1.0, and 2537 1.1 requests; 2539 o understand any valid request in the format of HTTP/0.9, 1.0, or 2540 1.1; 2542 o respond appropriately with a message in the same major version 2543 used by the client. 2545 And we would expect HTTP/1.1 clients to: 2547 o recognize the format of the Status-Line for HTTP/1.0 and 1.1 2548 responses; 2550 o understand any valid response in the format of HTTP/0.9, 1.0, or 2551 1.1. 2553 For most implementations of HTTP/1.0, each connection is established 2554 by the client prior to the request and closed by the server after 2555 sending the response. Some implementations implement the Keep-Alive 2556 version of persistent connections described in Section 19.7.1 of 2557 [RFC2068]. 2559 C.1. Changes from HTTP/1.0 2561 This section summarizes major differences between versions HTTP/1.0 2562 and HTTP/1.1. 2564 C.1.1. Changes to Simplify Multi-homed Web Servers and Conserve IP 2565 Addresses 2567 The requirements that clients and servers support the Host request- 2568 header, report an error if the Host request-header (Section 8.4) is 2569 missing from an HTTP/1.1 request, and accept absolute URIs 2570 (Section 5.1.2) are among the most important changes defined by this 2571 specification. 2573 Older HTTP/1.0 clients assumed a one-to-one relationship of IP 2574 addresses and servers; there was no other established mechanism for 2575 distinguishing the intended server of a request than the IP address 2576 to which that request was directed. The changes outlined above will 2577 allow the Internet, once older HTTP clients are no longer common, to 2578 support multiple Web sites from a single IP address, greatly 2579 simplifying large operational Web servers, where allocation of many 2580 IP addresses to a single host has created serious problems. The 2581 Internet will also be able to recover the IP addresses that have been 2582 allocated for the sole purpose of allowing special-purpose domain 2583 names to be used in root-level HTTP URLs. Given the rate of growth 2584 of the Web, and the number of servers already deployed, it is 2585 extremely important that all implementations of HTTP (including 2586 updates to existing HTTP/1.0 applications) correctly implement these 2587 requirements: 2589 o Both clients and servers MUST support the Host request-header. 2591 o A client that sends an HTTP/1.1 request MUST send a Host header. 2593 o Servers MUST report a 400 (Bad Request) error if an HTTP/1.1 2594 request does not include a Host request-header. 2596 o Servers MUST accept absolute URIs. 2598 C.2. Compatibility with HTTP/1.0 Persistent Connections 2600 Some clients and servers might wish to be compatible with some 2601 previous implementations of persistent connections in HTTP/1.0 2602 clients and servers. Persistent connections in HTTP/1.0 are 2603 explicitly negotiated as they are not the default behavior. HTTP/1.0 2604 experimental implementations of persistent connections are faulty, 2605 and the new facilities in HTTP/1.1 are designed to rectify these 2606 problems. The problem was that some existing 1.0 clients may be 2607 sending Keep-Alive to a proxy server that doesn't understand 2608 Connection, which would then erroneously forward it to the next 2609 inbound server, which would establish the Keep-Alive connection and 2610 result in a hung HTTP/1.0 proxy waiting for the close on the 2611 response. The result is that HTTP/1.0 clients must be prevented from 2612 using Keep-Alive when talking to proxies. 2614 However, talking to proxies is the most important use of persistent 2615 connections, so that prohibition is clearly unacceptable. Therefore, 2616 we need some other mechanism for indicating a persistent connection 2617 is desired, which is safe to use even when talking to an old proxy 2618 that ignores Connection. Persistent connections are the default for 2619 HTTP/1.1 messages; we introduce a new keyword (Connection: close) for 2620 declaring non-persistence. See Section 8.1. 2622 The original HTTP/1.0 form of persistent connections (the Connection: 2623 Keep-Alive and Keep-Alive header) is documented in [RFC2068]. 2625 C.3. Changes from RFC 2068 2627 This specification has been carefully audited to correct and 2628 disambiguate key word usage; RFC 2068 had many problems in respect to 2629 the conventions laid out in [RFC2119]. 2631 Transfer-coding and message lengths all interact in ways that 2632 required fixing exactly when chunked encoding is used (to allow for 2633 transfer encoding that may not be self delimiting); it was important 2634 to straighten out exactly how message lengths are computed. 2635 (Sections 3.4, 4.4, 8.2, see also [Part3], [Part5] and [Part6]) 2637 The use and interpretation of HTTP version numbers has been clarified 2638 by [RFC2145]. Require proxies to upgrade requests to highest 2639 protocol version they support to deal with problems discovered in 2640 HTTP/1.0 implementations (Section 3.1) 2642 Transfer-coding had significant problems, particularly with 2643 interactions with chunked encoding. The solution is that transfer- 2644 codings become as full fledged as content-codings. This involves 2645 adding an IANA registry for transfer-codings (separate from content 2646 codings), a new header field (TE) and enabling trailer headers in the 2647 future. Transfer encoding is a major performance benefit, so it was 2648 worth fixing [Nie1997]. TE also solves another, obscure, downward 2649 interoperability problem that could have occurred due to interactions 2650 between authentication trailers, chunked encoding and HTTP/1.0 2651 clients.(Section 3.4, 3.4.1, and 8.5) 2653 C.4. Changes from RFC 2616 2655 Rules about implicit linear white space between certain grammar 2656 productions have been removed; now it's only allowed when 2657 specifically pointed out in the ABNF. The CHAR rule does not allow 2658 the NUL character anymore (this affects the comment and quoted-string 2659 rules). Furthermore, the quoted-pair rule does not allow escaping 2660 NUL, CR or LF anymore. (Section 2.2) 2662 Clarify that HTTP-Version is case sensitive. (Section 3.1) 2664 Remove reference to non-existant identity transfer-coding value 2665 tokens. (Sections 3.4 and 4.4) 2667 Clarification that the chunk length does not include the count of the 2668 octets in the chunk header and trailer. (Section 3.4.1) 2669 Update use of abs_path production from RFC1808 to the path-absolute + 2670 query components of RFC3986. (Section 5.1.2) 2672 Clarify exactly when close connection options must be sent. 2673 (Section 8.1) 2675 Appendix D. Terminology 2677 This specification uses a number of terms to refer to the roles 2678 played by participants in, and objects of, the HTTP communication. 2680 connection 2682 A transport layer virtual circuit established between two programs 2683 for the purpose of communication. 2685 message 2687 The basic unit of HTTP communication, consisting of a structured 2688 sequence of octets matching the syntax defined in Section 4 and 2689 transmitted via the connection. 2691 request 2693 An HTTP request message, as defined in Section 5. 2695 response 2697 An HTTP response message, as defined in Section 6. 2699 resource 2701 A network data object or service that can be identified by a URI, 2702 as defined in Section 3.2. Resources may be available in multiple 2703 representations (e.g. multiple languages, data formats, size, and 2704 resolutions) or vary in other ways. 2706 entity 2708 The information transferred as the payload of a request or 2709 response. An entity consists of metainformation in the form of 2710 entity-header fields and content in the form of an entity-body, as 2711 described in Section 4 of [Part3]. 2713 representation 2714 An entity included with a response that is subject to content 2715 negotiation, as described in Section 5 of [Part3]. There may 2716 exist multiple representations associated with a particular 2717 response status. 2719 content negotiation 2721 The mechanism for selecting the appropriate representation when 2722 servicing a request, as described in Section 5 of [Part3]. The 2723 representation of entities in any response can be negotiated 2724 (including error responses). 2726 variant 2728 A resource may have one, or more than one, representation(s) 2729 associated with it at any given instant. Each of these 2730 representations is termed a `variant'. Use of the term `variant' 2731 does not necessarily imply that the resource is subject to content 2732 negotiation. 2734 client 2736 A program that establishes connections for the purpose of sending 2737 requests. 2739 user agent 2741 The client which initiates a request. These are often browsers, 2742 editors, spiders (web-traversing robots), or other end user tools. 2744 server 2746 An application program that accepts connections in order to 2747 service requests by sending back responses. Any given program may 2748 be capable of being both a client and a server; our use of these 2749 terms refers only to the role being performed by the program for a 2750 particular connection, rather than to the program's capabilities 2751 in general. Likewise, any server may act as an origin server, 2752 proxy, gateway, or tunnel, switching behavior based on the nature 2753 of each request. 2755 origin server 2757 The server on which a given resource resides or is to be created. 2759 proxy 2760 An intermediary program which acts as both a server and a client 2761 for the purpose of making requests on behalf of other clients. 2762 Requests are serviced internally or by passing them on, with 2763 possible translation, to other servers. A proxy MUST implement 2764 both the client and server requirements of this specification. A 2765 "transparent proxy" is a proxy that does not modify the request or 2766 response beyond what is required for proxy authentication and 2767 identification. A "non-transparent proxy" is a proxy that 2768 modifies the request or response in order to provide some added 2769 service to the user agent, such as group annotation services, 2770 media type transformation, protocol reduction, or anonymity 2771 filtering. Except where either transparent or non-transparent 2772 behavior is explicitly stated, the HTTP proxy requirements apply 2773 to both types of proxies. 2775 gateway 2777 A server which acts as an intermediary for some other server. 2778 Unlike a proxy, a gateway receives requests as if it were the 2779 origin server for the requested resource; the requesting client 2780 may not be aware that it is communicating with a gateway. 2782 tunnel 2784 An intermediary program which is acting as a blind relay between 2785 two connections. Once active, a tunnel is not considered a party 2786 to the HTTP communication, though the tunnel may have been 2787 initiated by an HTTP request. The tunnel ceases to exist when 2788 both ends of the relayed connections are closed. 2790 cache 2792 A program's local store of response messages and the subsystem 2793 that controls its message storage, retrieval, and deletion. A 2794 cache stores cacheable responses in order to reduce the response 2795 time and network bandwidth consumption on future, equivalent 2796 requests. Any client or server may include a cache, though a 2797 cache cannot be used by a server that is acting as a tunnel. 2799 cacheable 2801 A response is cacheable if a cache is allowed to store a copy of 2802 the response message for use in answering subsequent requests. 2803 The rules for determining the cacheability of HTTP responses are 2804 defined in Section 1 of [Part6]. Even if a resource is cacheable, 2805 there may be additional constraints on whether a cache can use the 2806 cached copy for a particular request. 2808 upstream/downstream 2810 Upstream and downstream describe the flow of a message: all 2811 messages flow from upstream to downstream. 2813 inbound/outbound 2815 Inbound and outbound refer to the request and response paths for 2816 messages: "inbound" means "traveling toward the origin server", 2817 and "outbound" means "traveling toward the user agent" 2819 Appendix E. Change Log (to be removed by RFC Editor before publication) 2821 E.1. Since RFC2616 2823 Extracted relevant partitions from [RFC2616]. 2825 E.2. Since draft-ietf-httpbis-p1-messaging-00 2827 Closed issues: 2829 o : "HTTP Version 2830 should be case sensitive" 2831 () 2833 o : "'unsafe' 2834 characters" () 2836 o : "Chunk Size 2837 Definition" () 2839 o : "Message Length" 2840 () 2842 o : "Media Type 2843 Registrations" () 2845 o : "URI includes 2846 query" () 2848 o : "No close on 2849 1xx responses" () 2851 o : "Remove 2852 'identity' token references" 2853 () 2855 o : "Import query 2856 BNF" 2858 o : "qdtext BNF" 2860 o : "Normative and 2861 Informative references" 2863 o : "RFC2606 2864 Compliance" 2866 o : "RFC977 2867 reference" 2869 o : "RFC1700 2870 references" 2872 o : "inconsistency 2873 in date format explanation" 2875 o : "Date reference 2876 typo" 2878 o : "Informative 2879 references" 2881 o : "ISO-8859-1 2882 Reference" 2884 o : "Normative up- 2885 to-date references" 2887 Other changes: 2889 o Update media type registrations to use RFC4288 template. 2891 o Use names of RFC4234 core rules DQUOTE and HTAB, fix broken ABNF 2892 for chunk-data (work in progress on 2893 ) 2895 E.3. Since draft-ietf-httpbis-p1-messaging-01 2897 Closed issues: 2899 o : "Bodies on GET 2900 (and other) requests" 2902 o : "Updating to 2903 RFC4288" 2905 o : "Status Code 2906 and Reason Phrase" 2908 o : "rel_path not 2909 used" 2911 Ongoing work on ABNF conversion 2912 (): 2914 o Get rid of duplicate BNF rule names ("host" -> "uri-host", 2915 "trailer" -> "trailer-part"). 2917 o Avoid underscore character in rule names ("http_URL" -> "http- 2918 URL", "abs_path" -> "path-absolute"). 2920 o Add rules for terms imported from URI spec ("absoluteURI", 2921 "authority", "path-absolute", "port", "query", "relativeURI", 2922 "host) -- these will have to be updated when switching over to 2923 RFC3986. 2925 o Synchronize core rules with RFC5234 (this includes a change to 2926 CHAR which now excludes NUL). 2928 o Get rid of prose rules that span multiple lines. 2930 o Get rid of unused rules LOALPHA and UPALPHA. 2932 o Move "Product Tokens" section (back) into Part 1, as "token" is 2933 used in the definition of the Upgrade header. 2935 o Add explicit references to BNF syntax and rules imported from 2936 other parts of the specification. 2938 o Rewrite prose rule "token" in terms of "tchar", rewrite prose rule 2939 "TEXT". 2941 E.4. Since draft-ietf-httpbis-p1-messaging-02 2943 Closed issues: 2945 o : "HTTP-date vs. 2946 rfc1123-date" 2948 o : "WS in quoted- 2949 pair" 2951 Ongoing work on IANA Message Header Registration 2952 (): 2954 o Reference RFC 3984, and update header registrations for headers 2955 defined in this document. 2957 Ongoing work on ABNF conversion 2958 (): 2960 o Replace string literals when the string really is case-sensitive 2961 (HTTP-Version). 2963 E.5. Since draft-ietf-httpbis-p1-messaging-03 2965 Closed issues: 2967 o : "Connection 2968 closing" 2970 o : "Move 2971 registrations and registry information to IANA Considerations" 2973 o : "need new URL 2974 for PAD1995 reference" 2976 o : "IANA 2977 Considerations: update HTTP URI scheme registration" 2979 o : "Cite HTTPS 2980 URI scheme definition" 2982 o : "List-type 2983 headers vs Set-Cookie" 2985 Ongoing work on ABNF conversion 2986 (): 2988 o Replace string literals when the string really is case-sensitive 2989 (HTTP-Date). 2991 o Replace HEX by HEXDIG for future consistence with RFC 5234's core 2992 rules. 2994 E.6. Since draft-ietf-httpbis-p1-messaging-04 2996 Closed issues: 2998 o : "Out-of-date 2999 reference for URIs" 3001 o : "RFC 2822 is 3002 updated by RFC 5322" 3004 Ongoing work on ABNF conversion 3005 (): 3007 o Use "/" instead of "|" for alternatives. 3009 o Get rid of RFC822 dependency; use RFC5234 plus extensions instead. 3011 o Only reference RFC 5234's core rules. 3013 o Introduce new ABNF rules for "bad" whitespace ("BWS"), optional 3014 whitespace ("OWS") and required whitespace ("RWS"). 3016 o Rewrite ABNFs to spell out whitespace rules, factor out header 3017 value format definitions. 3019 Index 3021 A 3022 application/http Media Type 45 3024 C 3025 cache 60 3026 cacheable 60 3027 client 59 3028 connection 58 3029 Connection header 35 3030 content negotiation 59 3031 Content-Length header 36 3033 D 3034 Date header 36 3035 downstream 61 3037 E 3038 entity 58 3040 G 3041 gateway 60 3042 Grammar 3043 absolute-URI 12 3044 asctime-date 14 3045 attribute 16 3046 authority 12 3047 BWS 9 3048 chunk 17 3049 chunk-data 17 3050 chunk-ext 17 3051 chunk-ext-name 17 3052 chunk-ext-val 17 3053 chunk-size 17 3054 Chunked-Body 17 3055 comment 10 3056 Connection 35 3057 connection-token 35 3058 Connection-v 35 3059 Content-Length 36 3060 Content-Length-v 36 3061 ctext 10 3062 Date 36 3063 Date-v 36 3064 date1 14 3065 date2 14 3066 date3 14 3067 extension-code 27 3068 extension-method 24 3069 field-content 20 3070 field-name 20 3071 field-value 20 3072 general-header 23 3073 generic-message 19 3074 Host 38 3075 Host-v 38 3076 HTTP-date 14 3077 HTTP-message 19 3078 HTTP-Prot-Name 11 3079 http-URI 13 3080 HTTP-Version 11 3081 last-chunk 17 3082 message-body 21 3083 message-header 20 3084 Method 24 3085 month 14 3086 obsolete-date 14 3087 OWS 9 3088 parameter 16 3089 path-absolute 12 3090 port 12 3091 product 18 3092 product-version 18 3093 protocol-name 42 3094 protocol-version 42 3095 pseudonym 42 3096 qdtext 10 3097 query 12 3098 quoted-pair 10 3099 quoted-string 10 3100 quoted-text 10 3101 Reason-Phrase 27 3102 received-by 42 3103 received-protocol 42 3104 relative-part 12 3105 relativeURI 12 3106 Request 24 3107 Request-Line 24 3108 Request-URI 24 3109 Response 26 3110 rfc850-date 14 3111 rfc1123-date 14 3112 RWS 9 3113 start-line 19 3114 Status-Code 27 3115 Status-Line 27 3116 t-codings 38 3117 tchar 10 3118 TE 38 3119 TE-v 38 3120 TEXT 9 3121 time 14 3122 token 10 3123 Trailer 40 3124 trailer-part 17 3125 Trailer-v 40 3126 transfer-coding 16 3127 Transfer-Encoding 40 3128 Transfer-Encoding-v 40 3129 transfer-extension 16 3130 Upgrade 41 3131 Upgrade-v 41 3132 uri-host 12 3133 URI-reference 12 3134 value 16 3135 Via 42 3136 Via-v 42 3137 weekday 14 3138 wkday 14 3140 H 3141 Headers 3142 Connection 35 3143 Content-Length 36 3144 Date 36 3145 Host 38 3146 TE 38 3147 Trailer 39 3148 Transfer-Encoding 40 3149 Upgrade 41 3150 Via 42 3151 Host header 38 3152 http URI scheme 13 3153 https URI scheme 13 3155 I 3156 inbound 61 3158 M 3159 Media Type 3160 application/http 45 3161 message/http 44 3162 message 58 3163 message/http Media Type 44 3165 O 3166 origin server 59 3167 outbound 61 3169 P 3170 proxy 59 3172 R 3173 representation 58 3174 request 58 3175 resource 58 3176 response 58 3178 S 3179 server 59 3181 T 3182 TE header 38 3183 Trailer header 39 3184 Transfer-Encoding header 40 3185 tunnel 60 3187 U 3188 Upgrade header 41 3189 upstream 61 3190 URI scheme 3191 http 13 3192 https 13 3193 user agent 59 3195 V 3196 variant 59 3197 Via header 42 3199 Authors' Addresses 3201 Roy T. Fielding (editor) 3202 Day Software 3203 23 Corporate Plaza DR, Suite 280 3204 Newport Beach, CA 92660 3205 USA 3207 Phone: +1-949-706-5300 3208 Fax: +1-949-706-5305 3209 Email: fielding@gbiv.com 3210 URI: http://roy.gbiv.com/ 3212 Jim Gettys 3213 One Laptop per Child 3214 21 Oak Knoll Road 3215 Carlisle, MA 01741 3216 USA 3218 Email: jg@laptop.org 3219 URI: http://www.laptop.org/ 3221 Jeffrey C. Mogul 3222 Hewlett-Packard Company 3223 HP Labs, Large Scale Systems Group 3224 1501 Page Mill Road, MS 1177 3225 Palo Alto, CA 94304 3226 USA 3228 Email: JeffMogul@acm.org 3229 Henrik Frystyk Nielsen 3230 Microsoft Corporation 3231 1 Microsoft Way 3232 Redmond, WA 98052 3233 USA 3235 Email: henrikn@microsoft.com 3237 Larry Masinter 3238 Adobe Systems, Incorporated 3239 345 Park Ave 3240 San Jose, CA 95110 3241 USA 3243 Email: LMM@acm.org 3244 URI: http://larry.masinter.net/ 3246 Paul J. Leach 3247 Microsoft Corporation 3248 1 Microsoft Way 3249 Redmond, WA 98052 3251 Email: paulle@microsoft.com 3253 Tim Berners-Lee 3254 World Wide Web Consortium 3255 MIT Computer Science and Artificial Intelligence Laboratory 3256 The Stata Center, Building 32 3257 32 Vassar Street 3258 Cambridge, MA 02139 3259 USA 3261 Email: timbl@w3.org 3262 URI: http://www.w3.org/People/Berners-Lee/ 3263 Yves Lafon (editor) 3264 World Wide Web Consortium 3265 W3C / ERCIM 3266 2004, rte des Lucioles 3267 Sophia-Antipolis, AM 06902 3268 France 3270 Email: ylafon@w3.org 3271 URI: http://www.raubacapeu.net/people/yves/ 3273 Julian F. Reschke (editor) 3274 greenbytes GmbH 3275 Hafenweg 16 3276 Muenster, NW 48155 3277 Germany 3279 Phone: +49 251 2807760 3280 Fax: +49 251 2807761 3281 Email: julian.reschke@greenbytes.de 3282 URI: http://greenbytes.de/tech/webdav/ 3284 Full Copyright Statement 3286 Copyright (C) The IETF Trust (2008). 3288 This document is subject to the rights, licenses and restrictions 3289 contained in BCP 78, and except as set forth therein, the authors 3290 retain all their rights. 3292 This document and the information contained herein are provided on an 3293 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 3294 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 3295 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 3296 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 3297 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 3298 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 3300 Intellectual Property 3302 The IETF takes no position regarding the validity or scope of any 3303 Intellectual Property Rights or other rights that might be claimed to 3304 pertain to the implementation or use of the technology described in 3305 this document or the extent to which any license under such rights 3306 might or might not be available; nor does it represent that it has 3307 made any independent effort to identify any such rights. Information 3308 on the procedures with respect to rights in RFC documents can be 3309 found in BCP 78 and BCP 79. 3311 Copies of IPR disclosures made to the IETF Secretariat and any 3312 assurances of licenses to be made available, or the result of an 3313 attempt made to obtain a general license or permission for the use of 3314 such proprietary rights by implementers or users of this 3315 specification can be obtained from the IETF on-line IPR repository at 3316 http://www.ietf.org/ipr. 3318 The IETF invites any interested party to bring to its attention any 3319 copyrights, patents or patent applications, or other proprietary 3320 rights that may cover technology that may be required to implement 3321 this standard. Please address the information to the IETF at 3322 ietf-ipr@ietf.org.