idnits 2.17.1 draft-ietf-httpbis-p1-messaging-18.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The abstract seems to indicate that this document obsoletes RFC2068, but the header doesn't have an 'Obsoletes:' line to match this. -- The draft header indicates that this document updates RFC2817, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC2817, updated by this document, for RFC5378 checks: 1998-11-18) -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 4, 2012) is 4467 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO-8859-1' == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p2-semantics-18 == Outdated reference: A later version (-20) exists of draft-ietf-httpbis-p3-payload-18 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p6-cache-18 ** Downref: Normative reference to an Informational RFC: RFC 1950 ** Downref: Normative reference to an Informational RFC: RFC 1951 ** Downref: Normative reference to an Informational RFC: RFC 1952 -- Possible downref: Non-RFC (?) normative reference: ref. 'USASCII' -- Obsolete informational reference (is this intentional?): RFC 2068 (Obsoleted by RFC 2616) -- Obsolete informational reference (is this intentional?): RFC 2145 (Obsoleted by RFC 7230) -- Obsolete informational reference (is this intentional?): RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) -- Obsolete informational reference (is this intentional?): RFC 2818 (Obsoleted by RFC 9110) -- Obsolete informational reference (is this intentional?): RFC 2965 (Obsoleted by RFC 6265) -- Obsolete informational reference (is this intentional?): RFC 4288 (Obsoleted by RFC 6838) -- Obsolete informational reference (is this intentional?): RFC 4395 (Obsoleted by RFC 7595) -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 15 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 HTTPbis Working Group R. Fielding, Ed. 3 Internet-Draft Adobe 4 Obsoletes: 2145,2616 (if approved) J. Gettys 5 Updates: 2817 (if approved) Alcatel-Lucent 6 Intended status: Standards Track J. Mogul 7 Expires: July 7, 2012 HP 8 H. Frystyk 9 Microsoft 10 L. Masinter 11 Adobe 12 P. Leach 13 Microsoft 14 T. Berners-Lee 15 W3C/MIT 16 Y. Lafon, Ed. 17 W3C 18 J. Reschke, Ed. 19 greenbytes 20 January 4, 2012 22 HTTP/1.1, part 1: URIs, Connections, and Message Parsing 23 draft-ietf-httpbis-p1-messaging-18 25 Abstract 27 The Hypertext Transfer Protocol (HTTP) is an application-level 28 protocol for distributed, collaborative, hypertext information 29 systems. HTTP has been in use by the World Wide Web global 30 information initiative since 1990. This document is Part 1 of the 31 seven-part specification that defines the protocol referred to as 32 "HTTP/1.1" and, taken together, obsoletes RFC 2616 and moves it to 33 historic status, along with its predecessor RFC 2068. 35 Part 1 provides an overview of HTTP and its associated terminology, 36 defines the "http" and "https" Uniform Resource Identifier (URI) 37 schemes, defines the generic message syntax and parsing requirements 38 for HTTP message frames, and describes general security concerns for 39 implementations. 41 This part also obsoletes RFCs 2145 (on HTTP version numbers) and 2817 42 (on using CONNECT for TLS upgrades) and moves them to historic 43 status. 45 Editorial Note (To be removed by RFC Editor) 47 Discussion of this draft should take place on the HTTPBIS working 48 group mailing list (ietf-http-wg@w3.org), which is archived at 49 . 51 The current issues list is at 52 and related 53 documents (including fancy diffs) can be found at 54 . 56 The changes in this draft are summarized in Appendix C.19. 58 Status of This Memo 60 This Internet-Draft is submitted in full conformance with the 61 provisions of BCP 78 and BCP 79. 63 Internet-Drafts are working documents of the Internet Engineering 64 Task Force (IETF). Note that other groups may also distribute 65 working documents as Internet-Drafts. The list of current Internet- 66 Drafts is at http://datatracker.ietf.org/drafts/current/. 68 Internet-Drafts are draft documents valid for a maximum of six months 69 and may be updated, replaced, or obsoleted by other documents at any 70 time. It is inappropriate to use Internet-Drafts as reference 71 material or to cite them other than as "work in progress." 73 This Internet-Draft will expire on July 7, 2012. 75 Copyright Notice 77 Copyright (c) 2012 IETF Trust and the persons identified as the 78 document authors. All rights reserved. 80 This document is subject to BCP 78 and the IETF Trust's Legal 81 Provisions Relating to IETF Documents 82 (http://trustee.ietf.org/license-info) in effect on the date of 83 publication of this document. Please review these documents 84 carefully, as they describe your rights and restrictions with respect 85 to this document. Code Components extracted from this document must 86 include Simplified BSD License text as described in Section 4.e of 87 the Trust Legal Provisions and are provided without warranty as 88 described in the Simplified BSD License. 90 This document may contain material from IETF Documents or IETF 91 Contributions published or made publicly available before November 92 10, 2008. The person(s) controlling the copyright in some of this 93 material may not have granted the IETF Trust the right to allow 94 modifications of such material outside the IETF Standards Process. 95 Without obtaining an adequate license from the person(s) controlling 96 the copyright in such materials, this document may not be modified 97 outside the IETF Standards Process, and derivative works of it may 98 not be created outside the IETF Standards Process, except to format 99 it for publication as an RFC or to translate it into languages other 100 than English. 102 Table of Contents 104 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6 105 1.1. Conformance and Error Handling . . . . . . . . . . . . . . 7 106 1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 7 107 1.2.1. ABNF Extension: #rule . . . . . . . . . . . . . . . . 8 108 1.2.2. Basic Rules . . . . . . . . . . . . . . . . . . . . . 9 109 2. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 9 110 2.1. Client/Server Messaging . . . . . . . . . . . . . . . . . 10 111 2.2. Message Orientation and Buffering . . . . . . . . . . . . 11 112 2.3. Connections and Transport Independence . . . . . . . . . . 12 113 2.4. Intermediaries . . . . . . . . . . . . . . . . . . . . . . 12 114 2.5. Caches . . . . . . . . . . . . . . . . . . . . . . . . . . 14 115 2.6. Protocol Versioning . . . . . . . . . . . . . . . . . . . 15 116 2.7. Uniform Resource Identifiers . . . . . . . . . . . . . . . 17 117 2.7.1. http URI scheme . . . . . . . . . . . . . . . . . . . 18 118 2.7.2. https URI scheme . . . . . . . . . . . . . . . . . . . 19 119 2.7.3. http and https URI Normalization and Comparison . . . 20 120 3. Message Format . . . . . . . . . . . . . . . . . . . . . . . . 21 121 3.1. Start Line . . . . . . . . . . . . . . . . . . . . . . . . 21 122 3.1.1. Request-Line . . . . . . . . . . . . . . . . . . . . . 22 123 3.1.2. Response Status-Line . . . . . . . . . . . . . . . . . 23 124 3.2. Header Fields . . . . . . . . . . . . . . . . . . . . . . 23 125 3.2.1. Field Parsing . . . . . . . . . . . . . . . . . . . . 25 126 3.2.2. Field Length . . . . . . . . . . . . . . . . . . . . . 25 127 3.2.3. Common Field ABNF Rules . . . . . . . . . . . . . . . 26 128 3.3. Message Body . . . . . . . . . . . . . . . . . . . . . . . 27 129 3.4. Handling Incomplete Messages . . . . . . . . . . . . . . . 30 130 3.5. Message Parsing Robustness . . . . . . . . . . . . . . . . 31 131 4. Message Routing . . . . . . . . . . . . . . . . . . . . . . . 31 132 4.1. Types of Request Target . . . . . . . . . . . . . . . . . 31 133 4.2. The Resource Identified by a Request . . . . . . . . . . . 33 134 4.3. Effective Request URI . . . . . . . . . . . . . . . . . . 34 135 5. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 35 136 5.1. Transfer Codings . . . . . . . . . . . . . . . . . . . . . 35 137 5.1.1. Chunked Transfer Coding . . . . . . . . . . . . . . . 36 138 5.1.2. Compression Codings . . . . . . . . . . . . . . . . . 38 139 5.1.3. Transfer Coding Registry . . . . . . . . . . . . . . . 39 140 5.2. Product Tokens . . . . . . . . . . . . . . . . . . . . . . 39 141 5.3. Quality Values . . . . . . . . . . . . . . . . . . . . . . 40 142 6. Connections . . . . . . . . . . . . . . . . . . . . . . . . . 40 143 6.1. Persistent Connections . . . . . . . . . . . . . . . . . . 40 144 6.1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . 40 145 6.1.2. Overall Operation . . . . . . . . . . . . . . . . . . 41 146 6.1.3. Proxy Servers . . . . . . . . . . . . . . . . . . . . 42 147 6.1.4. Practical Considerations . . . . . . . . . . . . . . . 45 148 6.1.5. Retrying Requests . . . . . . . . . . . . . . . . . . 46 149 6.2. Message Transmission Requirements . . . . . . . . . . . . 46 150 6.2.1. Persistent Connections and Flow Control . . . . . . . 46 151 6.2.2. Monitoring Connections for Error Status Messages . . . 46 152 6.2.3. Use of the 100 (Continue) Status . . . . . . . . . . . 46 153 7. Miscellaneous notes that might disappear . . . . . . . . . . . 48 154 7.1. Scheme aliases considered harmful . . . . . . . . . . . . 48 155 7.2. Use of HTTP for proxy communication . . . . . . . . . . . 49 156 7.3. Interception of HTTP for access control . . . . . . . . . 49 157 7.4. Use of HTTP by other protocols . . . . . . . . . . . . . . 49 158 7.5. Use of HTTP by media type specification . . . . . . . . . 49 159 8. Header Field Definitions . . . . . . . . . . . . . . . . . . . 49 160 8.1. Connection . . . . . . . . . . . . . . . . . . . . . . . . 49 161 8.2. Content-Length . . . . . . . . . . . . . . . . . . . . . . 51 162 8.3. Host . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 163 8.4. TE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 164 8.5. Trailer . . . . . . . . . . . . . . . . . . . . . . . . . 54 165 8.6. Transfer-Encoding . . . . . . . . . . . . . . . . . . . . 54 166 8.7. Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . 55 167 8.7.1. Upgrade Token Registry . . . . . . . . . . . . . . . . 56 168 8.8. Via . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 169 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 58 170 9.1. Header Field Registration . . . . . . . . . . . . . . . . 58 171 9.2. URI Scheme Registration . . . . . . . . . . . . . . . . . 59 172 9.3. Internet Media Type Registrations . . . . . . . . . . . . 59 173 9.3.1. Internet Media Type message/http . . . . . . . . . . . 59 174 9.3.2. Internet Media Type application/http . . . . . . . . . 61 175 9.4. Transfer Coding Registry . . . . . . . . . . . . . . . . . 62 176 9.5. Upgrade Token Registration . . . . . . . . . . . . . . . . 62 177 10. Security Considerations . . . . . . . . . . . . . . . . . . . 62 178 10.1. Personal Information . . . . . . . . . . . . . . . . . . . 63 179 10.2. Abuse of Server Log Information . . . . . . . . . . . . . 63 180 10.3. Attacks Based On File and Path Names . . . . . . . . . . . 63 181 10.4. DNS-related Attacks . . . . . . . . . . . . . . . . . . . 63 182 10.5. Proxies and Caching . . . . . . . . . . . . . . . . . . . 64 183 10.6. Protocol Element Size Overflows . . . . . . . . . . . . . 64 184 10.7. Denial of Service Attacks on Proxies . . . . . . . . . . . 65 185 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 65 186 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 66 187 12.1. Normative References . . . . . . . . . . . . . . . . . . . 66 188 12.2. Informative References . . . . . . . . . . . . . . . . . . 67 189 Appendix A. HTTP Version History . . . . . . . . . . . . . . . . 69 190 A.1. Changes from HTTP/1.0 . . . . . . . . . . . . . . . . . . 70 191 A.1.1. Multi-homed Web Servers . . . . . . . . . . . . . . . 70 192 A.1.2. Keep-Alive Connections . . . . . . . . . . . . . . . . 71 194 A.2. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 71 195 Appendix B. Collected ABNF . . . . . . . . . . . . . . . . . . . 72 196 Appendix C. Change Log (to be removed by RFC Editor before 197 publication) . . . . . . . . . . . . . . . . . . . . 75 198 C.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 75 199 C.2. Since draft-ietf-httpbis-p1-messaging-00 . . . . . . . . . 75 200 C.3. Since draft-ietf-httpbis-p1-messaging-01 . . . . . . . . . 77 201 C.4. Since draft-ietf-httpbis-p1-messaging-02 . . . . . . . . . 78 202 C.5. Since draft-ietf-httpbis-p1-messaging-03 . . . . . . . . . 78 203 C.6. Since draft-ietf-httpbis-p1-messaging-04 . . . . . . . . . 79 204 C.7. Since draft-ietf-httpbis-p1-messaging-05 . . . . . . . . . 79 205 C.8. Since draft-ietf-httpbis-p1-messaging-06 . . . . . . . . . 80 206 C.9. Since draft-ietf-httpbis-p1-messaging-07 . . . . . . . . . 81 207 C.10. Since draft-ietf-httpbis-p1-messaging-08 . . . . . . . . . 82 208 C.11. Since draft-ietf-httpbis-p1-messaging-09 . . . . . . . . . 82 209 C.12. Since draft-ietf-httpbis-p1-messaging-10 . . . . . . . . . 82 210 C.13. Since draft-ietf-httpbis-p1-messaging-11 . . . . . . . . . 83 211 C.14. Since draft-ietf-httpbis-p1-messaging-12 . . . . . . . . . 83 212 C.15. Since draft-ietf-httpbis-p1-messaging-13 . . . . . . . . . 84 213 C.16. Since draft-ietf-httpbis-p1-messaging-14 . . . . . . . . . 84 214 C.17. Since draft-ietf-httpbis-p1-messaging-15 . . . . . . . . . 85 215 C.18. Since draft-ietf-httpbis-p1-messaging-16 . . . . . . . . . 85 216 C.19. Since draft-ietf-httpbis-p1-messaging-17 . . . . . . . . . 85 217 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 219 1. Introduction 221 The Hypertext Transfer Protocol (HTTP) is an application-level 222 request/response protocol that uses extensible semantics and MIME- 223 like message payloads for flexible interaction with network-based 224 hypertext information systems. HTTP relies upon the Uniform Resource 225 Identifier (URI) standard [RFC3986] to indicate the target resource 226 and relationships between resources. Messages are passed in a format 227 similar to that used by Internet mail [RFC5322] and the Multipurpose 228 Internet Mail Extensions (MIME) [RFC2045] (see Appendix A of [Part3] 229 for the differences between HTTP and MIME messages). 231 HTTP is a generic interface protocol for information systems. It is 232 designed to hide the details of how a service is implemented by 233 presenting a uniform interface to clients that is independent of the 234 types of resources provided. Likewise, servers do not need to be 235 aware of each client's purpose: an HTTP request can be considered in 236 isolation rather than being associated with a specific type of client 237 or a predetermined sequence of application steps. The result is a 238 protocol that can be used effectively in many different contexts and 239 for which implementations can evolve independently over time. 241 HTTP is also designed for use as an intermediation protocol for 242 translating communication to and from non-HTTP information systems. 243 HTTP proxies and gateways can provide access to alternative 244 information services by translating their diverse protocols into a 245 hypertext format that can be viewed and manipulated by clients in the 246 same way as HTTP services. 248 One consequence of HTTP flexibility is that the protocol cannot be 249 defined in terms of what occurs behind the interface. Instead, we 250 are limited to defining the syntax of communication, the intent of 251 received communication, and the expected behavior of recipients. If 252 the communication is considered in isolation, then successful actions 253 ought to be reflected in corresponding changes to the observable 254 interface provided by servers. However, since multiple clients might 255 act in parallel and perhaps at cross-purposes, we cannot require that 256 such changes be observable beyond the scope of a single response. 258 This document is Part 1 of the seven-part specification of HTTP, 259 defining the protocol referred to as "HTTP/1.1", obsoleting [RFC2616] 260 and [RFC2145]. Part 1 describes the architectural elements that are 261 used or referred to in HTTP, defines the "http" and "https" URI 262 schemes, describes overall network operation and connection 263 management, and defines HTTP message framing and forwarding 264 requirements. Our goal is to define all of the mechanisms necessary 265 for HTTP message handling that are independent of message semantics, 266 thereby defining the complete set of requirements for message parsers 267 and message-forwarding intermediaries. 269 1.1. Conformance and Error Handling 271 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 272 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 273 document are to be interpreted as described in [RFC2119]. 275 This document defines conformance criteria for several roles in HTTP 276 communication, including Senders, Recipients, Clients, Servers, User- 277 Agents, Origin Servers, Intermediaries, Proxies and Gateways. See 278 Section 2 for definitions of these terms. 280 An implementation is considered conformant if it complies with all of 281 the requirements associated with its role(s). Note that SHOULD-level 282 requirements are relevant here, unless one of the documented 283 exceptions is applicable. 285 This document also uses ABNF to define valid protocol elements 286 (Section 1.2). In addition to the prose requirements placed upon 287 them, Senders MUST NOT generate protocol elements that are invalid. 289 Unless noted otherwise, Recipients MAY take steps to recover a usable 290 protocol element from an invalid construct. However, HTTP does not 291 define specific error handling mechanisms, except in cases where it 292 has direct impact on security. This is because different uses of the 293 protocol require different error handling strategies; for example, a 294 Web browser may wish to transparently recover from a response where 295 the Location header field doesn't parse according to the ABNF, 296 whereby in a systems control protocol using HTTP, this type of error 297 recovery could lead to dangerous consequences. 299 1.2. Syntax Notation 301 This specification uses the Augmented Backus-Naur Form (ABNF) 302 notation of [RFC5234]. 304 The following core rules are included by reference, as defined in 305 [RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF 306 (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote), 307 HEXDIG (hexadecimal 0-9/A-F/a-f), HTAB (horizontal tab), LF (line 308 feed), OCTET (any 8-bit sequence of data), SP (space), and VCHAR (any 309 visible [USASCII] character). 311 As a syntactic convention, ABNF rule names prefixed with "obs-" 312 denote "obsolete" grammar rules that appear for historical reasons. 314 1.2.1. ABNF Extension: #rule 316 The #rule extension to the ABNF rules of [RFC5234] is used to improve 317 readability. 319 A construct "#" is defined, similar to "*", for defining comma- 320 delimited lists of elements. The full form is "#element" 321 indicating at least and at most elements, each separated by a 322 single comma (",") and optional whitespace (OWS, Section 1.2.2). 324 Thus, 326 1#element => element *( OWS "," OWS element ) 328 and: 330 #element => [ 1#element ] 332 and for n >= 1 and m > 1: 334 #element => element *( OWS "," OWS element ) 336 For compatibility with legacy list rules, recipients SHOULD accept 337 empty list elements. In other words, consumers would follow the list 338 productions: 340 #element => [ ( "," / element ) *( OWS "," [ OWS element ] ) ] 342 1#element => *( "," OWS ) element *( OWS "," [ OWS element ] ) 344 Note that empty elements do not contribute to the count of elements 345 present, though. 347 For example, given these ABNF productions: 349 example-list = 1#example-list-elmt 350 example-list-elmt = token ; see Section 3.2.3 352 Then these are valid values for example-list (not including the 353 double quotes, which are present for delimitation only): 355 "foo,bar" 356 "foo ,bar," 357 "foo , ,bar,charlie " 359 But these values would be invalid, as at least one non-empty element 360 is required: 362 "" 363 "," 364 ", ," 366 Appendix B shows the collected ABNF, with the list rules expanded as 367 explained above. 369 1.2.2. Basic Rules 371 This specification uses three rules to denote the use of linear 372 whitespace: OWS (optional whitespace), RWS (required whitespace), and 373 BWS ("bad" whitespace). 375 The OWS rule is used where zero or more linear whitespace octets 376 might appear. OWS SHOULD either not be produced or be produced as a 377 single SP. Multiple OWS octets that occur within field-content 378 SHOULD either be replaced with a single SP or transformed to all SP 379 octets (each octet other than SP replaced with SP) before 380 interpreting the field value or forwarding the message downstream. 382 RWS is used when at least one linear whitespace octet is required to 383 separate field tokens. RWS SHOULD be produced as a single SP. 384 Multiple RWS octets that occur within field-content SHOULD either be 385 replaced with a single SP or transformed to all SP octets before 386 interpreting the field value or forwarding the message downstream. 388 BWS is used where the grammar allows optional whitespace for 389 historical reasons but senders SHOULD NOT produce it in messages. 390 HTTP/1.1 recipients MUST accept such bad optional whitespace and 391 remove it before interpreting the field value or forwarding the 392 message downstream. 394 OWS = *( SP / HTAB / obs-fold ) 395 ; "optional" whitespace 396 RWS = 1*( SP / HTAB / obs-fold ) 397 ; "required" whitespace 398 BWS = OWS 399 ; "bad" whitespace 400 obs-fold = CRLF ( SP / HTAB ) 401 ; obsolete line folding 402 ; see Section 3.2.1 404 2. Architecture 406 HTTP was created for the World Wide Web architecture and has evolved 407 over time to support the scalability needs of a worldwide hypertext 408 system. Much of that architecture is reflected in the terminology 409 and syntax productions used to define HTTP. 411 2.1. Client/Server Messaging 413 HTTP is a stateless request/response protocol that operates by 414 exchanging messages (Section 3) across a reliable transport or 415 session-layer "connection". An HTTP "client" is a program that 416 establishes a connection to a server for the purpose of sending one 417 or more HTTP requests. An HTTP "server" is a program that accepts 418 connections in order to service HTTP requests by sending HTTP 419 responses. 421 Note that the terms client and server refer only to the roles that 422 these programs perform for a particular connection. The same program 423 might act as a client on some connections and a server on others. We 424 use the term "user agent" to refer to the program that initiates a 425 request, such as a WWW browser, editor, or spider (web-traversing 426 robot), and the term "origin server" to refer to the program that can 427 originate authoritative responses to a request. For general 428 requirements, we use the term "sender" to refer to whichever 429 component sent a given message and the term "recipient" to refer to 430 any component that receives the message. 432 Note: The term 'user agent' covers both those situations where 433 there is a user (human) interacting with the software agent (and 434 for which user interface or interactive suggestions might be made, 435 e.g., warning the user or given the user an option in the case of 436 security or privacy options) and also those where the software 437 agent may act autonomously. 439 Most HTTP communication consists of a retrieval request (GET) for a 440 representation of some resource identified by a URI. In the simplest 441 case, this might be accomplished via a single bidirectional 442 connection (===) between the user agent (UA) and the origin server 443 (O). 445 request > 446 UA ======================================= O 447 < response 449 A client sends an HTTP request to the server in the form of a request 450 message, beginning with a request-line that includes a method, URI, 451 and protocol version (Section 3.1.1), followed by MIME-like header 452 fields containing request modifiers, client information, and payload 453 metadata (Section 3.2), an empty line to indicate the end of the 454 header section, and finally a message body containing the payload 455 body (if any, Section 3.3). 457 A server responds to the client's request by sending an HTTP response 458 message, beginning with a status line that includes the protocol 459 version, a success or error code, and textual reason phrase 460 (Section 3.1.2), followed by MIME-like header fields containing 461 server information, resource metadata, and payload metadata 462 (Section 3.2), an empty line to indicate the end of the header 463 section, and finally a message body containing the payload body (if 464 any, Section 3.3). 466 Note that 1xx responses (Section 7.1 of [Part2]) are not final; 467 therefore, a server can send zero or more 1xx responses, followed by 468 exactly one final response (with any other status code). 470 The following example illustrates a typical message exchange for a 471 GET request on the URI "http://www.example.com/hello.txt": 473 client request: 475 GET /hello.txt HTTP/1.1 476 User-Agent: curl/7.16.3 libcurl/7.16.3 OpenSSL/0.9.7l zlib/1.2.3 477 Host: www.example.com 478 Accept: */* 480 server response: 482 HTTP/1.1 200 OK 483 Date: Mon, 27 Jul 2009 12:28:53 GMT 484 Server: Apache 485 Last-Modified: Wed, 22 Jul 2009 19:15:56 GMT 486 ETag: "34aa387-d-1568eb00" 487 Accept-Ranges: bytes 488 Content-Length: 14 489 Vary: Accept-Encoding 490 Content-Type: text/plain 492 Hello World! 494 2.2. Message Orientation and Buffering 496 Fundamentally, HTTP is a message-based protocol. Although message 497 bodies can be chunked (Section 5.1.1) and implementations often make 498 parts of a message available progressively, this is not required, and 499 some widely-used implementations only make a message available when 500 it is complete. Furthermore, while most proxies will progressively 501 stream messages, some amount of buffering will take place, and some 502 proxies might buffer messages to perform transformations, check 503 content or provide other services. 505 Therefore, extensions to and uses of HTTP cannot rely on the 506 availability of a partial message, or assume that messages will not 507 be buffered. There are strategies that can be used to test for 508 buffering in a given connection, but it should be understood that 509 behaviors can differ across connections, and between requests and 510 responses. 512 Recipients MUST consider every message in a connection in isolation; 513 because HTTP is a stateless protocol, it cannot be assumed that two 514 requests on the same connection are from the same client or share any 515 other common attributes. In particular, intermediaries might mix 516 requests from different clients into a single server connection. 517 Note that some existing HTTP extensions (e.g., [RFC4559]) violate 518 this requirement, thereby potentially causing interoperability and 519 security problems. 521 2.3. Connections and Transport Independence 523 HTTP messaging is independent of the underlying transport or session- 524 layer connection protocol(s). HTTP only presumes a reliable 525 transport with in-order delivery of requests and the corresponding 526 in-order delivery of responses. The mapping of HTTP request and 527 response structures onto the data units of the underlying transport 528 protocol is outside the scope of this specification. 530 The specific connection protocols to be used for an interaction are 531 determined by client configuration and the target resource's URI. 532 For example, the "http" URI scheme (Section 2.7.1) indicates a 533 default connection of TCP over IP, with a default TCP port of 80, but 534 the client might be configured to use a proxy via some other 535 connection port or protocol instead of using the defaults. 537 A connection might be used for multiple HTTP request/response 538 exchanges, as defined in Section 6.1. 540 2.4. Intermediaries 542 HTTP enables the use of intermediaries to satisfy requests through a 543 chain of connections. There are three common forms of HTTP 544 intermediary: proxy, gateway, and tunnel. In some cases, a single 545 intermediary might act as an origin server, proxy, gateway, or 546 tunnel, switching behavior based on the nature of each request. 548 > > > > 549 UA =========== A =========== B =========== C =========== O 550 < < < < 552 The figure above shows three intermediaries (A, B, and C) between the 553 user agent and origin server. A request or response message that 554 travels the whole chain will pass through four separate connections. 555 Some HTTP communication options might apply only to the connection 556 with the nearest, non-tunnel neighbor, only to the end-points of the 557 chain, or to all connections along the chain. Although the diagram 558 is linear, each participant might be engaged in multiple, 559 simultaneous communications. For example, B might be receiving 560 requests from many clients other than A, and/or forwarding requests 561 to servers other than C, at the same time that it is handling A's 562 request. 564 We use the terms "upstream" and "downstream" to describe various 565 requirements in relation to the directional flow of a message: all 566 messages flow from upstream to downstream. Likewise, we use the 567 terms inbound and outbound to refer to directions in relation to the 568 request path: "inbound" means toward the origin server and "outbound" 569 means toward the user agent. 571 A "proxy" is a message forwarding agent that is selected by the 572 client, usually via local configuration rules, to receive requests 573 for some type(s) of absolute URI and attempt to satisfy those 574 requests via translation through the HTTP interface. Some 575 translations are minimal, such as for proxy requests for "http" URIs, 576 whereas other requests might require translation to and from entirely 577 different application-layer protocols. Proxies are often used to 578 group an organization's HTTP requests through a common intermediary 579 for the sake of security, annotation services, or shared caching. 581 An HTTP-to-HTTP proxy is called a "transforming proxy" if it is 582 designed or configured to modify request or response messages in a 583 semantically meaningful way (i.e., modifications, beyond those 584 required by normal HTTP processing, that change the message in a way 585 that would be significant to the original sender or potentially 586 significant to downstream recipients). For example, a transforming 587 proxy might be acting as a shared annotation server (modifying 588 responses to include references to a local annotation database), a 589 malware filter, a format transcoder, or an intranet-to-Internet 590 privacy filter. Such transformations are presumed to be desired by 591 the client (or client organization) that selected the proxy and are 592 beyond the scope of this specification. However, when a proxy is not 593 intended to transform a given message, we use the term "non- 594 transforming proxy" to target requirements that preserve HTTP message 595 semantics. See Section 7.2.4 of [Part2] and Section 3.6 of [Part6] 596 for status and warning codes related to transformations. 598 A "gateway" (a.k.a., "reverse proxy") is a receiving agent that acts 599 as a layer above some other server(s) and translates the received 600 requests to the underlying server's protocol. Gateways are often 601 used to encapsulate legacy or untrusted information services, to 602 improve server performance through "accelerator" caching, and to 603 enable partitioning or load-balancing of HTTP services across 604 multiple machines. 606 A gateway behaves as an origin server on its outbound connection and 607 as a user agent on its inbound connection. All HTTP requirements 608 applicable to an origin server also apply to the outbound 609 communication of a gateway. A gateway communicates with inbound 610 servers using any protocol that it desires, including private 611 extensions to HTTP that are outside the scope of this specification. 612 However, an HTTP-to-HTTP gateway that wishes to interoperate with 613 third-party HTTP servers MUST comply with HTTP user agent 614 requirements on the gateway's inbound connection and MUST implement 615 the Connection (Section 8.1) and Via (Section 8.8) header fields for 616 both connections. 618 A "tunnel" acts as a blind relay between two connections without 619 changing the messages. Once active, a tunnel is not considered a 620 party to the HTTP communication, though the tunnel might have been 621 initiated by an HTTP request. A tunnel ceases to exist when both 622 ends of the relayed connection are closed. Tunnels are used to 623 extend a virtual connection through an intermediary, such as when 624 transport-layer security is used to establish private communication 625 through a shared firewall proxy. 627 In addition, there may exist network intermediaries that are not 628 considered part of the HTTP communication but nevertheless act as 629 filters or redirecting agents (usually violating HTTP semantics, 630 causing security problems, and otherwise making a mess of things). 631 Such a network intermediary, often referred to as an "interception 632 proxy" [RFC3040], "transparent proxy" [RFC1919], or "captive portal", 633 differs from an HTTP proxy because it has not been selected by the 634 client. Instead, the network intermediary redirects outgoing TCP 635 port 80 packets (and occasionally other common port traffic) to an 636 internal HTTP server. Interception proxies are commonly found on 637 public network access points, as a means of enforcing account 638 subscription prior to allowing use of non-local Internet services, 639 and within corporate firewalls to enforce network usage policies. 640 They are indistinguishable from a man-in-the-middle attack. 642 2.5. Caches 644 A "cache" is a local store of previous response messages and the 645 subsystem that controls its message storage, retrieval, and deletion. 646 A cache stores cacheable responses in order to reduce the response 647 time and network bandwidth consumption on future, equivalent 648 requests. Any client or server MAY employ a cache, though a cache 649 cannot be used by a server while it is acting as a tunnel. 651 The effect of a cache is that the request/response chain is shortened 652 if one of the participants along the chain has a cached response 653 applicable to that request. The following illustrates the resulting 654 chain if B has a cached copy of an earlier response from O (via C) 655 for a request which has not been cached by UA or A. 657 > > 658 UA =========== A =========== B - - - - - - C - - - - - - O 659 < < 661 A response is "cacheable" if a cache is allowed to store a copy of 662 the response message for use in answering subsequent requests. Even 663 when a response is cacheable, there might be additional constraints 664 placed by the client or by the origin server on when that cached 665 response can be used for a particular request. HTTP requirements for 666 cache behavior and cacheable responses are defined in Section 2 of 667 [Part6]. 669 There are a wide variety of architectures and configurations of 670 caches and proxies deployed across the World Wide Web and inside 671 large organizations. These systems include national hierarchies of 672 proxy caches to save transoceanic bandwidth, systems that broadcast 673 or multicast cache entries, organizations that distribute subsets of 674 cached data via optical media, and so on. 676 2.6. Protocol Versioning 678 HTTP uses a "." numbering scheme to indicate versions 679 of the protocol. This specification defines version "1.1". The 680 protocol version as a whole indicates the sender's compliance with 681 the set of requirements laid out in that version's corresponding 682 specification of HTTP. 684 The version of an HTTP message is indicated by an HTTP-Version field 685 in the first line of the message. HTTP-Version is case-sensitive. 687 HTTP-Version = HTTP-Prot-Name "/" DIGIT "." DIGIT 688 HTTP-Prot-Name = %x48.54.54.50 ; "HTTP", case-sensitive 690 The HTTP version number consists of two decimal digits separated by a 691 "." (period or decimal point). The first digit ("major version") 692 indicates the HTTP messaging syntax, whereas the second digit ("minor 693 version") indicates the highest minor version to which the sender is 694 at least conditionally compliant and able to understand for future 695 communication. The minor version advertises the sender's 696 communication capabilities even when the sender is only using a 697 backwards-compatible subset of the protocol, thereby letting the 698 recipient know that more advanced features can be used in response 699 (by servers) or in future requests (by clients). 701 When an HTTP/1.1 message is sent to an HTTP/1.0 recipient [RFC1945] 702 or a recipient whose version is unknown, the HTTP/1.1 message is 703 constructed such that it can be interpreted as a valid HTTP/1.0 704 message if all of the newer features are ignored. This specification 705 places recipient-version requirements on some new features so that a 706 compliant sender will only use compatible features until it has 707 determined, through configuration or the receipt of a message, that 708 the recipient supports HTTP/1.1. 710 The interpretation of an HTTP header field does not change between 711 minor versions of the same major version, though the default behavior 712 of a recipient in the absence of such a field can change. Unless 713 specified otherwise, header fields defined in HTTP/1.1 are defined 714 for all versions of HTTP/1.x. In particular, the Host and Connection 715 header fields ought to be implemented by all HTTP/1.x implementations 716 whether or not they advertise compliance with HTTP/1.1. 718 New header fields can be defined such that, when they are understood 719 by a recipient, they might override or enhance the interpretation of 720 previously defined header fields. When an implementation receives an 721 unrecognized header field, the recipient MUST ignore that header 722 field for local processing regardless of the message's HTTP version. 723 An unrecognized header field received by a proxy MUST be forwarded 724 downstream unless the header field's field-name is listed in the 725 message's Connection header-field (see Section 8.1). These 726 requirements allow HTTP's functionality to be enhanced without 727 requiring prior update of all compliant intermediaries. 729 Intermediaries that process HTTP messages (i.e., all intermediaries 730 other than those acting as a tunnel) MUST send their own HTTP-Version 731 in forwarded messages. In other words, they MUST NOT blindly forward 732 the first line of an HTTP message without ensuring that the protocol 733 version matches what the intermediary understands, and is at least 734 conditionally compliant to, for both the receiving and sending of 735 messages. Forwarding an HTTP message without rewriting the HTTP- 736 Version might result in communication errors when downstream 737 recipients use the message sender's version to determine what 738 features are safe to use for later communication with that sender. 740 An HTTP client SHOULD send a request version equal to the highest 741 version for which the client is at least conditionally compliant and 742 whose major version is no higher than the highest version supported 743 by the server, if this is known. An HTTP client MUST NOT send a 744 version for which it is not at least conditionally compliant. 746 An HTTP client MAY send a lower request version if it is known that 747 the server incorrectly implements the HTTP specification, but only 748 after the client has attempted at least one normal request and 749 determined from the response status or header fields (e.g., Server) 750 that the server improperly handles higher request versions. 752 An HTTP server SHOULD send a response version equal to the highest 753 version for which the server is at least conditionally compliant and 754 whose major version is less than or equal to the one received in the 755 request. An HTTP server MUST NOT send a version for which it is not 756 at least conditionally compliant. A server MAY send a 505 (HTTP 757 Version Not Supported) response if it cannot send a response using 758 the major version used in the client's request. 760 An HTTP server MAY send an HTTP/1.0 response to an HTTP/1.0 request 761 if it is known or suspected that the client incorrectly implements 762 the HTTP specification and is incapable of correctly processing later 763 version responses, such as when a client fails to parse the version 764 number correctly or when an intermediary is known to blindly forward 765 the HTTP-Version even when it doesn't comply with the given minor 766 version of the protocol. Such protocol downgrades SHOULD NOT be 767 performed unless triggered by specific client attributes, such as 768 when one or more of the request header fields (e.g., User-Agent) 769 uniquely match the values sent by a client known to be in error. 771 The intention of HTTP's versioning design is that the major number 772 will only be incremented if an incompatible message syntax is 773 introduced, and that the minor number will only be incremented when 774 changes made to the protocol have the effect of adding to the message 775 semantics or implying additional capabilities of the sender. 776 However, the minor version was not incremented for the changes 777 introduced between [RFC2068] and [RFC2616], and this revision is 778 specifically avoiding any such changes to the protocol. 780 2.7. Uniform Resource Identifiers 782 Uniform Resource Identifiers (URIs) [RFC3986] are used throughout 783 HTTP as the means for identifying resources. URI references are used 784 to target requests, indicate redirects, and define relationships. 785 HTTP does not limit what a resource might be; it merely defines an 786 interface that can be used to interact with a resource via HTTP. 787 More information on the scope of URIs and resources can be found in 788 [RFC3986]. 790 This specification adopts the definitions of "URI-reference", 791 "absolute-URI", "relative-part", "port", "host", "path-abempty", 792 "path-absolute", "query", and "authority" from the URI generic syntax 793 [RFC3986]. In addition, we define a partial-URI rule for protocol 794 elements that allow a relative URI but not a fragment. 796 URI-reference = 797 absolute-URI = 798 relative-part = 799 authority = 800 path-abempty = 801 path-absolute = 802 port = 803 query = 804 uri-host = 806 partial-URI = relative-part [ "?" query ] 808 Each protocol element in HTTP that allows a URI reference will 809 indicate in its ABNF production whether the element allows any form 810 of reference (URI-reference), only a URI in absolute form (absolute- 811 URI), only the path and optional query components, or some 812 combination of the above. Unless otherwise indicated, URI references 813 are parsed relative to the effective request URI, which defines the 814 default base URI for references in both the request and its 815 corresponding response. 817 2.7.1. http URI scheme 819 The "http" URI scheme is hereby defined for the purpose of minting 820 identifiers according to their association with the hierarchical 821 namespace governed by a potential HTTP origin server listening for 822 TCP connections on a given port. 824 http-URI = "http:" "//" authority path-abempty [ "?" query ] 826 The HTTP origin server is identified by the generic syntax's 827 authority component, which includes a host identifier and optional 828 TCP port ([RFC3986], Section 3.2.2). The remainder of the URI, 829 consisting of both the hierarchical path component and optional query 830 component, serves as an identifier for a potential resource within 831 that origin server's name space. 833 If the host identifier is provided as an IP literal or IPv4 address, 834 then the origin server is any listener on the indicated TCP port at 835 that IP address. If host is a registered name, then that name is 836 considered an indirect identifier and the recipient might use a name 837 resolution service, such as DNS, to find the address of a listener 838 for that host. The host MUST NOT be empty; if an "http" URI is 839 received with an empty host, then it MUST be rejected as invalid. If 840 the port subcomponent is empty or not given, then TCP port 80 is 841 assumed (the default reserved port for WWW services). 843 Regardless of the form of host identifier, access to that host is not 844 implied by the mere presence of its name or address. The host might 845 or might not exist and, even when it does exist, might or might not 846 be running an HTTP server or listening to the indicated port. The 847 "http" URI scheme makes use of the delegated nature of Internet names 848 and addresses to establish a naming authority (whatever entity has 849 the ability to place an HTTP server at that Internet name or address) 850 and allows that authority to determine which names are valid and how 851 they might be used. 853 When an "http" URI is used within a context that calls for access to 854 the indicated resource, a client MAY attempt access by resolving the 855 host to an IP address, establishing a TCP connection to that address 856 on the indicated port, and sending an HTTP request message 857 (Section 3) containing the URI's identifying data (Section 4) to the 858 server. If the server responds to that request with a non-interim 859 HTTP response message, as described in Section 4 of [Part2], then 860 that response is considered an authoritative answer to the client's 861 request. 863 Although HTTP is independent of the transport protocol, the "http" 864 scheme is specific to TCP-based services because the name delegation 865 process depends on TCP for establishing authority. An HTTP service 866 based on some other underlying connection protocol would presumably 867 be identified using a different URI scheme, just as the "https" 868 scheme (below) is used for servers that require an SSL/TLS transport 869 layer on a connection. Other protocols might also be used to provide 870 access to "http" identified resources -- it is only the authoritative 871 interface used for mapping the namespace that is specific to TCP. 873 The URI generic syntax for authority also includes a deprecated 874 userinfo subcomponent ([RFC3986], Section 3.2.1) for including user 875 authentication information in the URI. Some implementations make use 876 of the userinfo component for internal configuration of 877 authentication information, such as within command invocation 878 options, configuration files, or bookmark lists, even though such 879 usage might expose a user identifier or password. Senders MUST NOT 880 include a userinfo subcomponent (and its "@" delimiter) when 881 transmitting an "http" URI in a message. Recipients of HTTP messages 882 that contain a URI reference SHOULD parse for the existence of 883 userinfo and treat its presence as an error, likely indicating that 884 the deprecated subcomponent is being used to obscure the authority 885 for the sake of phishing attacks. 887 2.7.2. https URI scheme 889 The "https" URI scheme is hereby defined for the purpose of minting 890 identifiers according to their association with the hierarchical 891 namespace governed by a potential HTTP origin server listening for 892 SSL/TLS-secured connections on a given TCP port. 894 All of the requirements listed above for the "http" scheme are also 895 requirements for the "https" scheme, except that a default TCP port 896 of 443 is assumed if the port subcomponent is empty or not given, and 897 the TCP connection MUST be secured for privacy through the use of 898 strong encryption prior to sending the first HTTP request. 900 https-URI = "https:" "//" authority path-abempty [ "?" query ] 902 Unlike the "http" scheme, responses to "https" identified requests 903 are never "public" and thus MUST NOT be reused for shared caching. 904 They can, however, be reused in a private cache if the message is 905 cacheable by default in HTTP or specifically indicated as such by the 906 Cache-Control header field (Section 3.2 of [Part6]). 908 Resources made available via the "https" scheme have no shared 909 identity with the "http" scheme even if their resource identifiers 910 indicate the same authority (the same host listening to the same TCP 911 port). They are distinct name spaces and are considered to be 912 distinct origin servers. However, an extension to HTTP that is 913 defined to apply to entire host domains, such as the Cookie protocol 914 [RFC6265], can allow information set by one service to impact 915 communication with other services within a matching group of host 916 domains. 918 The process for authoritative access to an "https" identified 919 resource is defined in [RFC2818]. 921 2.7.3. http and https URI Normalization and Comparison 923 Since the "http" and "https" schemes conform to the URI generic 924 syntax, such URIs are normalized and compared according to the 925 algorithm defined in [RFC3986], Section 6, using the defaults 926 described above for each scheme. 928 If the port is equal to the default port for a scheme, the normal 929 form is to elide the port subcomponent. Likewise, an empty path 930 component is equivalent to an absolute path of "/", so the normal 931 form is to provide a path of "/" instead. The scheme and host are 932 case-insensitive and normally provided in lowercase; all other 933 components are compared in a case-sensitive manner. Characters other 934 than those in the "reserved" set are equivalent to their percent- 935 encoded octets (see [RFC3986], Section 2.1): the normal form is to 936 not encode them. 938 For example, the following three URIs are equivalent: 940 http://example.com:80/~smith/home.html 941 http://EXAMPLE.com/%7Esmith/home.html 942 http://EXAMPLE.com:/%7esmith/home.html 944 3. Message Format 946 All HTTP/1.1 messages consist of a start-line followed by a sequence 947 of octets in a format similar to the Internet Message Format 948 [RFC5322]: zero or more header fields (collectively referred to as 949 the "headers" or the "header section"), an empty line indicating the 950 end of the header section, and an optional message-body. 952 HTTP-message = start-line 953 *( header-field CRLF ) 954 CRLF 955 [ message-body ] 957 The normal procedure for parsing an HTTP message is to read the 958 start-line into a structure, read each header field into a hash table 959 by field name until the empty line, and then use the parsed data to 960 determine if a message-body is expected. If a message-body has been 961 indicated, then it is read as a stream until an amount of octets 962 equal to the message-body length is read or the connection is closed. 964 Recipients MUST parse an HTTP message as a sequence of octets in an 965 encoding that is a superset of US-ASCII [USASCII]. Parsing an HTTP 966 message as a stream of Unicode characters, without regard for the 967 specific encoding, creates security vulnerabilities due to the 968 varying ways that string processing libraries handle invalid 969 multibyte character sequences that contain the octet LF (%x0A). 970 String-based parsers can only be safely used within protocol elements 971 after the element has been extracted from the message, such as within 972 a header field-value after message parsing has delineated the 973 individual fields. 975 3.1. Start Line 977 An HTTP message can either be a request from client to server or a 978 response from server to client. Syntactically, the two types of 979 message differ only in the start-line, which is either a Request-Line 980 (for requests) or a Status-Line (for responses), and in the algorithm 981 for determining the length of the message-body (Section 3.3). In 982 theory, a client could receive requests and a server could receive 983 responses, distinguishing them by their different start-line formats, 984 but in practice servers are implemented to only expect a request (a 985 response is interpreted as an unknown or invalid request method) and 986 clients are implemented to only expect a response. 988 start-line = Request-Line / Status-Line 990 Implementations MUST NOT send whitespace between the start-line and 991 the first header field. The presence of such whitespace in a request 992 might be an attempt to trick a server into ignoring that field or 993 processing the line after it as a new request, either of which might 994 result in a security vulnerability if other implementations within 995 the request chain interpret the same message differently. Likewise, 996 the presence of such whitespace in a response might be ignored by 997 some clients or cause others to cease parsing. 999 3.1.1. Request-Line 1001 The Request-Line begins with a method token, followed by a single 1002 space (SP), the request-target, another single space (SP), the 1003 protocol version, and ending with CRLF. 1005 Request-Line = Method SP request-target SP HTTP-Version CRLF 1007 3.1.1.1. Method 1009 The Method token indicates the request method to be performed on the 1010 target resource. The request method is case-sensitive. 1012 Method = token 1014 See Section 2 of [Part2] for further information, such as the list of 1015 methods defined by this specification, the IANA registry, and 1016 considerations for new methods. 1018 3.1.1.2. request-target 1020 The request-target identifies the target resource upon which to apply 1021 the request. The four options for request-target are described in 1022 Section 4.1. 1024 request-target = "*" 1025 / absolute-URI 1026 / ( path-absolute [ "?" query ] ) 1027 / authority 1029 HTTP does not place a pre-defined limit on the length of a request- 1030 target. A server MUST be prepared to receive URIs of unbounded 1031 length and respond with the 414 (URI Too Long) status code if the 1032 received request-target would be longer than the server wishes to 1033 handle (see Section 7.4.15 of [Part2]). 1035 Various ad-hoc limitations on request-target length are found in 1036 practice. It is RECOMMENDED that all HTTP senders and recipients 1037 support request-target lengths of 8000 or more octets. 1039 Note: Fragments ([RFC3986], Section 3.5) are not part of the 1040 request-target and thus will not be transmitted in an HTTP 1041 request. 1043 3.1.2. Response Status-Line 1045 The first line of a Response message is the Status-Line, consisting 1046 of the protocol version, a space (SP), the status code, another 1047 space, a possibly-empty textual phrase describing the status code, 1048 and ending with CRLF. 1050 Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF 1052 3.1.2.1. Status Code 1054 The Status-Code element is a 3-digit integer result code of the 1055 attempt to understand and satisfy the request. See Section 4 of 1056 [Part2] for further information, such as the list of status codes 1057 defined by this specification, the IANA registry, and considerations 1058 for new status codes. 1060 Status-Code = 3DIGIT 1062 3.1.2.2. Reason Phrase 1064 The Reason Phrase exists for the sole purpose of providing a textual 1065 description associated with the numeric status code, out of deference 1066 to earlier Internet application protocols that were more frequently 1067 used with interactive text clients. A client SHOULD ignore the 1068 content of the Reason Phrase. 1070 Reason-Phrase = *( HTAB / SP / VCHAR / obs-text ) 1072 3.2. Header Fields 1074 Each HTTP header field consists of a case-insensitive field name 1075 followed by a colon (":"), optional whitespace, and the field value. 1077 header-field = field-name ":" OWS field-value BWS 1078 field-name = token 1079 field-value = *( field-content / obs-fold ) 1080 field-content = *( HTAB / SP / VCHAR / obs-text ) 1082 The field-name token labels the corresponding field-value as having 1083 the semantics defined by that header field. For example, the Date 1084 header field is defined in Section 9.2 of [Part2] as containing the 1085 origination timestamp for the message in which it appears. 1087 HTTP header fields are fully extensible: there is no limit on the 1088 introduction of new field names, each presumably defining new 1089 semantics, or on the number of header fields used in a given message. 1090 Existing fields are defined in each part of this specification and in 1091 many other specifications outside the standards process. New header 1092 fields can be introduced without changing the protocol version if 1093 their defined semantics allow them to be safely ignored by recipients 1094 that do not recognize them. 1096 New HTTP header fields SHOULD be registered with IANA according to 1097 the procedures in Section 3.1 of [Part2]. Unrecognized header fields 1098 MUST be forwarded by a proxy unless the field-name is listed in the 1099 Connection header field (Section 8.1) or the proxy is specifically 1100 configured to block or otherwise transform such fields. Unrecognized 1101 header fields SHOULD be ignored by other recipients. 1103 The order in which header fields with differing field names are 1104 received is not significant. However, it is "good practice" to send 1105 header fields that contain control data first, such as Host on 1106 requests and Date on responses, so that implementations can decide 1107 when not to handle a message as early as possible. A server MUST 1108 wait until the entire header section is received before interpreting 1109 a request message, since later header fields might include 1110 conditionals, authentication credentials, or deliberately misleading 1111 duplicate header fields that would impact request processing. 1113 Multiple header fields with the same field name MUST NOT be sent in a 1114 message unless the entire field value for that header field is 1115 defined as a comma-separated list [i.e., #(values)]. Multiple header 1116 fields with the same field name can be combined into one "field-name: 1117 field-value" pair, without changing the semantics of the message, by 1118 appending each subsequent field value to the combined field value in 1119 order, separated by a comma. The order in which header fields with 1120 the same field name are received is therefore significant to the 1121 interpretation of the combined field value; a proxy MUST NOT change 1122 the order of these field values when forwarding a message. 1124 Note: The "Set-Cookie" header field as implemented in practice can 1125 occur multiple times, but does not use the list syntax, and thus 1126 cannot be combined into a single line ([RFC6265]). (See Appendix 1127 A.2.3 of [Kri2001] for details.) Also note that the Set-Cookie2 1128 header field specified in [RFC2965] does not share this problem. 1130 3.2.1. Field Parsing 1132 No whitespace is allowed between the header field-name and colon. In 1133 the past, differences in the handling of such whitespace have led to 1134 security vulnerabilities in request routing and response handling. 1135 Any received request message that contains whitespace between a 1136 header field-name and colon MUST be rejected with a response code of 1137 400 (Bad Request). A proxy MUST remove any such whitespace from a 1138 response message before forwarding the message downstream. 1140 A field value MAY be preceded by optional whitespace (OWS); a single 1141 SP is preferred. The field value does not include any leading or 1142 trailing white space: OWS occurring before the first non-whitespace 1143 octet of the field value or after the last non-whitespace octet of 1144 the field value is ignored and SHOULD be removed before further 1145 processing (as this does not change the meaning of the header field). 1147 Historically, HTTP header field values could be extended over 1148 multiple lines by preceding each extra line with at least one space 1149 or horizontal tab (obs-fold). This specification deprecates such 1150 line folding except within the message/http media type 1151 (Section 9.3.1). HTTP senders MUST NOT produce messages that include 1152 line folding (i.e., that contain any field-content that matches the 1153 obs-fold rule) unless the message is intended for packaging within 1154 the message/http media type. HTTP recipients SHOULD accept line 1155 folding and replace any embedded obs-fold whitespace with either a 1156 single SP or a matching number of SP octets (to avoid buffer copying) 1157 prior to interpreting the field value or forwarding the message 1158 downstream. 1160 Historically, HTTP has allowed field content with text in the ISO- 1161 8859-1 [ISO-8859-1] character encoding and supported other character 1162 sets only through use of [RFC2047] encoding. In practice, most HTTP 1163 header field values use only a subset of the US-ASCII character 1164 encoding [USASCII]. Newly defined header fields SHOULD limit their 1165 field values to US-ASCII octets. Recipients SHOULD treat other (obs- 1166 text) octets in field content as opaque data. 1168 3.2.2. Field Length 1170 HTTP does not place a pre-defined limit on the length of header 1171 fields, either in isolation or as a set. A server MUST be prepared 1172 to receive request header fields of unbounded length and respond with 1173 a 4xx status code if the received header field(s) would be longer 1174 than the server wishes to handle. 1176 A client that receives response headers that are longer than it 1177 wishes to handle can only treat it as a server error. 1179 Various ad-hoc limitations on header length are found in practice. 1180 It is RECOMMENDED that all HTTP senders and recipients support 1181 messages whose combined header fields have 4000 or more octets. 1183 3.2.3. Common Field ABNF Rules 1185 Many HTTP/1.1 header field values consist of words (token or quoted- 1186 string) separated by whitespace or special characters. These special 1187 characters MUST be in a quoted string to be used within a parameter 1188 value (as defined in Section 5.1). 1190 word = token / quoted-string 1192 token = 1*tchar 1194 tchar = "!" / "#" / "$" / "%" / "&" / "'" / "*" 1195 / "+" / "-" / "." / "^" / "_" / "`" / "|" / "~" 1196 / DIGIT / ALPHA 1197 ; any VCHAR, except special 1199 special = "(" / ")" / "<" / ">" / "@" / "," 1200 / ";" / ":" / "\" / DQUOTE / "/" / "[" 1201 / "]" / "?" / "=" / "{" / "}" 1203 A string of text is parsed as a single word if it is quoted using 1204 double-quote marks. 1206 quoted-string = DQUOTE *( qdtext / quoted-pair ) DQUOTE 1207 qdtext = OWS / %x21 / %x23-5B / %x5D-7E / obs-text 1208 obs-text = %x80-FF 1210 The backslash octet ("\") can be used as a single-octet quoting 1211 mechanism within quoted-string constructs: 1213 quoted-pair = "\" ( HTAB / SP / VCHAR / obs-text ) 1215 Recipients that process the value of the quoted-string MUST handle a 1216 quoted-pair as if it were replaced by the octet following the 1217 backslash. 1219 Senders SHOULD NOT escape octets in quoted-strings that do not 1220 require escaping (i.e., other than DQUOTE and the backslash octet). 1222 Comments can be included in some HTTP header fields by surrounding 1223 the comment text with parentheses. Comments are only allowed in 1224 fields containing "comment" as part of their field value definition. 1226 comment = "(" *( ctext / quoted-cpair / comment ) ")" 1227 ctext = OWS / %x21-27 / %x2A-5B / %x5D-7E / obs-text 1229 The backslash octet ("\") can be used as a single-octet quoting 1230 mechanism within comment constructs: 1232 quoted-cpair = "\" ( HTAB / SP / VCHAR / obs-text ) 1234 Senders SHOULD NOT escape octets in comments that do not require 1235 escaping (i.e., other than the backslash octet "\" and the 1236 parentheses "(" and ")"). 1238 3.3. Message Body 1240 The message-body (if any) of an HTTP message is used to carry the 1241 payload body associated with the request or response. 1243 message-body = *OCTET 1245 The message-body differs from the payload body only when a transfer- 1246 coding has been applied, as indicated by the Transfer-Encoding header 1247 field (Section 8.6). If more than one Transfer-Encoding header field 1248 is present in a message, the multiple field-values MUST be combined 1249 into one field-value, according to the algorithm defined in 1250 Section 3.2, before determining the message-body length. 1252 When one or more transfer-codings are applied to a payload in order 1253 to form the message-body, the Transfer-Encoding header field MUST 1254 contain the list of transfer-codings applied. Transfer-Encoding is a 1255 property of the message, not of the payload, and thus MAY be added or 1256 removed by any implementation along the request/response chain under 1257 the constraints found in Section 5.1. 1259 If a message is received that has multiple Content-Length header 1260 fields (Section 8.2) with field-values consisting of the same decimal 1261 value, or a single Content-Length header field with a field value 1262 containing a list of identical decimal values (e.g., "Content-Length: 1263 42, 42"), indicating that duplicate Content-Length header fields have 1264 been generated or combined by an upstream message processor, then the 1265 recipient MUST either reject the message as invalid or replace the 1266 duplicated field-values with a single valid Content-Length field 1267 containing that decimal value prior to determining the message-body 1268 length. 1270 The rules for when a message-body is allowed in a message differ for 1271 requests and responses. 1273 The presence of a message-body in a request is signaled by the 1274 inclusion of a Content-Length or Transfer-Encoding header field in 1275 the request's header fields, even if the request method does not 1276 define any use for a message-body. This allows the request message 1277 framing algorithm to be independent of method semantics. 1279 For response messages, whether or not a message-body is included with 1280 a message is dependent on both the request method and the response 1281 status code (Section 3.1.2.1). Responses to the HEAD request method 1282 never include a message-body because the associated response header 1283 fields (e.g., Transfer-Encoding, Content-Length, etc.) only indicate 1284 what their values would have been if the request method had been GET. 1285 All 1xx (Informational), 204 (No Content), and 304 (Not Modified) 1286 responses MUST NOT include a message-body. All other responses do 1287 include a message-body, although the body MAY be of zero length. 1289 The length of the message-body is determined by one of the following 1290 (in order of precedence): 1292 1. Any response to a HEAD request and any response with a status 1293 code of 100-199, 204, or 304 is always terminated by the first 1294 empty line after the header fields, regardless of the header 1295 fields present in the message, and thus cannot contain a message- 1296 body. 1298 2. If a Transfer-Encoding header field is present and the "chunked" 1299 transfer-coding (Section 5.1) is the final encoding, the message- 1300 body length is determined by reading and decoding the chunked 1301 data until the transfer-coding indicates the data is complete. 1303 If a Transfer-Encoding header field is present in a response and 1304 the "chunked" transfer-coding is not the final encoding, the 1305 message-body length is determined by reading the connection until 1306 it is closed by the server. If a Transfer-Encoding header field 1307 is present in a request and the "chunked" transfer-coding is not 1308 the final encoding, the message-body length cannot be determined 1309 reliably; the server MUST respond with the 400 (Bad Request) 1310 status code and then close the connection. 1312 If a message is received with both a Transfer-Encoding header 1313 field and a Content-Length header field, the Transfer-Encoding 1314 overrides the Content-Length. Such a message might indicate an 1315 attempt to perform request or response smuggling (bypass of 1316 security-related checks on message routing or content) and thus 1317 ought to be handled as an error. The provided Content-Length 1318 MUST be removed, prior to forwarding the message downstream, or 1319 replaced with the real message-body length after the transfer- 1320 coding is decoded. 1322 3. If a message is received without Transfer-Encoding and with 1323 either multiple Content-Length header fields having differing 1324 field-values or a single Content-Length header field having an 1325 invalid value, then the message framing is invalid and MUST be 1326 treated as an error to prevent request or response smuggling. If 1327 this is a request message, the server MUST respond with a 400 1328 (Bad Request) status code and then close the connection. If this 1329 is a response message received by a proxy, the proxy MUST discard 1330 the received response, send a 502 (Bad Gateway) status code as 1331 its downstream response, and then close the connection. If this 1332 is a response message received by a user-agent, it MUST be 1333 treated as an error by discarding the message and closing the 1334 connection. 1336 4. If a valid Content-Length header field is present without 1337 Transfer-Encoding, its decimal value defines the message-body 1338 length in octets. If the actual number of octets sent in the 1339 message is less than the indicated Content-Length, the recipient 1340 MUST consider the message to be incomplete and treat the 1341 connection as no longer usable. If the actual number of octets 1342 sent in the message is more than the indicated Content-Length, 1343 the recipient MUST only process the message-body up to the field 1344 value's number of octets; the remainder of the message MUST 1345 either be discarded or treated as the next message in a pipeline. 1346 For the sake of robustness, a user-agent MAY attempt to detect 1347 and correct such an error in message framing if it is parsing the 1348 response to the last request on a connection and the connection 1349 has been closed by the server. 1351 5. If this is a request message and none of the above are true, then 1352 the message-body length is zero (no message-body is present). 1354 6. Otherwise, this is a response message without a declared message- 1355 body length, so the message-body length is determined by the 1356 number of octets received prior to the server closing the 1357 connection. 1359 Since there is no way to distinguish a successfully completed, close- 1360 delimited message from a partially-received message interrupted by 1361 network failure, implementations SHOULD use encoding or length- 1362 delimited messages whenever possible. The close-delimiting feature 1363 exists primarily for backwards compatibility with HTTP/1.0. 1365 A server MAY reject a request that contains a message-body but not a 1366 Content-Length by responding with 411 (Length Required). 1368 Unless a transfer-coding other than "chunked" has been applied, a 1369 client that sends a request containing a message-body SHOULD use a 1370 valid Content-Length header field if the message-body length is known 1371 in advance, rather than the "chunked" encoding, since some existing 1372 services respond to "chunked" with a 411 (Length Required) status 1373 code even though they understand the chunked encoding. This is 1374 typically because such services are implemented via a gateway that 1375 requires a content-length in advance of being called and the server 1376 is unable or unwilling to buffer the entire request before 1377 processing. 1379 A client that sends a request containing a message-body MUST include 1380 a valid Content-Length header field if it does not know the server 1381 will handle HTTP/1.1 (or later) requests; such knowledge can be in 1382 the form of specific user configuration or by remembering the version 1383 of a prior received response. 1385 3.4. Handling Incomplete Messages 1387 Request messages that are prematurely terminated, possibly due to a 1388 cancelled connection or a server-imposed time-out exception, MUST 1389 result in closure of the connection; sending an HTTP/1.1 error 1390 response prior to closing the connection is OPTIONAL. 1392 Response messages that are prematurely terminated, usually by closure 1393 of the connection prior to receiving the expected number of octets or 1394 by failure to decode a transfer-encoded message-body, MUST be 1395 recorded as incomplete. A response that terminates in the middle of 1396 the header block (before the empty line is received) cannot be 1397 assumed to convey the full semantics of the response and MUST be 1398 treated as an error. 1400 A message-body that uses the chunked transfer encoding is incomplete 1401 if the zero-sized chunk that terminates the encoding has not been 1402 received. A message that uses a valid Content-Length is incomplete 1403 if the size of the message-body received (in octets) is less than the 1404 value given by Content-Length. A response that has neither chunked 1405 transfer encoding nor Content-Length is terminated by closure of the 1406 connection, and thus is considered complete regardless of the number 1407 of message-body octets received, provided that the header block was 1408 received intact. 1410 A user agent MUST NOT render an incomplete response message-body as 1411 if it were complete (i.e., some indication must be given to the user 1412 that an error occurred). Cache requirements for incomplete responses 1413 are defined in Section 2.1 of [Part6]. 1415 A server MUST read the entire request message-body or close the 1416 connection after sending its response, since otherwise the remaining 1417 data on a persistent connection would be misinterpreted as the next 1418 request. Likewise, a client MUST read the entire response message- 1419 body if it intends to reuse the same connection for a subsequent 1420 request. Pipelining multiple requests on a connection is described 1421 in Section 6.1.2.2. 1423 3.5. Message Parsing Robustness 1425 Older HTTP/1.0 client implementations might send an extra CRLF after 1426 a POST request as a lame workaround for some early server 1427 applications that failed to read message-body content that was not 1428 terminated by a line-ending. An HTTP/1.1 client MUST NOT preface or 1429 follow a request with an extra CRLF. If terminating the request 1430 message-body with a line-ending is desired, then the client MUST 1431 include the terminating CRLF octets as part of the message-body 1432 length. 1434 In the interest of robustness, servers SHOULD ignore at least one 1435 empty line received where a Request-Line is expected. In other 1436 words, if the server is reading the protocol stream at the beginning 1437 of a message and receives a CRLF first, it SHOULD ignore the CRLF. 1438 Likewise, although the line terminator for the start-line and header 1439 fields is the sequence CRLF, we recommend that recipients recognize a 1440 single LF as a line terminator and ignore any CR. 1442 When a server listening only for HTTP request messages, or processing 1443 what appears from the start-line to be an HTTP request message, 1444 receives a sequence of octets that does not match the HTTP-message 1445 grammar aside from the robustness exceptions listed above, the server 1446 MUST respond with an HTTP/1.1 400 (Bad Request) response. 1448 4. Message Routing 1450 In most cases, the user agent is provided a URI reference from which 1451 it determines an absolute URI for identifying the target resource. 1452 When a request to the resource is initiated, all or part of that URI 1453 is used to construct the HTTP request-target. 1455 4.1. Types of Request Target 1457 The four options for request-target are dependent on the nature of 1458 the request. 1460 The asterisk "*" form of request-target, which MUST NOT be used with 1461 any request method other than OPTIONS, means that the request applies 1462 to the server as a whole (the listening process) rather than to a 1463 specific named resource at that server. For example, 1465 OPTIONS * HTTP/1.1 1467 The "absolute-URI" form is REQUIRED when the request is being made to 1468 a proxy. The proxy is requested to either forward the request or 1469 service it from a valid cache, and then return the response. Note 1470 that the proxy MAY forward the request on to another proxy or 1471 directly to the server specified by the absolute-URI. In order to 1472 avoid request loops, a proxy that forwards requests to other proxies 1473 MUST be able to recognize and exclude all of its own server names, 1474 including any aliases, local variations, and the numeric IP address. 1475 An example Request-Line would be: 1477 GET http://www.example.org/pub/WWW/TheProject.html HTTP/1.1 1479 To allow for transition to absolute-URIs in all requests in future 1480 versions of HTTP, all HTTP/1.1 servers MUST accept the absolute-URI 1481 form in requests, even though HTTP/1.1 clients will only generate 1482 them in requests to proxies. 1484 If a proxy receives a host name that is not a fully qualified domain 1485 name, it MAY add its domain to the host name it received. If a proxy 1486 receives a fully qualified domain name, the proxy MUST NOT change the 1487 host name. 1489 The "authority form" is only used by the CONNECT request method 1490 (Section 6.9 of [Part2]). 1492 The most common form of request-target is that used when making a 1493 request to an origin server ("origin form"). In this case, the 1494 absolute path and query components of the URI MUST be transmitted as 1495 the request-target, and the authority component MUST be transmitted 1496 in a Host header field. For example, a client wishing to retrieve a 1497 representation of the resource, as identified above, directly from 1498 the origin server would open (or reuse) a TCP connection to port 80 1499 of the host "www.example.org" and send the lines: 1501 GET /pub/WWW/TheProject.html HTTP/1.1 1502 Host: www.example.org 1504 followed by the remainder of the Request. Note that the origin form 1505 of request-target always starts with an absolute path; if the target 1506 resource's URI path is empty, then an absolute path of "/" MUST be 1507 provided in the request-target. 1509 If a proxy receives an OPTIONS request with an absolute-URI form of 1510 request-target in which the URI has an empty path and no query 1511 component, then the last proxy on the request chain MUST use a 1512 request-target of "*" when it forwards the request to the indicated 1513 origin server. 1515 For example, the request 1517 OPTIONS http://www.example.org:8001 HTTP/1.1 1519 would be forwarded by the final proxy as 1521 OPTIONS * HTTP/1.1 1522 Host: www.example.org:8001 1524 after connecting to port 8001 of host "www.example.org". 1526 The request-target is transmitted in the format specified in 1527 Section 2.7.1. If the request-target is percent-encoded ([RFC3986], 1528 Section 2.1), the origin server MUST decode the request-target in 1529 order to properly interpret the request. Servers SHOULD respond to 1530 invalid request-targets with an appropriate status code. 1532 A non-transforming proxy MUST NOT rewrite the "path-absolute" and 1533 "query" parts of the received request-target when forwarding it to 1534 the next inbound server, except as noted above to replace a null 1535 path-absolute with "/" or "*". 1537 Note: The "no rewrite" rule prevents the proxy from changing the 1538 meaning of the request when the origin server is improperly using 1539 a non-reserved URI character for a reserved purpose. Implementors 1540 need to be aware that some pre-HTTP/1.1 proxies have been known to 1541 rewrite the request-target. 1543 4.2. The Resource Identified by a Request 1545 The exact resource identified by an Internet request is determined by 1546 examining both the request-target and the Host header field. 1548 An origin server that does not allow resources to differ by the 1549 requested host MAY ignore the Host header field value when 1550 determining the resource identified by an HTTP/1.1 request. (But see 1551 Appendix A.1.1 for other requirements on Host support in HTTP/1.1.) 1553 An origin server that does differentiate resources based on the host 1554 requested (sometimes referred to as virtual hosts or vanity host 1555 names) MUST use the following rules for determining the requested 1556 resource on an HTTP/1.1 request: 1558 1. If request-target is an absolute-URI, the host is part of the 1559 request-target. Any Host header field value in the request MUST 1560 be ignored. 1562 2. If the request-target is not an absolute-URI, and the request 1563 includes a Host header field, the host is determined by the Host 1564 header field value. 1566 3. If the host as determined by rule 1 or 2 is not a valid host on 1567 the server, the response MUST be a 400 (Bad Request) error 1568 message. 1570 Recipients of an HTTP/1.0 request that lacks a Host header field MAY 1571 attempt to use heuristics (e.g., examination of the URI path for 1572 something unique to a particular host) in order to determine what 1573 exact resource is being requested. 1575 4.3. Effective Request URI 1577 HTTP requests often do not carry the absolute URI ([RFC3986], Section 1578 4.3) for the target resource; instead, the URI needs to be inferred 1579 from the request-target, Host header field, and connection context. 1580 The result of this process is called the "effective request URI". 1581 The "target resource" is the resource identified by the effective 1582 request URI. 1584 If the request-target is an absolute-URI, then the effective request 1585 URI is the request-target. 1587 If the request-target uses the origin form or the asterisk form, and 1588 the Host header field is present, then the effective request URI is 1589 constructed by concatenating 1591 o the scheme name: "http" if the request was received over an 1592 insecure TCP connection, or "https" when received over a SSL/ 1593 TLS-secured TCP connection, 1595 o the octet sequence "://", 1597 o the authority component, as specified in the Host header field 1598 (Section 8.3), and 1600 o the request-target obtained from the Request-Line, unless the 1601 request-target is just the asterisk "*". 1603 If the request-target uses the origin form or the asterisk form, and 1604 the Host header field is not present, then the effective request URI 1605 is undefined. 1607 Otherwise, when request-target uses the authority form, the effective 1608 request URI is undefined. 1610 Example 1: the effective request URI for the message 1612 GET /pub/WWW/TheProject.html HTTP/1.1 1613 Host: www.example.org:8080 1615 (received over an insecure TCP connection) is "http", plus "://", 1616 plus the authority component "www.example.org:8080", plus the 1617 request-target "/pub/WWW/TheProject.html", thus 1618 "http://www.example.org:8080/pub/WWW/TheProject.html". 1620 Example 2: the effective request URI for the message 1622 OPTIONS * HTTP/1.1 1623 Host: www.example.org 1625 (received over an SSL/TLS secured TCP connection) is "https", plus 1626 "://", plus the authority component "www.example.org", thus 1627 "https://www.example.org". 1629 Effective request URIs are compared using the rules described in 1630 Section 2.7.3, except that empty path components MUST NOT be treated 1631 as equivalent to an absolute path of "/". 1633 5. Protocol Parameters 1635 5.1. Transfer Codings 1637 Transfer-coding values are used to indicate an encoding 1638 transformation that has been, can be, or might need to be applied to 1639 a payload body in order to ensure "safe transport" through the 1640 network. This differs from a content coding in that the transfer- 1641 coding is a property of the message rather than a property of the 1642 representation that is being transferred. 1644 transfer-coding = "chunked" ; Section 5.1.1 1645 / "compress" ; Section 5.1.2.1 1646 / "deflate" ; Section 5.1.2.2 1647 / "gzip" ; Section 5.1.2.3 1648 / transfer-extension 1649 transfer-extension = token *( OWS ";" OWS transfer-parameter ) 1651 Parameters are in the form of attribute/value pairs. 1653 transfer-parameter = attribute BWS "=" BWS value 1654 attribute = token 1655 value = word 1657 All transfer-coding values are case-insensitive. HTTP/1.1 uses 1658 transfer-coding values in the TE header field (Section 8.4) and in 1659 the Transfer-Encoding header field (Section 8.6). 1661 Transfer-codings are analogous to the Content-Transfer-Encoding 1662 values of MIME, which were designed to enable safe transport of 1663 binary data over a 7-bit transport service ([RFC2045], Section 6). 1664 However, safe transport has a different focus for an 8bit-clean 1665 transfer protocol. In HTTP, the only unsafe characteristic of 1666 message-bodies is the difficulty in determining the exact message 1667 body length (Section 3.3), or the desire to encrypt data over a 1668 shared transport. 1670 A server that receives a request message with a transfer-coding it 1671 does not understand SHOULD respond with 501 (Not Implemented) and 1672 then close the connection. A server MUST NOT send transfer-codings 1673 to an HTTP/1.0 client. 1675 5.1.1. Chunked Transfer Coding 1677 The chunked encoding modifies the body of a message in order to 1678 transfer it as a series of chunks, each with its own size indicator, 1679 followed by an OPTIONAL trailer containing header fields. This 1680 allows dynamically produced content to be transferred along with the 1681 information necessary for the recipient to verify that it has 1682 received the full message. 1684 Chunked-Body = *chunk 1685 last-chunk 1686 trailer-part 1687 CRLF 1689 chunk = chunk-size [ chunk-ext ] CRLF 1690 chunk-data CRLF 1691 chunk-size = 1*HEXDIG 1692 last-chunk = 1*("0") [ chunk-ext ] CRLF 1694 chunk-ext = *( ";" chunk-ext-name 1695 [ "=" chunk-ext-val ] ) 1696 chunk-ext-name = token 1697 chunk-ext-val = token / quoted-str-nf 1698 chunk-data = 1*OCTET ; a sequence of chunk-size octets 1699 trailer-part = *( header-field CRLF ) 1701 quoted-str-nf = DQUOTE *( qdtext-nf / quoted-pair ) DQUOTE 1702 ; like quoted-string, but disallowing line folding 1703 qdtext-nf = HTAB / SP / %x21 / %x23-5B / %x5D-7E / obs-text 1705 The chunk-size field is a string of hex digits indicating the size of 1706 the chunk-data in octets. The chunked encoding is ended by any chunk 1707 whose size is zero, followed by the trailer, which is terminated by 1708 an empty line. 1710 The trailer allows the sender to include additional HTTP header 1711 fields at the end of the message. The Trailer header field can be 1712 used to indicate which header fields are included in a trailer (see 1713 Section 8.5). 1715 A server using chunked transfer-coding in a response MUST NOT use the 1716 trailer for any header fields unless at least one of the following is 1717 true: 1719 1. the request included a TE header field that indicates "trailers" 1720 is acceptable in the transfer-coding of the response, as 1721 described in Section 8.4; or, 1723 2. the trailer fields consist entirely of optional metadata, and the 1724 recipient could use the message (in a manner acceptable to the 1725 server where the field originated) without receiving it. In 1726 other words, the server that generated the header (often but not 1727 always the origin server) is willing to accept the possibility 1728 that the trailer fields might be silently discarded along the 1729 path to the client. 1731 This requirement prevents an interoperability failure when the 1732 message is being received by an HTTP/1.1 (or later) proxy and 1733 forwarded to an HTTP/1.0 recipient. It avoids a situation where 1734 compliance with the protocol would have necessitated a possibly 1735 infinite buffer on the proxy. 1737 A process for decoding the "chunked" transfer-coding can be 1738 represented in pseudo-code as: 1740 length := 0 1741 read chunk-size, chunk-ext (if any) and CRLF 1742 while (chunk-size > 0) { 1743 read chunk-data and CRLF 1744 append chunk-data to decoded-body 1745 length := length + chunk-size 1746 read chunk-size and CRLF 1747 } 1748 read header-field 1749 while (header-field not empty) { 1750 append header-field to existing header fields 1751 read header-field 1752 } 1753 Content-Length := length 1754 Remove "chunked" from Transfer-Encoding 1756 All HTTP/1.1 applications MUST be able to receive and decode the 1757 "chunked" transfer-coding and MUST ignore chunk-ext extensions they 1758 do not understand. 1760 Since "chunked" is the only transfer-coding required to be understood 1761 by HTTP/1.1 recipients, it plays a crucial role in delimiting 1762 messages on a persistent connection. Whenever a transfer-coding is 1763 applied to a payload body in a request, the final transfer-coding 1764 applied MUST be "chunked". If a transfer-coding is applied to a 1765 response payload body, then either the final transfer-coding applied 1766 MUST be "chunked" or the message MUST be terminated by closing the 1767 connection. When the "chunked" transfer-coding is used, it MUST be 1768 the last transfer-coding applied to form the message-body. The 1769 "chunked" transfer-coding MUST NOT be applied more than once in a 1770 message-body. 1772 5.1.2. Compression Codings 1774 The codings defined below can be used to compress the payload of a 1775 message. 1777 Note: Use of program names for the identification of encoding 1778 formats is not desirable and is discouraged for future encodings. 1779 Their use here is representative of historical practice, not good 1780 design. 1782 Note: For compatibility with previous implementations of HTTP, 1783 applications SHOULD consider "x-gzip" and "x-compress" to be 1784 equivalent to "gzip" and "compress" respectively. 1786 5.1.2.1. Compress Coding 1788 The "compress" format is produced by the common UNIX file compression 1789 program "compress". This format is an adaptive Lempel-Ziv-Welch 1790 coding (LZW). 1792 5.1.2.2. Deflate Coding 1794 The "deflate" format is defined as the "deflate" compression 1795 mechanism (described in [RFC1951]) used inside the "zlib" data format 1796 ([RFC1950]). 1798 Note: Some incorrect implementations send the "deflate" compressed 1799 data without the zlib wrapper. 1801 5.1.2.3. Gzip Coding 1803 The "gzip" format is produced by the file compression program "gzip" 1804 (GNU zip), as described in [RFC1952]. This format is a Lempel-Ziv 1805 coding (LZ77) with a 32 bit CRC. 1807 5.1.3. Transfer Coding Registry 1809 The HTTP Transfer Coding Registry defines the name space for the 1810 transfer coding names. 1812 Registrations MUST include the following fields: 1814 o Name 1816 o Description 1818 o Pointer to specification text 1820 Names of transfer codings MUST NOT overlap with names of content 1821 codings (Section 2.2 of [Part3]), unless the encoding transformation 1822 is identical (as it is the case for the compression codings defined 1823 in Section 5.1.2). 1825 Values to be added to this name space require a specification (see 1826 "Specification Required" in Section 4.1 of [RFC5226]), and MUST 1827 conform to the purpose of transfer coding defined in this section. 1829 The registry itself is maintained at 1830 . 1832 5.2. Product Tokens 1834 Product tokens are used to allow communicating applications to 1835 identify themselves by software name and version. Most fields using 1836 product tokens also allow sub-products which form a significant part 1837 of the application to be listed, separated by whitespace. By 1838 convention, the products are listed in order of their significance 1839 for identifying the application. 1841 product = token ["/" product-version] 1842 product-version = token 1844 Examples: 1846 User-Agent: CERN-LineMode/2.15 libwww/2.17b3 1847 Server: Apache/0.8.4 1849 Product tokens SHOULD be short and to the point. They MUST NOT be 1850 used for advertising or other non-essential information. Although 1851 any token octet MAY appear in a product-version, this token SHOULD 1852 only be used for a version identifier (i.e., successive versions of 1853 the same product SHOULD only differ in the product-version portion of 1854 the product value). 1856 5.3. Quality Values 1858 Both transfer codings (TE request header field, Section 8.4) and 1859 content negotiation (Section 5 of [Part3]) use short "floating point" 1860 numbers to indicate the relative importance ("weight") of various 1861 negotiable parameters. A weight is normalized to a real number in 1862 the range 0 through 1, where 0 is the minimum and 1 the maximum 1863 value. If a parameter has a quality value of 0, then content with 1864 this parameter is "not acceptable" for the client. HTTP/1.1 1865 applications MUST NOT generate more than three digits after the 1866 decimal point. User configuration of these values SHOULD also be 1867 limited in this fashion. 1869 qvalue = ( "0" [ "." 0*3DIGIT ] ) 1870 / ( "1" [ "." 0*3("0") ] ) 1872 Note: "Quality values" is a misnomer, since these values merely 1873 represent relative degradation in desired quality. 1875 6. Connections 1877 6.1. Persistent Connections 1879 6.1.1. Purpose 1881 Prior to persistent connections, a separate TCP connection was 1882 established for each request, increasing the load on HTTP servers and 1883 causing congestion on the Internet. The use of inline images and 1884 other associated data often requires a client to make multiple 1885 requests of the same server in a short amount of time. Analysis of 1886 these performance problems and results from a prototype 1887 implementation are available [Pad1995] [Spe]. Implementation 1888 experience and measurements of actual HTTP/1.1 implementations show 1889 good results [Nie1997]. Alternatives have also been explored, for 1890 example, T/TCP [Tou1998]. 1892 Persistent HTTP connections have a number of advantages: 1894 o By opening and closing fewer TCP connections, CPU time is saved in 1895 routers and hosts (clients, servers, proxies, gateways, tunnels, 1896 or caches), and memory used for TCP protocol control blocks can be 1897 saved in hosts. 1899 o HTTP requests and responses can be pipelined on a connection. 1900 Pipelining allows a client to make multiple requests without 1901 waiting for each response, allowing a single TCP connection to be 1902 used much more efficiently, with much lower elapsed time. 1904 o Network congestion is reduced by reducing the number of packets 1905 caused by TCP opens, and by allowing TCP sufficient time to 1906 determine the congestion state of the network. 1908 o Latency on subsequent requests is reduced since there is no time 1909 spent in TCP's connection opening handshake. 1911 o HTTP can evolve more gracefully, since errors can be reported 1912 without the penalty of closing the TCP connection. Clients using 1913 future versions of HTTP might optimistically try a new feature, 1914 but if communicating with an older server, retry with old 1915 semantics after an error is reported. 1917 HTTP implementations SHOULD implement persistent connections. 1919 6.1.2. Overall Operation 1921 A significant difference between HTTP/1.1 and earlier versions of 1922 HTTP is that persistent connections are the default behavior of any 1923 HTTP connection. That is, unless otherwise indicated, the client 1924 SHOULD assume that the server will maintain a persistent connection, 1925 even after error responses from the server. 1927 Persistent connections provide a mechanism by which a client and a 1928 server can signal the close of a TCP connection. This signaling 1929 takes place using the Connection header field (Section 8.1). Once a 1930 close has been signaled, the client MUST NOT send any more requests 1931 on that connection. 1933 6.1.2.1. Negotiation 1935 An HTTP/1.1 server MAY assume that a HTTP/1.1 client intends to 1936 maintain a persistent connection unless a Connection header field 1937 including the connection-token "close" was sent in the request. If 1938 the server chooses to close the connection immediately after sending 1939 the response, it SHOULD send a Connection header field including the 1940 connection-token "close". 1942 An HTTP/1.1 client MAY expect a connection to remain open, but would 1943 decide to keep it open based on whether the response from a server 1944 contains a Connection header field with the connection-token close. 1946 In case the client does not want to maintain a connection for more 1947 than that request, it SHOULD send a Connection header field including 1948 the connection-token close. 1950 If either the client or the server sends the close token in the 1951 Connection header field, that request becomes the last one for the 1952 connection. 1954 Clients and servers SHOULD NOT assume that a persistent connection is 1955 maintained for HTTP versions less than 1.1 unless it is explicitly 1956 signaled. See Appendix A.1.2 for more information on backward 1957 compatibility with HTTP/1.0 clients. 1959 In order to remain persistent, all messages on the connection MUST 1960 have a self-defined message length (i.e., one not defined by closure 1961 of the connection), as described in Section 3.3. 1963 6.1.2.2. Pipelining 1965 A client that supports persistent connections MAY "pipeline" its 1966 requests (i.e., send multiple requests without waiting for each 1967 response). A server MUST send its responses to those requests in the 1968 same order that the requests were received. 1970 Clients which assume persistent connections and pipeline immediately 1971 after connection establishment SHOULD be prepared to retry their 1972 connection if the first pipelined attempt fails. If a client does 1973 such a retry, it MUST NOT pipeline before it knows the connection is 1974 persistent. Clients MUST also be prepared to resend their requests 1975 if the server closes the connection before sending all of the 1976 corresponding responses. 1978 Clients SHOULD NOT pipeline requests using non-idempotent request 1979 methods or non-idempotent sequences of request methods (see Section 1980 6.1.2 of [Part2]). Otherwise, a premature termination of the 1981 transport connection could lead to indeterminate results. A client 1982 wishing to send a non-idempotent request SHOULD wait to send that 1983 request until it has received the response status line for the 1984 previous request. 1986 6.1.3. Proxy Servers 1988 It is especially important that proxies correctly implement the 1989 properties of the Connection header field as specified in 1990 Section 8.1. 1992 The proxy server MUST signal persistent connections separately with 1993 its clients and the origin servers (or other proxy servers) that it 1994 connects to. Each persistent connection applies to only one 1995 transport link. 1997 A proxy server MUST NOT establish a HTTP/1.1 persistent connection 1998 with an HTTP/1.0 client (but see Section 19.7.1 of [RFC2068] for 1999 information and discussion of the problems with the Keep-Alive header 2000 field implemented by many HTTP/1.0 clients). 2002 6.1.3.1. End-to-end and Hop-by-hop Header Fields 2004 For the purpose of defining the behavior of caches and non-caching 2005 proxies, we divide HTTP header fields into two categories: 2007 o End-to-end header fields, which are transmitted to the ultimate 2008 recipient of a request or response. End-to-end header fields in 2009 responses MUST be stored as part of a cache entry and MUST be 2010 transmitted in any response formed from a cache entry. 2012 o Hop-by-hop header fields, which are meaningful only for a single 2013 transport-level connection, and are not stored by caches or 2014 forwarded by proxies. 2016 The following HTTP/1.1 header fields are hop-by-hop header fields: 2018 o Connection 2020 o Keep-Alive 2022 o Proxy-Authenticate 2024 o Proxy-Authorization 2026 o TE 2028 o Trailer 2030 o Transfer-Encoding 2032 o Upgrade 2034 All other header fields defined by HTTP/1.1 are end-to-end header 2035 fields. 2037 Other hop-by-hop header fields MUST be listed in a Connection header 2038 field (Section 8.1). 2040 6.1.3.2. Non-modifiable Header Fields 2042 Some features of HTTP/1.1, such as Digest Authentication, depend on 2043 the value of certain end-to-end header fields. A non-transforming 2044 proxy SHOULD NOT modify an end-to-end header field unless the 2045 definition of that header field requires or specifically allows that. 2047 A non-transforming proxy MUST NOT modify any of the following fields 2048 in a request or response, and it MUST NOT add any of these fields if 2049 not already present: 2051 o Allow 2053 o Content-Location 2055 o Content-MD5 2057 o ETag 2059 o Last-Modified 2061 o Server 2063 A non-transforming proxy MUST NOT modify any of the following fields 2064 in a response: 2066 o Expires 2068 but it MAY add any of these fields if not already present. If an 2069 Expires header field is added, it MUST be given a field-value 2070 identical to that of the Date header field in that response. 2072 A proxy MUST NOT modify or add any of the following fields in a 2073 message that contains the no-transform cache-control directive, or in 2074 any request: 2076 o Content-Encoding 2078 o Content-Range 2080 o Content-Type 2082 A transforming proxy MAY modify or add these fields to a message that 2083 does not include no-transform, but if it does so, it MUST add a 2084 Warning 214 (Transformation applied) if one does not already appear 2085 in the message (see Section 3.6 of [Part6]). 2087 Warning: Unnecessary modification of end-to-end header fields 2088 might cause authentication failures if stronger authentication 2089 mechanisms are introduced in later versions of HTTP. Such 2090 authentication mechanisms MAY rely on the values of header fields 2091 not listed here. 2093 A non-transforming proxy MUST preserve the message payload ([Part3]), 2094 though it MAY change the message-body through application or removal 2095 of a transfer-coding (Section 5.1). 2097 6.1.4. Practical Considerations 2099 Servers will usually have some time-out value beyond which they will 2100 no longer maintain an inactive connection. Proxy servers might make 2101 this a higher value since it is likely that the client will be making 2102 more connections through the same server. The use of persistent 2103 connections places no requirements on the length (or existence) of 2104 this time-out for either the client or the server. 2106 When a client or server wishes to time-out it SHOULD issue a graceful 2107 close on the transport connection. Clients and servers SHOULD both 2108 constantly watch for the other side of the transport close, and 2109 respond to it as appropriate. If a client or server does not detect 2110 the other side's close promptly it could cause unnecessary resource 2111 drain on the network. 2113 A client, server, or proxy MAY close the transport connection at any 2114 time. For example, a client might have started to send a new request 2115 at the same time that the server has decided to close the "idle" 2116 connection. From the server's point of view, the connection is being 2117 closed while it was idle, but from the client's point of view, a 2118 request is in progress. 2120 Clients (including proxies) SHOULD limit the number of simultaneous 2121 connections that they maintain to a given server (including proxies). 2123 Previous revisions of HTTP gave a specific number of connections as a 2124 ceiling, but this was found to be impractical for many applications. 2125 As a result, this specification does not mandate a particular maximum 2126 number of connections, but instead encourages clients to be 2127 conservative when opening multiple connections. 2129 In particular, while using multiple connections avoids the "head-of- 2130 line blocking" problem (whereby a request that takes significant 2131 server-side processing and/or has a large payload can block 2132 subsequent requests on the same connection), each connection used 2133 consumes server resources (sometimes significantly), and furthermore 2134 using multiple connections can cause undesirable side effects in 2135 congested networks. 2137 Note that servers might reject traffic that they deem abusive, 2138 including an excessive number of connections from a client. 2140 6.1.5. Retrying Requests 2142 Senders can close the transport connection at any time. Therefore, 2143 clients, servers, and proxies MUST be able to recover from 2144 asynchronous close events. Client software MAY reopen the transport 2145 connection and retransmit the aborted sequence of requests without 2146 user interaction so long as the request sequence is idempotent (see 2147 Section 6.1.2 of [Part2]). Non-idempotent request methods or 2148 sequences MUST NOT be automatically retried, although user agents MAY 2149 offer a human operator the choice of retrying the request(s). 2150 Confirmation by user-agent software with semantic understanding of 2151 the application MAY substitute for user confirmation. The automatic 2152 retry SHOULD NOT be repeated if the second sequence of requests 2153 fails. 2155 6.2. Message Transmission Requirements 2157 6.2.1. Persistent Connections and Flow Control 2159 HTTP/1.1 servers SHOULD maintain persistent connections and use TCP's 2160 flow control mechanisms to resolve temporary overloads, rather than 2161 terminating connections with the expectation that clients will retry. 2162 The latter technique can exacerbate network congestion. 2164 6.2.2. Monitoring Connections for Error Status Messages 2166 An HTTP/1.1 (or later) client sending a message-body SHOULD monitor 2167 the network connection for an error status code while it is 2168 transmitting the request. If the client sees an error status code, 2169 it SHOULD immediately cease transmitting the body. If the body is 2170 being sent using a "chunked" encoding (Section 5.1), a zero length 2171 chunk and empty trailer MAY be used to prematurely mark the end of 2172 the message. If the body was preceded by a Content-Length header 2173 field, the client MUST close the connection. 2175 6.2.3. Use of the 100 (Continue) Status 2177 The purpose of the 100 (Continue) status code (see Section 7.1.1 of 2178 [Part2]) is to allow a client that is sending a request message with 2179 a request body to determine if the origin server is willing to accept 2180 the request (based on the request header fields) before the client 2181 sends the request body. In some cases, it might either be 2182 inappropriate or highly inefficient for the client to send the body 2183 if the server will reject the message without looking at the body. 2185 Requirements for HTTP/1.1 clients: 2187 o If a client will wait for a 100 (Continue) response before sending 2188 the request body, it MUST send an Expect header field (Section 9.3 2189 of [Part2]) with the "100-continue" expectation. 2191 o A client MUST NOT send an Expect header field (Section 9.3 of 2192 [Part2]) with the "100-continue" expectation if it does not intend 2193 to send a request body. 2195 Because of the presence of older implementations, the protocol allows 2196 ambiguous situations in which a client might send "Expect: 100- 2197 continue" without receiving either a 417 (Expectation Failed) or a 2198 100 (Continue) status code. Therefore, when a client sends this 2199 header field to an origin server (possibly via a proxy) from which it 2200 has never seen a 100 (Continue) status code, the client SHOULD NOT 2201 wait for an indefinite period before sending the request body. 2203 Requirements for HTTP/1.1 origin servers: 2205 o Upon receiving a request which includes an Expect header field 2206 with the "100-continue" expectation, an origin server MUST either 2207 respond with 100 (Continue) status code and continue to read from 2208 the input stream, or respond with a final status code. The origin 2209 server MUST NOT wait for the request body before sending the 100 2210 (Continue) response. If it responds with a final status code, it 2211 MAY close the transport connection or it MAY continue to read and 2212 discard the rest of the request. It MUST NOT perform the request 2213 method if it returns a final status code. 2215 o An origin server SHOULD NOT send a 100 (Continue) response if the 2216 request message does not include an Expect header field with the 2217 "100-continue" expectation, and MUST NOT send a 100 (Continue) 2218 response if such a request comes from an HTTP/1.0 (or earlier) 2219 client. There is an exception to this rule: for compatibility 2220 with [RFC2068], a server MAY send a 100 (Continue) status code in 2221 response to an HTTP/1.1 PUT or POST request that does not include 2222 an Expect header field with the "100-continue" expectation. This 2223 exception, the purpose of which is to minimize any client 2224 processing delays associated with an undeclared wait for 100 2225 (Continue) status code, applies only to HTTP/1.1 requests, and not 2226 to requests with any other HTTP-version value. 2228 o An origin server MAY omit a 100 (Continue) response if it has 2229 already received some or all of the request body for the 2230 corresponding request. 2232 o An origin server that sends a 100 (Continue) response MUST 2233 ultimately send a final status code, once the request body is 2234 received and processed, unless it terminates the transport 2235 connection prematurely. 2237 o If an origin server receives a request that does not include an 2238 Expect header field with the "100-continue" expectation, the 2239 request includes a request body, and the server responds with a 2240 final status code before reading the entire request body from the 2241 transport connection, then the server SHOULD NOT close the 2242 transport connection until it has read the entire request, or 2243 until the client closes the connection. Otherwise, the client 2244 might not reliably receive the response message. However, this 2245 requirement is not be construed as preventing a server from 2246 defending itself against denial-of-service attacks, or from badly 2247 broken client implementations. 2249 Requirements for HTTP/1.1 proxies: 2251 o If a proxy receives a request that includes an Expect header field 2252 with the "100-continue" expectation, and the proxy either knows 2253 that the next-hop server complies with HTTP/1.1 or higher, or does 2254 not know the HTTP version of the next-hop server, it MUST forward 2255 the request, including the Expect header field. 2257 o If the proxy knows that the version of the next-hop server is 2258 HTTP/1.0 or lower, it MUST NOT forward the request, and it MUST 2259 respond with a 417 (Expectation Failed) status code. 2261 o Proxies SHOULD maintain a record of the HTTP version numbers 2262 received from recently-referenced next-hop servers. 2264 o A proxy MUST NOT forward a 100 (Continue) response if the request 2265 message was received from an HTTP/1.0 (or earlier) client and did 2266 not include an Expect header field with the "100-continue" 2267 expectation. This requirement overrides the general rule for 2268 forwarding of 1xx responses (see Section 7.1 of [Part2]). 2270 7. Miscellaneous notes that might disappear 2272 7.1. Scheme aliases considered harmful 2274 [[TBD-aliases-harmful: describe why aliases like webcal are 2275 harmful.]] 2277 7.2. Use of HTTP for proxy communication 2279 [[TBD-proxy-other: Configured to use HTTP to proxy HTTP or other 2280 protocols.]] 2282 7.3. Interception of HTTP for access control 2284 [[TBD-intercept: Interception of HTTP traffic for initiating access 2285 control.]] 2287 7.4. Use of HTTP by other protocols 2289 [[TBD-profiles: Profiles of HTTP defined by other protocol. 2290 Extensions of HTTP like WebDAV.]] 2292 7.5. Use of HTTP by media type specification 2294 [[TBD-hypertext: Instructions on composing HTTP requests via 2295 hypertext formats.]] 2297 8. Header Field Definitions 2299 This section defines the syntax and semantics of HTTP header fields 2300 related to message origination, framing, and routing. 2302 +-------------------+---------------+ 2303 | Header Field Name | Defined in... | 2304 +-------------------+---------------+ 2305 | Connection | Section 8.1 | 2306 | Content-Length | Section 8.2 | 2307 | Host | Section 8.3 | 2308 | TE | Section 8.4 | 2309 | Trailer | Section 8.5 | 2310 | Transfer-Encoding | Section 8.6 | 2311 | Upgrade | Section 8.7 | 2312 | Via | Section 8.8 | 2313 +-------------------+---------------+ 2315 8.1. Connection 2317 The "Connection" header field allows the sender to specify options 2318 that are desired only for that particular connection. Such 2319 connection options MUST be removed or replaced before the message can 2320 be forwarded downstream by a proxy or gateway. This mechanism also 2321 allows the sender to indicate which HTTP header fields used in the 2322 message are only intended for the immediate recipient ("hop-by-hop"), 2323 as opposed to all recipients on the chain ("end-to-end"), enabling 2324 the message to be self-descriptive and allowing future connection- 2325 specific extensions to be deployed in HTTP without fear that they 2326 will be blindly forwarded by previously deployed intermediaries. 2328 The Connection header field's value has the following grammar: 2330 Connection = 1#connection-token 2331 connection-token = token 2333 A proxy or gateway MUST parse a received Connection header field 2334 before a message is forwarded and, for each connection-token in this 2335 field, remove any header field(s) from the message with the same name 2336 as the connection-token, and then remove the Connection header field 2337 itself or replace it with the sender's own connection options for the 2338 forwarded message. 2340 A sender MUST NOT include field-names in the Connection header field- 2341 value for fields that are defined as expressing constraints for all 2342 recipients in the request or response chain, such as the Cache- 2343 Control header field (Section 3.2 of [Part6]). 2345 The connection options do not have to correspond to a header field 2346 present in the message, since a connection-specific header field 2347 might not be needed if there are no parameters associated with that 2348 connection option. Recipients that trigger certain connection 2349 behavior based on the presence of connection options MUST do so based 2350 on the presence of the connection-token rather than only the presence 2351 of the optional header field. In other words, if the connection 2352 option is received as a header field but not indicated within the 2353 Connection field-value, then the recipient MUST ignore the 2354 connection-specific header field because it has likely been forwarded 2355 by an intermediary that is only partially compliant. 2357 When defining new connection options, specifications ought to 2358 carefully consider existing deployed header fields and ensure that 2359 the new connection-token does not share the same name as an unrelated 2360 header field that might already be deployed. Defining a new 2361 connection-token essentially reserves that potential field-name for 2362 carrying additional information related to the connection option, 2363 since it would be unwise for senders to use that field-name for 2364 anything else. 2366 HTTP/1.1 defines the "close" connection option for the sender to 2367 signal that the connection will be closed after completion of the 2368 response. For example, 2370 Connection: close 2372 in either the request or the response header fields indicates that 2373 the connection SHOULD NOT be considered "persistent" (Section 6.1) 2374 after the current request/response is complete. 2376 An HTTP/1.1 client that does not support persistent connections MUST 2377 include the "close" connection option in every request message. 2379 An HTTP/1.1 server that does not support persistent connections MUST 2380 include the "close" connection option in every response message that 2381 does not have a 1xx (Informational) status code. 2383 8.2. Content-Length 2385 The "Content-Length" header field indicates the size of the message- 2386 body, in decimal number of octets, for any message other than a 2387 response to a HEAD request or a response with a status code of 304. 2388 In the case of a response to a HEAD request, Content-Length indicates 2389 the size of the payload body (not including any potential transfer- 2390 coding) that would have been sent had the request been a GET. In the 2391 case of a 304 (Not Modified) response to a GET request, Content- 2392 Length indicates the size of the payload body (not including any 2393 potential transfer-coding) that would have been sent in a 200 (OK) 2394 response. 2396 Content-Length = 1*DIGIT 2398 An example is 2400 Content-Length: 3495 2402 Implementations SHOULD use this field to indicate the message-body 2403 length when no transfer-coding is being applied and the payload's 2404 body length can be determined prior to being transferred. 2405 Section 3.3 describes how recipients determine the length of a 2406 message-body. 2408 Any Content-Length greater than or equal to zero is a valid value. 2410 Note that the use of this field in HTTP is significantly different 2411 from the corresponding definition in MIME, where it is an optional 2412 field used within the "message/external-body" content-type. 2414 8.3. Host 2416 The "Host" header field in a request provides the host and port 2417 information from the target resource's URI, enabling the origin 2418 server to distinguish between resources while servicing requests for 2419 multiple host names on a single IP address. Since the Host field- 2420 value is critical information for handling a request, it SHOULD be 2421 sent as the first header field following the Request-Line. 2423 Host = uri-host [ ":" port ] ; Section 2.7.1 2425 A client MUST send a Host header field in all HTTP/1.1 request 2426 messages. If the target resource's URI includes an authority 2427 component, then the Host field-value MUST be identical to that 2428 authority component after excluding any userinfo (Section 2.7.1). If 2429 the authority component is missing or undefined for the target 2430 resource's URI, then the Host header field MUST be sent with an empty 2431 field-value. 2433 For example, a GET request to the origin server for 2434 would begin with: 2436 GET /pub/WWW/ HTTP/1.1 2437 Host: www.example.org 2439 The Host header field MUST be sent in an HTTP/1.1 request even if the 2440 request-target is in the form of an absolute-URI, since this allows 2441 the Host information to be forwarded through ancient HTTP/1.0 proxies 2442 that might not have implemented Host. 2444 When an HTTP/1.1 proxy receives a request with a request-target in 2445 the form of an absolute-URI, the proxy MUST ignore the received Host 2446 header field (if any) and instead replace it with the host 2447 information of the request-target. When a proxy forwards a request, 2448 it MUST generate the Host header field based on the received 2449 absolute-URI rather than the received Host. 2451 Since the Host header field acts as an application-level routing 2452 mechanism, it is a frequent target for malware seeking to poison a 2453 shared cache or redirect a request to an unintended server. An 2454 interception proxy is particularly vulnerable if it relies on the 2455 Host header field value for redirecting requests to internal servers, 2456 or for use as a cache key in a shared cache, without first verifying 2457 that the intercepted connection is targeting a valid IP address for 2458 that host. 2460 A server MUST respond with a 400 (Bad Request) status code to any 2461 HTTP/1.1 request message that lacks a Host header field and to any 2462 request message that contains more than one Host header field or a 2463 Host header field with an invalid field-value. 2465 See Sections 4.2 and A.1.1 for other requirements relating to Host. 2467 8.4. TE 2469 The "TE" header field indicates what extension transfer-codings it is 2470 willing to accept in the response, and whether or not it is willing 2471 to accept trailer fields in a chunked transfer-coding. 2473 Its value consists of the keyword "trailers" and/or a comma-separated 2474 list of extension transfer-coding names with optional accept 2475 parameters (as described in Section 5.1). 2477 TE = #t-codings 2478 t-codings = "trailers" / ( transfer-extension [ te-params ] ) 2479 te-params = OWS ";" OWS "q=" qvalue *( te-ext ) 2480 te-ext = OWS ";" OWS token [ "=" word ] 2482 The presence of the keyword "trailers" indicates that the client is 2483 willing to accept trailer fields in a chunked transfer-coding, as 2484 defined in Section 5.1.1. This keyword is reserved for use with 2485 transfer-coding values even though it does not itself represent a 2486 transfer-coding. 2488 Examples of its use are: 2490 TE: deflate 2491 TE: 2492 TE: trailers, deflate;q=0.5 2494 The TE header field only applies to the immediate connection. 2495 Therefore, the keyword MUST be supplied within a Connection header 2496 field (Section 8.1) whenever TE is present in an HTTP/1.1 message. 2498 A server tests whether a transfer-coding is acceptable, according to 2499 a TE field, using these rules: 2501 1. The "chunked" transfer-coding is always acceptable. If the 2502 keyword "trailers" is listed, the client indicates that it is 2503 willing to accept trailer fields in the chunked response on 2504 behalf of itself and any downstream clients. The implication is 2505 that, if given, the client is stating that either all downstream 2506 clients are willing to accept trailer fields in the forwarded 2507 response, or that it will attempt to buffer the response on 2508 behalf of downstream recipients. 2510 Note: HTTP/1.1 does not define any means to limit the size of a 2511 chunked response such that a client can be assured of buffering 2512 the entire response. 2514 2. If the transfer-coding being tested is one of the transfer- 2515 codings listed in the TE field, then it is acceptable unless it 2516 is accompanied by a qvalue of 0. (As defined in Section 5.3, a 2517 qvalue of 0 means "not acceptable".) 2519 3. If multiple transfer-codings are acceptable, then the acceptable 2520 transfer-coding with the highest non-zero qvalue is preferred. 2521 The "chunked" transfer-coding always has a qvalue of 1. 2523 If the TE field-value is empty or if no TE field is present, the only 2524 transfer-coding is "chunked". A message with no transfer-coding is 2525 always acceptable. 2527 8.5. Trailer 2529 The "Trailer" header field indicates that the given set of header 2530 fields is present in the trailer of a message encoded with chunked 2531 transfer-coding. 2533 Trailer = 1#field-name 2535 An HTTP/1.1 message SHOULD include a Trailer header field in a 2536 message using chunked transfer-coding with a non-empty trailer. 2537 Doing so allows the recipient to know which header fields to expect 2538 in the trailer. 2540 If no Trailer header field is present, the trailer SHOULD NOT include 2541 any header fields. See Section 5.1.1 for restrictions on the use of 2542 trailer fields in a "chunked" transfer-coding. 2544 Message header fields listed in the Trailer header field MUST NOT 2545 include the following header fields: 2547 o Transfer-Encoding 2549 o Content-Length 2551 o Trailer 2553 8.6. Transfer-Encoding 2555 The "Transfer-Encoding" header field indicates what transfer-codings 2556 (if any) have been applied to the message body. It differs from 2557 Content-Encoding (Section 2.2 of [Part3]) in that transfer-codings 2558 are a property of the message (and therefore are removed by 2559 intermediaries), whereas content-codings are not. 2561 Transfer-Encoding = 1#transfer-coding 2563 Transfer-codings are defined in Section 5.1. An example is: 2565 Transfer-Encoding: chunked 2567 If multiple encodings have been applied to a representation, the 2568 transfer-codings MUST be listed in the order in which they were 2569 applied. Additional information about the encoding parameters MAY be 2570 provided by other header fields not defined by this specification. 2572 Many older HTTP/1.0 applications do not understand the Transfer- 2573 Encoding header field. 2575 8.7. Upgrade 2577 The "Upgrade" header field allows the client to specify what 2578 additional communication protocols it would like to use, if the 2579 server chooses to switch protocols. Servers can use it to indicate 2580 what protocols they are willing to switch to. 2582 Upgrade = 1#product 2584 For example, 2586 Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11 2588 The Upgrade header field is intended to provide a simple mechanism 2589 for transition from HTTP/1.1 to some other, incompatible protocol. 2590 It does so by allowing the client to advertise its desire to use 2591 another protocol, such as a later version of HTTP with a higher major 2592 version number, even though the current request has been made using 2593 HTTP/1.1. This eases the difficult transition between incompatible 2594 protocols by allowing the client to initiate a request in the more 2595 commonly supported protocol while indicating to the server that it 2596 would like to use a "better" protocol if available (where "better" is 2597 determined by the server, possibly according to the nature of the 2598 request method or target resource). 2600 The Upgrade header field only applies to switching application-layer 2601 protocols upon the existing transport-layer connection. Upgrade 2602 cannot be used to insist on a protocol change; its acceptance and use 2603 by the server is optional. The capabilities and nature of the 2604 application-layer communication after the protocol change is entirely 2605 dependent upon the new protocol chosen, although the first action 2606 after changing the protocol MUST be a response to the initial HTTP 2607 request containing the Upgrade header field. 2609 The Upgrade header field only applies to the immediate connection. 2610 Therefore, the upgrade keyword MUST be supplied within a Connection 2611 header field (Section 8.1) whenever Upgrade is present in an HTTP/1.1 2612 message. 2614 The Upgrade header field cannot be used to indicate a switch to a 2615 protocol on a different connection. For that purpose, it is more 2616 appropriate to use a 3xx redirection response (Section 7.3 of 2617 [Part2]). 2619 Servers MUST include the "Upgrade" header field in 101 (Switching 2620 Protocols) responses to indicate which protocol(s) are being switched 2621 to, and MUST include it in 426 (Upgrade Required) responses to 2622 indicate acceptable protocols to upgrade to. Servers MAY include it 2623 in any other response to indicate that they are willing to upgrade to 2624 one of the specified protocols. 2626 This specification only defines the protocol name "HTTP" for use by 2627 the family of Hypertext Transfer Protocols, as defined by the HTTP 2628 version rules of Section 2.6 and future updates to this 2629 specification. Additional tokens can be registered with IANA using 2630 the registration procedure defined below. 2632 8.7.1. Upgrade Token Registry 2634 The HTTP Upgrade Token Registry defines the name space for product 2635 tokens used to identify protocols in the Upgrade header field. Each 2636 registered token is associated with contact information and an 2637 optional set of specifications that details how the connection will 2638 be processed after it has been upgraded. 2640 Registrations are allowed on a First Come First Served basis as 2641 described in Section 4.1 of [RFC5226]. The specifications need not 2642 be IETF documents or be subject to IESG review. Registrations are 2643 subject to the following rules: 2645 1. A token, once registered, stays registered forever. 2647 2. The registration MUST name a responsible party for the 2648 registration. 2650 3. The registration MUST name a point of contact. 2652 4. The registration MAY name a set of specifications associated with 2653 that token. Such specifications need not be publicly available. 2655 5. The responsible party MAY change the registration at any time. 2656 The IANA will keep a record of all such changes, and make them 2657 available upon request. 2659 6. The responsible party for the first registration of a "product" 2660 token MUST approve later registrations of a "version" token 2661 together with that "product" token before they can be registered. 2663 7. If absolutely required, the IESG MAY reassign the responsibility 2664 for a token. This will normally only be used in the case when a 2665 responsible party cannot be contacted. 2667 8.8. Via 2669 The "Via" header field MUST be sent by a proxy or gateway to indicate 2670 the intermediate protocols and recipients between the user agent and 2671 the server on requests, and between the origin server and the client 2672 on responses. It is analogous to the "Received" field used by email 2673 systems (Section 3.6.7 of [RFC5322]) and is intended to be used for 2674 tracking message forwards, avoiding request loops, and identifying 2675 the protocol capabilities of all senders along the request/response 2676 chain. 2678 Via = 1#( received-protocol RWS received-by 2679 [ RWS comment ] ) 2680 received-protocol = [ protocol-name "/" ] protocol-version 2681 protocol-name = token 2682 protocol-version = token 2683 received-by = ( uri-host [ ":" port ] ) / pseudonym 2684 pseudonym = token 2686 The received-protocol indicates the protocol version of the message 2687 received by the server or client along each segment of the request/ 2688 response chain. The received-protocol version is appended to the Via 2689 field value when the message is forwarded so that information about 2690 the protocol capabilities of upstream applications remains visible to 2691 all recipients. 2693 The protocol-name is excluded if and only if it would be "HTTP". The 2694 received-by field is normally the host and optional port number of a 2695 recipient server or client that subsequently forwarded the message. 2696 However, if the real host is considered to be sensitive information, 2697 it MAY be replaced by a pseudonym. If the port is not given, it MAY 2698 be assumed to be the default port of the received-protocol. 2700 Multiple Via field values represent each proxy or gateway that has 2701 forwarded the message. Each recipient MUST append its information 2702 such that the end result is ordered according to the sequence of 2703 forwarding applications. 2705 Comments MAY be used in the Via header field to identify the software 2706 of each recipient, analogous to the User-Agent and Server header 2707 fields. However, all comments in the Via field are optional and MAY 2708 be removed by any recipient prior to forwarding the message. 2710 For example, a request message could be sent from an HTTP/1.0 user 2711 agent to an internal proxy code-named "fred", which uses HTTP/1.1 to 2712 forward the request to a public proxy at p.example.net, which 2713 completes the request by forwarding it to the origin server at 2714 www.example.com. The request received by www.example.com would then 2715 have the following Via header field: 2717 Via: 1.0 fred, 1.1 p.example.net (Apache/1.1) 2719 A proxy or gateway used as a portal through a network firewall SHOULD 2720 NOT forward the names and ports of hosts within the firewall region 2721 unless it is explicitly enabled to do so. If not enabled, the 2722 received-by host of any host behind the firewall SHOULD be replaced 2723 by an appropriate pseudonym for that host. 2725 For organizations that have strong privacy requirements for hiding 2726 internal structures, a proxy or gateway MAY combine an ordered 2727 subsequence of Via header field entries with identical received- 2728 protocol values into a single such entry. For example, 2730 Via: 1.0 ricky, 1.1 ethel, 1.1 fred, 1.0 lucy 2732 could be collapsed to 2734 Via: 1.0 ricky, 1.1 mertz, 1.0 lucy 2736 Senders SHOULD NOT combine multiple entries unless they are all under 2737 the same organizational control and the hosts have already been 2738 replaced by pseudonyms. Senders MUST NOT combine entries which have 2739 different received-protocol values. 2741 9. IANA Considerations 2743 9.1. Header Field Registration 2745 The Message Header Field Registry located at shall be 2747 updated with the permanent registrations below (see [RFC3864]): 2749 +-------------------+----------+----------+-------------+ 2750 | Header Field Name | Protocol | Status | Reference | 2751 +-------------------+----------+----------+-------------+ 2752 | Connection | http | standard | Section 8.1 | 2753 | Content-Length | http | standard | Section 8.2 | 2754 | Host | http | standard | Section 8.3 | 2755 | TE | http | standard | Section 8.4 | 2756 | Trailer | http | standard | Section 8.5 | 2757 | Transfer-Encoding | http | standard | Section 8.6 | 2758 | Upgrade | http | standard | Section 8.7 | 2759 | Via | http | standard | Section 8.8 | 2760 +-------------------+----------+----------+-------------+ 2762 Furthermore, the header field name "Close" shall be registered as 2763 "reserved", as its use as HTTP header field would be in conflict with 2764 the use of the "close" connection option for the "Connection" header 2765 field (Section 8.1). 2767 +-------------------+----------+----------+-------------+ 2768 | Header Field Name | Protocol | Status | Reference | 2769 +-------------------+----------+----------+-------------+ 2770 | Close | http | reserved | Section 9.1 | 2771 +-------------------+----------+----------+-------------+ 2773 The change controller is: "IETF (iesg@ietf.org) - Internet 2774 Engineering Task Force". 2776 9.2. URI Scheme Registration 2778 The entries for the "http" and "https" URI Schemes in the registry 2779 located at shall 2780 be updated to point to Sections 2.7.1 and 2.7.2 of this document (see 2781 [RFC4395]). 2783 9.3. Internet Media Type Registrations 2785 This document serves as the specification for the Internet media 2786 types "message/http" and "application/http". The following is to be 2787 registered with IANA (see [RFC4288]). 2789 9.3.1. Internet Media Type message/http 2791 The message/http type can be used to enclose a single HTTP request or 2792 response message, provided that it obeys the MIME restrictions for 2793 all "message" types regarding line length and encodings. 2795 Type name: message 2797 Subtype name: http 2799 Required parameters: none 2801 Optional parameters: version, msgtype 2803 version: The HTTP-Version number of the enclosed message (e.g., 2804 "1.1"). If not present, the version can be determined from the 2805 first line of the body. 2807 msgtype: The message type -- "request" or "response". If not 2808 present, the type can be determined from the first line of the 2809 body. 2811 Encoding considerations: only "7bit", "8bit", or "binary" are 2812 permitted 2814 Security considerations: none 2816 Interoperability considerations: none 2818 Published specification: This specification (see Section 9.3.1). 2820 Applications that use this media type: 2822 Additional information: 2824 Magic number(s): none 2826 File extension(s): none 2828 Macintosh file type code(s): none 2830 Person and email address to contact for further information: See 2831 Authors Section. 2833 Intended usage: COMMON 2835 Restrictions on usage: none 2837 Author/Change controller: IESG 2839 9.3.2. Internet Media Type application/http 2841 The application/http type can be used to enclose a pipeline of one or 2842 more HTTP request or response messages (not intermixed). 2844 Type name: application 2846 Subtype name: http 2848 Required parameters: none 2850 Optional parameters: version, msgtype 2852 version: The HTTP-Version number of the enclosed messages (e.g., 2853 "1.1"). If not present, the version can be determined from the 2854 first line of the body. 2856 msgtype: The message type -- "request" or "response". If not 2857 present, the type can be determined from the first line of the 2858 body. 2860 Encoding considerations: HTTP messages enclosed by this type are in 2861 "binary" format; use of an appropriate Content-Transfer-Encoding 2862 is required when transmitted via E-mail. 2864 Security considerations: none 2866 Interoperability considerations: none 2868 Published specification: This specification (see Section 9.3.2). 2870 Applications that use this media type: 2872 Additional information: 2874 Magic number(s): none 2876 File extension(s): none 2878 Macintosh file type code(s): none 2880 Person and email address to contact for further information: See 2881 Authors Section. 2883 Intended usage: COMMON 2884 Restrictions on usage: none 2886 Author/Change controller: IESG 2888 9.4. Transfer Coding Registry 2890 The registration procedure for HTTP Transfer Codings is now defined 2891 by Section 5.1.3 of this document. 2893 The HTTP Transfer Codings Registry located at 2894 shall be updated 2895 with the registrations below: 2897 +----------+--------------------------------------+-----------------+ 2898 | Name | Description | Reference | 2899 +----------+--------------------------------------+-----------------+ 2900 | chunked | Transfer in a series of chunks | Section 5.1.1 | 2901 | compress | UNIX "compress" program method | Section 5.1.2.1 | 2902 | deflate | "deflate" compression mechanism | Section 5.1.2.2 | 2903 | | ([RFC1951]) used inside the "zlib" | | 2904 | | data format ([RFC1950]) | | 2905 | gzip | Same as GNU zip [RFC1952] | Section 5.1.2.3 | 2906 +----------+--------------------------------------+-----------------+ 2908 9.5. Upgrade Token Registration 2910 The registration procedure for HTTP Upgrade Tokens -- previously 2911 defined in Section 7.2 of [RFC2817] -- is now defined by 2912 Section 8.7.1 of this document. 2914 The HTTP Status Code Registry located at 2915 shall be 2916 updated with the registration below: 2918 +-------+---------------------------+-------------------------------+ 2919 | Value | Description | Reference | 2920 +-------+---------------------------+-------------------------------+ 2921 | HTTP | Hypertext Transfer | Section 2.6 of this | 2922 | | Protocol | specification | 2923 +-------+---------------------------+-------------------------------+ 2925 10. Security Considerations 2927 This section is meant to inform application developers, information 2928 providers, and users of the security limitations in HTTP/1.1 as 2929 described by this document. The discussion does not include 2930 definitive solutions to the problems revealed, though it does make 2931 some suggestions for reducing security risks. 2933 10.1. Personal Information 2935 HTTP clients are often privy to large amounts of personal information 2936 (e.g., the user's name, location, mail address, passwords, encryption 2937 keys, etc.), and SHOULD be very careful to prevent unintentional 2938 leakage of this information. We very strongly recommend that a 2939 convenient interface be provided for the user to control 2940 dissemination of such information, and that designers and 2941 implementors be particularly careful in this area. History shows 2942 that errors in this area often create serious security and/or privacy 2943 problems and generate highly adverse publicity for the implementor's 2944 company. 2946 10.2. Abuse of Server Log Information 2948 A server is in the position to save personal data about a user's 2949 requests which might identify their reading patterns or subjects of 2950 interest. This information is clearly confidential in nature and its 2951 handling can be constrained by law in certain countries. People 2952 using HTTP to provide data are responsible for ensuring that such 2953 material is not distributed without the permission of any individuals 2954 that are identifiable by the published results. 2956 10.3. Attacks Based On File and Path Names 2958 Implementations of HTTP origin servers SHOULD be careful to restrict 2959 the documents returned by HTTP requests to be only those that were 2960 intended by the server administrators. If an HTTP server translates 2961 HTTP URIs directly into file system calls, the server MUST take 2962 special care not to serve files that were not intended to be 2963 delivered to HTTP clients. For example, UNIX, Microsoft Windows, and 2964 other operating systems use ".." as a path component to indicate a 2965 directory level above the current one. On such a system, an HTTP 2966 server MUST disallow any such construct in the request-target if it 2967 would otherwise allow access to a resource outside those intended to 2968 be accessible via the HTTP server. Similarly, files intended for 2969 reference only internally to the server (such as access control 2970 files, configuration files, and script code) MUST be protected from 2971 inappropriate retrieval, since they might contain sensitive 2972 information. Experience has shown that minor bugs in such HTTP 2973 server implementations have turned into security risks. 2975 10.4. DNS-related Attacks 2977 HTTP clients rely heavily on the Domain Name Service (DNS), and are 2978 thus generally prone to security attacks based on the deliberate 2979 misassociation of IP addresses and DNS names not protected by DNSSec. 2980 Clients need to be cautious in assuming the validity of an IP number/ 2981 DNS name association unless the response is protected by DNSSec 2982 ([RFC4033]). 2984 10.5. Proxies and Caching 2986 By their very nature, HTTP proxies are men-in-the-middle, and 2987 represent an opportunity for man-in-the-middle attacks. Compromise 2988 of the systems on which the proxies run can result in serious 2989 security and privacy problems. Proxies have access to security- 2990 related information, personal information about individual users and 2991 organizations, and proprietary information belonging to users and 2992 content providers. A compromised proxy, or a proxy implemented or 2993 configured without regard to security and privacy considerations, 2994 might be used in the commission of a wide range of potential attacks. 2996 Proxy operators need to protect the systems on which proxies run as 2997 they would protect any system that contains or transports sensitive 2998 information. In particular, log information gathered at proxies 2999 often contains highly sensitive personal information, and/or 3000 information about organizations. Log information needs to be 3001 carefully guarded, and appropriate guidelines for use need to be 3002 developed and followed. (Section 10.2). 3004 Proxy implementors need to consider the privacy and security 3005 implications of their design and coding decisions, and of the 3006 configuration options they provide to proxy operators (especially the 3007 default configuration). 3009 Users of a proxy need to be aware that proxies are no trustworthier 3010 than the people who run them; HTTP itself cannot solve this problem. 3012 The judicious use of cryptography, when appropriate, might suffice to 3013 protect against a broad range of security and privacy attacks. Such 3014 cryptography is beyond the scope of the HTTP/1.1 specification. 3016 10.6. Protocol Element Size Overflows 3018 Because HTTP uses mostly textual, character-delimited fields, 3019 attackers can overflow buffers in implementations, and/or perform a 3020 Denial of Service against implementations that accept fields with 3021 unlimited lengths. 3023 To promote interoperability, this specification makes specific 3024 recommendations for size limits on request-targets (Section 3.1.1.2) 3025 and blocks of header fields (Section 3.2). These are minimum 3026 recommendations, chosen to be supportable even by implementations 3027 with limited resources; it is expected that most implementations will 3028 choose substantially higher limits. 3030 This specification also provides a way for servers to reject messages 3031 that have request-targets that are too long (Section 7.4.15 of 3032 [Part2]) or request entities that are too large (Section 7.4 of 3033 [Part2]). 3035 Other fields (including but not limited to request methods, response 3036 status phrases, header field-names, and body chunks) SHOULD be 3037 limited by implementations carefully, so as to not impede 3038 interoperability. 3040 10.7. Denial of Service Attacks on Proxies 3042 They exist. They are hard to defend against. Research continues. 3043 Beware. 3045 11. Acknowledgments 3047 This document revision builds on the work that went into RFC 2616 and 3048 its predecessors. See Section 16 of [RFC2616] for detailed 3049 acknowledgements. 3051 Since 1999, many contributors have helped by reporting bugs, asking 3052 smart questions, drafting and reviewing text, and discussing open 3053 issues: 3055 Adam Barth, Adam Roach, Addison Phillips, Adrian Chadd, Adrien de 3056 Croy, Alan Ford, Alan Ruttenberg, Albert Lunde, Alex Rousskov, Alexey 3057 Melnikov, Alisha Smith, Amichai Rothman, Amit Klein, Amos Jeffries, 3058 Andreas Maier, Andreas Petersson, Anne van Kesteren, Anthony Bryan, 3059 Asbjorn Ulsberg, Balachander Krishnamurthy, Barry Leiba, Ben Laurie, 3060 Benjamin Niven-Jenkins, Bil Corry, Bill Burke, Bjoern Hoehrmann, Bob 3061 Scheifler, Boris Zbarsky, Brett Slatkin, Brian Kell, Brian McBarron, 3062 Brian Pane, Brian Smith, Bryce Nesbitt, Cameron Heavon-Jones, Carl 3063 Kugler, Charles Fry, Chris Newman, Cyrus Daboo, Dale Robert Anderson, 3064 Dan Winship, Daniel Stenberg, Dave Cridland, Dave Crocker, Dave 3065 Kristol, David Booth, David Singer, David W. Morris, Diwakar Shetty, 3066 Dmitry Kurochkin, Drummond Reed, Duane Wessels, Edward Lee, Eliot 3067 Lear, Eran Hammer-Lahav, Eric D. Williams, Eric J. Bowman, Eric 3068 Lawrence, Erik Aronesty, Florian Weimer, Frank Ellermann, Fred Bohle, 3069 Geoffrey Sneddon, Gervase Markham, Greg Wilkins, Harald Tveit 3070 Alvestrand, Harry Halpin, Helge Hess, Henrik Nordstrom, Henry S. 3071 Thompson, Henry Story, Herbert van de Sompel, Howard Melman, Hugo 3072 Haas, Ian Hickson, Ingo Struck, J. Ross Nicoll, James H. Manger, 3073 James Lacey, James M. Snell, Jamie Lokier, Jan Algermissen, Jeff 3074 Hodges (for coming up with the term 'effective Request-URI'), Jeff 3075 Walden, Jim Luther, Joe D. Williams, Joe Gregorio, Joe Orton, John C. 3076 Klensin, John C. Mallery, John Cowan, John Kemp, John Panzer, John 3077 Schneider, John Stracke, Jonas Sicking, Jonathan Moore, Jonathan 3078 Rees, Jordi Ros, Joris Dobbelsteen, Josh Cohen, Julien Pierre, 3079 Jungshik Shin, Justin Chapweske, Justin Erenkrantz, Justin James, 3080 Kalvinder Singh, Karl Dubost, Keith Hoffman, Keith Moore, Koen 3081 Holtman, Konstantin Voronkov, Kris Zyp, Lisa Dusseault, Maciej 3082 Stachowiak, Marc Schneider, Marc Slemko, Mark Baker, Mark Nottingham 3083 (Working Group chair), Mark Pauley, Martin J. Duerst, Martin Thomson, 3084 Matt Lynch, Matthew Cox, Max Clark, Michael Burrows, Michael 3085 Hausenblas, Mike Amundsen, Mike Kelly, Mike Schinkel, Miles Sabin, 3086 Mykyta Yevstifeyev, Nathan Rixham, Nicholas Shanks, Nico Williams, 3087 Nicolas Alvarez, Noah Slater, Pablo Castro, Pat Hayes, Patrick R. 3088 McManus, Paul E. Jones, Paul Hoffman, Paul Marquess, Peter Saint- 3089 Andre, Peter Watkins, Phil Archer, Phillip Hallam-Baker, Poul-Henning 3090 Kamp, Preethi Natarajan, Reto Bachmann-Gmuer, Richard Cyganiak, 3091 Robert Brewer, Robert Collins, Robert O'Callahan, Robert Olofsson, 3092 Robert Sayre, Robert Siemer, Robert de Wilde, Roberto Javier Godoy, 3093 Ronny Widjaja, S. Mike Dierken, Salvatore Loreto, Sam Johnston, Sam 3094 Ruby, Scott Lawrence (for maintaining the original issues list), Sean 3095 B. Palmer, Shane McCarron, Stefan Eissing, Stefan Tilkov, Stefanos 3096 Harhalakis, Stephane Bortzmeyer, Stuart Williams, Subbu Allamaraju, 3097 Sylvain Hellegouarch, Tapan Divekar, Thomas Broyer, Thomas Nordin, 3098 Thomas Roessler, Tim Morgan, Tim Olsen, Travis Snoozy, Tyler Close, 3099 Vincent Murphy, Wenbo Zhu, Werner Baumann, Wilbur Streett, Wilfredo 3100 Sanchez Vega, William A. Rowe Jr., William Chan, Willy Tarreau, 3101 Xiaoshu Wang, Yaron Goland, Yngve Nysaeter Pettersen, Yogesh Bang, 3102 Yutaka Oiwa, and Zed A. Shaw. 3104 12. References 3106 12.1. Normative References 3108 [ISO-8859-1] International Organization for Standardization, 3109 "Information technology -- 8-bit single-byte coded 3110 graphic character sets -- Part 1: Latin alphabet No. 3111 1", ISO/IEC 8859-1:1998, 1998. 3113 [Part2] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., 3114 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., 3115 Ed., and J. Reschke, Ed., "HTTP/1.1, part 2: Message 3116 Semantics", draft-ietf-httpbis-p2-semantics-18 (work in 3117 progress), January 2012. 3119 [Part3] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., 3120 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., 3121 Ed., and J. Reschke, Ed., "HTTP/1.1, part 3: Message 3122 Payload and Content Negotiation", 3123 draft-ietf-httpbis-p3-payload-18 (work in progress), 3124 January 2012. 3126 [Part6] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., 3127 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., 3128 Ed., Nottingham, M., Ed., and J. Reschke, Ed., 3129 "HTTP/1.1, part 6: Caching", 3130 draft-ietf-httpbis-p6-cache-18 (work in progress), 3131 January 2012. 3133 [RFC1950] Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data 3134 Format Specification version 3.3", RFC 1950, May 1996. 3136 [RFC1951] Deutsch, P., "DEFLATE Compressed Data Format 3137 Specification version 1.3", RFC 1951, May 1996. 3139 [RFC1952] Deutsch, P., Gailly, J-L., Adler, M., Deutsch, L., and 3140 G. Randers-Pehrson, "GZIP file format specification 3141 version 4.3", RFC 1952, May 1996. 3143 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3144 Requirement Levels", BCP 14, RFC 2119, March 1997. 3146 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, 3147 "Uniform Resource Identifier (URI): Generic Syntax", 3148 STD 66, RFC 3986, January 2005. 3150 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for 3151 Syntax Specifications: ABNF", STD 68, RFC 5234, 3152 January 2008. 3154 [USASCII] American National Standards Institute, "Coded Character 3155 Set -- 7-bit American Standard Code for Information 3156 Interchange", ANSI X3.4, 1986. 3158 12.2. Informative References 3160 [Kri2001] Kristol, D., "HTTP Cookies: Standards, Privacy, and 3161 Politics", ACM Transactions on Internet Technology Vol. 3162 1, #2, November 2001, 3163 . 3165 [Nie1997] Frystyk, H., Gettys, J., Prud'hommeaux, E., Lie, H., 3166 and C. Lilley, "Network Performance Effects of 3167 HTTP/1.1, CSS1, and PNG", ACM Proceedings of the ACM 3168 SIGCOMM '97 conference on Applications, technologies, 3169 architectures, and protocols for computer communication 3170 SIGCOMM '97, September 1997, 3171 . 3173 [Pad1995] Padmanabhan, V. and J. Mogul, "Improving HTTP Latency", 3174 Computer Networks and ISDN Systems v. 28, pp. 25-35, 3175 December 1995, 3176 . 3178 [RFC1919] Chatel, M., "Classical versus Transparent IP Proxies", 3179 RFC 1919, March 1996. 3181 [RFC1945] Berners-Lee, T., Fielding, R., and H. Nielsen, 3182 "Hypertext Transfer Protocol -- HTTP/1.0", RFC 1945, 3183 May 1996. 3185 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet 3186 Mail Extensions (MIME) Part One: Format of Internet 3187 Message Bodies", RFC 2045, November 1996. 3189 [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail 3190 Extensions) Part Three: Message Header Extensions for 3191 Non-ASCII Text", RFC 2047, November 1996. 3193 [RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and 3194 T. Berners-Lee, "Hypertext Transfer Protocol -- 3195 HTTP/1.1", RFC 2068, January 1997. 3197 [RFC2145] Mogul, J., Fielding, R., Gettys, J., and H. Nielsen, 3198 "Use and Interpretation of HTTP Version Numbers", 3199 RFC 2145, May 1997. 3201 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 3202 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 3203 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 3205 [RFC2817] Khare, R. and S. Lawrence, "Upgrading to TLS Within 3206 HTTP/1.1", RFC 2817, May 2000. 3208 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 3210 [RFC2965] Kristol, D. and L. Montulli, "HTTP State Management 3211 Mechanism", RFC 2965, October 2000. 3213 [RFC3040] Cooper, I., Melve, I., and G. Tomlinson, "Internet Web 3214 Replication and Caching Taxonomy", RFC 3040, 3215 January 2001. 3217 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration 3218 Procedures for Message Header Fields", BCP 90, 3219 RFC 3864, September 2004. 3221 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 3223 Rose, "DNS Security Introduction and Requirements", 3224 RFC 4033, March 2005. 3226 [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications 3227 and Registration Procedures", BCP 13, RFC 4288, 3228 December 2005. 3230 [RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines 3231 and Registration Procedures for New URI Schemes", 3232 BCP 115, RFC 4395, February 2006. 3234 [RFC4559] Jaganathan, K., Zhu, L., and J. Brezak, "SPNEGO-based 3235 Kerberos and NTLM HTTP Authentication in Microsoft 3236 Windows", RFC 4559, June 2006. 3238 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing 3239 an IANA Considerations Section in RFCs", BCP 26, 3240 RFC 5226, May 2008. 3242 [RFC5322] Resnick, P., "Internet Message Format", RFC 5322, 3243 October 2008. 3245 [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, 3246 April 2011. 3248 [Spe] Spero, S., "Analysis of HTTP Performance Problems", 3249 . 3251 [Tou1998] Touch, J., Heidemann, J., and K. Obraczka, "Analysis of 3252 HTTP Performance", ISI Research Report ISI/RR-98-463, 3253 Aug 1998, . 3255 (original report dated Aug. 1996) 3257 Appendix A. HTTP Version History 3259 HTTP has been in use by the World-Wide Web global information 3260 initiative since 1990. The first version of HTTP, later referred to 3261 as HTTP/0.9, was a simple protocol for hypertext data transfer across 3262 the Internet with only a single request method (GET) and no metadata. 3263 HTTP/1.0, as defined by [RFC1945], added a range of request methods 3264 and MIME-like messaging that could include metadata about the data 3265 transferred and modifiers on the request/response semantics. 3266 However, HTTP/1.0 did not sufficiently take into consideration the 3267 effects of hierarchical proxies, caching, the need for persistent 3268 connections, or name-based virtual hosts. The proliferation of 3269 incompletely-implemented applications calling themselves "HTTP/1.0" 3270 further necessitated a protocol version change in order for two 3271 communicating applications to determine each other's true 3272 capabilities. 3274 HTTP/1.1 remains compatible with HTTP/1.0 by including more stringent 3275 requirements that enable reliable implementations, adding only those 3276 new features that will either be safely ignored by an HTTP/1.0 3277 recipient or only sent when communicating with a party advertising 3278 compliance with HTTP/1.1. 3280 It is beyond the scope of a protocol specification to mandate 3281 compliance with previous versions. HTTP/1.1 was deliberately 3282 designed, however, to make supporting previous versions easy. We 3283 would expect a general-purpose HTTP/1.1 server to understand any 3284 valid request in the format of HTTP/1.0 and respond appropriately 3285 with an HTTP/1.1 message that only uses features understood (or 3286 safely ignored) by HTTP/1.0 clients. Likewise, would expect an 3287 HTTP/1.1 client to understand any valid HTTP/1.0 response. 3289 Since HTTP/0.9 did not support header fields in a request, there is 3290 no mechanism for it to support name-based virtual hosts (selection of 3291 resource by inspection of the Host header field). Any server that 3292 implements name-based virtual hosts ought to disable support for 3293 HTTP/0.9. Most requests that appear to be HTTP/0.9 are, in fact, 3294 badly constructed HTTP/1.x requests wherein a buggy client failed to 3295 properly encode linear whitespace found in a URI reference and placed 3296 in the request-target. 3298 A.1. Changes from HTTP/1.0 3300 This section summarizes major differences between versions HTTP/1.0 3301 and HTTP/1.1. 3303 A.1.1. Multi-homed Web Servers 3305 The requirements that clients and servers support the Host header 3306 field (Section 8.3), report an error if it is missing from an 3307 HTTP/1.1 request, and accept absolute URIs (Section 3.1.1.2) are 3308 among the most important changes defined by HTTP/1.1. 3310 Older HTTP/1.0 clients assumed a one-to-one relationship of IP 3311 addresses and servers; there was no other established mechanism for 3312 distinguishing the intended server of a request than the IP address 3313 to which that request was directed. The Host header field was 3314 introduced during the development of HTTP/1.1 and, though it was 3315 quickly implemented by most HTTP/1.0 browsers, additional 3316 requirements were placed on all HTTP/1.1 requests in order to ensure 3317 complete adoption. At the time of this writing, most HTTP-based 3318 services are dependent upon the Host header field for targeting 3319 requests. 3321 A.1.2. Keep-Alive Connections 3323 In HTTP/1.0, each connection is established by the client prior to 3324 the request and closed by the server after sending the response. 3325 However, some implementations implement the explicitly negotiated 3326 ("Keep-Alive") version of persistent connections described in Section 3327 19.7.1 of [RFC2068]. 3329 Some clients and servers might wish to be compatible with these 3330 previous approaches to persistent connections, by explicitly 3331 negotiating for them with a "Connection: keep-alive" request header 3332 field. However, some experimental implementations of HTTP/1.0 3333 persistent connections are faulty; for example, if a HTTP/1.0 proxy 3334 server doesn't understand Connection, it will erroneously forward 3335 that header to the next inbound server, which would result in a hung 3336 connection. 3338 One attempted solution was the introduction of a Proxy-Connection 3339 header, targeted specifically at proxies. In practice, this was also 3340 unworkable, because proxies are often deployed in multiple layers, 3341 bringing about the same problem discussed above. 3343 As a result, clients are encouraged not to send the Proxy-Connection 3344 header in any requests. 3346 Clients are also encouraged to consider the use of Connection: keep- 3347 alive in requests carefully; while they can enable persistent 3348 connections with HTTP/1.0 servers, clients using them need will need 3349 to monitor the connection for "hung" requests (which indicate that 3350 the client ought stop sending the header), and this mechanism ought 3351 not be used by clients at all when a proxy is being used. 3353 A.2. Changes from RFC 2616 3355 Empty list elements in list productions have been deprecated. 3356 (Section 1.2.1) 3358 Rules about implicit linear whitespace between certain grammar 3359 productions have been removed; now it's only allowed when 3360 specifically pointed out in the ABNF. (Section 1.2.2) 3362 Clarify that the string "HTTP" in the HTTP-Version ABFN production is 3363 case sensitive. Restrict the version numbers to be single digits due 3364 to the fact that implementations are known to handle multi-digit 3365 version numbers incorrectly. (Section 2.6) 3366 Require that invalid whitespace around field-names be rejected. 3367 (Section 3.2) 3369 The NUL octet is no longer allowed in comment and quoted-string text. 3370 The quoted-pair rule no longer allows escaping control characters 3371 other than HTAB. Non-ASCII content in header fields and reason 3372 phrase has been obsoleted and made opaque (the TEXT rule was 3373 removed). (Section 3.2.3) 3375 Require recipients to handle bogus Content-Length header fields as 3376 errors. (Section 3.3) 3378 Remove reference to non-existent identity transfer-coding value 3379 tokens. (Sections 3.3 and 5.1) 3381 Update use of abs_path production from RFC 1808 to the path-absolute 3382 + query components of RFC 3986. State that the asterisk form is 3383 allowed for the OPTIONS request method only. (Section 3.1.1.2) 3385 Clarification that the chunk length does not include the count of the 3386 octets in the chunk header and trailer. Furthermore disallowed line 3387 folding in chunk extensions. (Section 5.1.1) 3389 Remove hard limit of two connections per server. Remove requirement 3390 to retry a sequence of requests as long it was idempotent. Remove 3391 requirements about when servers are allowed to close connections 3392 prematurely. (Section 6.1.4) 3394 Remove requirement to retry requests under certain cirumstances when 3395 the server prematurely closes the connection. (Section 6.2) 3397 Change ABNF productions for header fields to only define the field 3398 value. (Section 8) 3400 Clarify exactly when close connection options must be sent. 3401 (Section 8.1) 3403 Define the semantics of the "Upgrade" header field in responses other 3404 than 101 (this was incorporated from [RFC2817]). (Section 8.7) 3406 Appendix B. Collected ABNF 3408 BWS = OWS 3410 Chunked-Body = *chunk last-chunk trailer-part CRLF 3411 Connection = *( "," OWS ) connection-token *( OWS "," [ OWS 3412 connection-token ] ) 3413 Content-Length = 1*DIGIT 3414 HTTP-Prot-Name = %x48.54.54.50 ; HTTP 3415 HTTP-Version = HTTP-Prot-Name "/" DIGIT "." DIGIT 3416 HTTP-message = start-line *( header-field CRLF ) CRLF [ message-body 3417 ] 3418 Host = uri-host [ ":" port ] 3420 Method = token 3422 OWS = *( SP / HTAB / obs-fold ) 3424 RWS = 1*( SP / HTAB / obs-fold ) 3425 Reason-Phrase = *( HTAB / SP / VCHAR / obs-text ) 3426 Request-Line = Method SP request-target SP HTTP-Version CRLF 3428 Status-Code = 3DIGIT 3429 Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF 3431 TE = [ ( "," / t-codings ) *( OWS "," [ OWS t-codings ] ) ] 3432 Trailer = *( "," OWS ) field-name *( OWS "," [ OWS field-name ] ) 3433 Transfer-Encoding = *( "," OWS ) transfer-coding *( OWS "," [ OWS 3434 transfer-coding ] ) 3436 URI-reference = 3437 Upgrade = *( "," OWS ) product *( OWS "," [ OWS product ] ) 3439 Via = *( "," OWS ) received-protocol RWS received-by [ RWS comment ] 3440 *( OWS "," [ OWS received-protocol RWS received-by [ RWS comment ] ] 3441 ) 3443 absolute-URI = 3444 attribute = token 3445 authority = 3447 chunk = chunk-size [ chunk-ext ] CRLF chunk-data CRLF 3448 chunk-data = 1*OCTET 3449 chunk-ext = *( ";" chunk-ext-name [ "=" chunk-ext-val ] ) 3450 chunk-ext-name = token 3451 chunk-ext-val = token / quoted-str-nf 3452 chunk-size = 1*HEXDIG 3453 comment = "(" *( ctext / quoted-cpair / comment ) ")" 3454 connection-token = token 3455 ctext = OWS / %x21-27 ; '!'-''' 3456 / %x2A-5B ; '*'-'[' 3457 / %x5D-7E ; ']'-'~' 3458 / obs-text 3460 field-content = *( HTAB / SP / VCHAR / obs-text ) 3461 field-name = token 3462 field-value = *( field-content / obs-fold ) 3464 header-field = field-name ":" OWS field-value BWS 3465 http-URI = "http://" authority path-abempty [ "?" query ] 3466 https-URI = "https://" authority path-abempty [ "?" query ] 3468 last-chunk = 1*"0" [ chunk-ext ] CRLF 3470 message-body = *OCTET 3472 obs-fold = CRLF ( SP / HTAB ) 3473 obs-text = %x80-FF 3475 partial-URI = relative-part [ "?" query ] 3476 path-abempty = 3477 path-absolute = 3478 port = 3479 product = token [ "/" product-version ] 3480 product-version = token 3481 protocol-name = token 3482 protocol-version = token 3483 pseudonym = token 3485 qdtext = OWS / "!" / %x23-5B ; '#'-'[' 3486 / %x5D-7E ; ']'-'~' 3487 / obs-text 3488 qdtext-nf = HTAB / SP / "!" / %x23-5B ; '#'-'[' 3489 / %x5D-7E ; ']'-'~' 3490 / obs-text 3491 query = 3492 quoted-cpair = "\" ( HTAB / SP / VCHAR / obs-text ) 3493 quoted-pair = "\" ( HTAB / SP / VCHAR / obs-text ) 3494 quoted-str-nf = DQUOTE *( qdtext-nf / quoted-pair ) DQUOTE 3495 quoted-string = DQUOTE *( qdtext / quoted-pair ) DQUOTE 3496 qvalue = ( "0" [ "." *3DIGIT ] ) / ( "1" [ "." *3"0" ] ) 3498 received-by = ( uri-host [ ":" port ] ) / pseudonym 3499 received-protocol = [ protocol-name "/" ] protocol-version 3500 relative-part = 3501 request-target = "*" / absolute-URI / ( path-absolute [ "?" query ] ) 3502 / authority 3504 special = "(" / ")" / "<" / ">" / "@" / "," / ";" / ":" / "\" / 3505 DQUOTE / "/" / "[" / "]" / "?" / "=" / "{" / "}" 3506 start-line = Request-Line / Status-Line 3508 t-codings = "trailers" / ( transfer-extension [ te-params ] ) 3509 tchar = "!" / "#" / "$" / "%" / "&" / "'" / "*" / "+" / "-" / "." / 3510 "^" / "_" / "`" / "|" / "~" / DIGIT / ALPHA 3511 te-ext = OWS ";" OWS token [ "=" word ] 3512 te-params = OWS ";" OWS "q=" qvalue *te-ext 3513 token = 1*tchar 3514 trailer-part = *( header-field CRLF ) 3515 transfer-coding = "chunked" / "compress" / "deflate" / "gzip" / 3516 transfer-extension 3517 transfer-extension = token *( OWS ";" OWS transfer-parameter ) 3518 transfer-parameter = attribute BWS "=" BWS value 3520 uri-host = 3522 value = word 3524 word = token / quoted-string 3526 ABNF diagnostics: 3528 ; Chunked-Body defined but not used 3529 ; Connection defined but not used 3530 ; Content-Length defined but not used 3531 ; HTTP-message defined but not used 3532 ; Host defined but not used 3533 ; TE defined but not used 3534 ; Trailer defined but not used 3535 ; Transfer-Encoding defined but not used 3536 ; URI-reference defined but not used 3537 ; Upgrade defined but not used 3538 ; Via defined but not used 3539 ; http-URI defined but not used 3540 ; https-URI defined but not used 3541 ; partial-URI defined but not used 3542 ; special defined but not used 3544 Appendix C. Change Log (to be removed by RFC Editor before publication) 3546 C.1. Since RFC 2616 3548 Extracted relevant partitions from [RFC2616]. 3550 C.2. Since draft-ietf-httpbis-p1-messaging-00 3552 Closed issues: 3554 o : "HTTP Version 3555 should be case sensitive" 3556 () 3558 o : "'unsafe' 3559 characters" () 3561 o : "Chunk Size 3562 Definition" () 3564 o : "Message Length" 3565 () 3567 o : "Media Type 3568 Registrations" () 3570 o : "URI includes 3571 query" () 3573 o : "No close on 3574 1xx responses" () 3576 o : "Remove 3577 'identity' token references" 3578 () 3580 o : "Import query 3581 BNF" 3583 o : "qdtext BNF" 3585 o : "Normative and 3586 Informative references" 3588 o : "RFC2606 3589 Compliance" 3591 o : "RFC977 3592 reference" 3594 o : "RFC1700 3595 references" 3597 o : "inconsistency 3598 in date format explanation" 3600 o : "Date reference 3601 typo" 3603 o : "Informative 3604 references" 3606 o : "ISO-8859-1 3607 Reference" 3609 o : "Normative up- 3610 to-date references" 3612 Other changes: 3614 o Update media type registrations to use RFC4288 template. 3616 o Use names of RFC4234 core rules DQUOTE and HTAB, fix broken ABNF 3617 for chunk-data (work in progress on 3618 ) 3620 C.3. Since draft-ietf-httpbis-p1-messaging-01 3622 Closed issues: 3624 o : "Bodies on GET 3625 (and other) requests" 3627 o : "Updating to 3628 RFC4288" 3630 o : "Status Code 3631 and Reason Phrase" 3633 o : "rel_path not 3634 used" 3636 Ongoing work on ABNF conversion 3637 (): 3639 o Get rid of duplicate BNF rule names ("host" -> "uri-host", 3640 "trailer" -> "trailer-part"). 3642 o Avoid underscore character in rule names ("http_URL" -> "http- 3643 URL", "abs_path" -> "path-absolute"). 3645 o Add rules for terms imported from URI spec ("absoluteURI", 3646 "authority", "path-absolute", "port", "query", "relativeURI", 3647 "host) -- these will have to be updated when switching over to 3648 RFC3986. 3650 o Synchronize core rules with RFC5234. 3652 o Get rid of prose rules that span multiple lines. 3654 o Get rid of unused rules LOALPHA and UPALPHA. 3656 o Move "Product Tokens" section (back) into Part 1, as "token" is 3657 used in the definition of the Upgrade header field. 3659 o Add explicit references to BNF syntax and rules imported from 3660 other parts of the specification. 3662 o Rewrite prose rule "token" in terms of "tchar", rewrite prose rule 3663 "TEXT". 3665 C.4. Since draft-ietf-httpbis-p1-messaging-02 3667 Closed issues: 3669 o : "HTTP-date vs. 3670 rfc1123-date" 3672 o : "WS in quoted- 3673 pair" 3675 Ongoing work on IANA Message Header Field Registration 3676 (): 3678 o Reference RFC 3984, and update header field registrations for 3679 headers defined in this document. 3681 Ongoing work on ABNF conversion 3682 (): 3684 o Replace string literals when the string really is case-sensitive 3685 (HTTP-Version). 3687 C.5. Since draft-ietf-httpbis-p1-messaging-03 3689 Closed issues: 3691 o : "Connection 3692 closing" 3694 o : "Move 3695 registrations and registry information to IANA Considerations" 3697 o : "need new URL 3698 for PAD1995 reference" 3700 o : "IANA 3701 Considerations: update HTTP URI scheme registration" 3703 o : "Cite HTTPS 3704 URI scheme definition" 3706 o : "List-type 3707 headers vs Set-Cookie" 3709 Ongoing work on ABNF conversion 3710 (): 3712 o Replace string literals when the string really is case-sensitive 3713 (HTTP-Date). 3715 o Replace HEX by HEXDIG for future consistence with RFC 5234's core 3716 rules. 3718 C.6. Since draft-ietf-httpbis-p1-messaging-04 3720 Closed issues: 3722 o : "Out-of-date 3723 reference for URIs" 3725 o : "RFC 2822 is 3726 updated by RFC 5322" 3728 Ongoing work on ABNF conversion 3729 (): 3731 o Use "/" instead of "|" for alternatives. 3733 o Get rid of RFC822 dependency; use RFC5234 plus extensions instead. 3735 o Only reference RFC 5234's core rules. 3737 o Introduce new ABNF rules for "bad" whitespace ("BWS"), optional 3738 whitespace ("OWS") and required whitespace ("RWS"). 3740 o Rewrite ABNFs to spell out whitespace rules, factor out header 3741 field value format definitions. 3743 C.7. Since draft-ietf-httpbis-p1-messaging-05 3745 Closed issues: 3747 o : "Header LWS" 3749 o : "Sort 1.3 3750 Terminology" 3752 o : "RFC2047 3753 encoded words" 3755 o : "Character 3756 Encodings in TEXT" 3758 o : "Line Folding" 3760 o : "OPTIONS * and 3761 proxies" 3763 o : "Reason-Phrase 3764 BNF" 3766 o : "Use of TEXT" 3768 o : "Join 3769 "Differences Between HTTP Entities and RFC 2045 Entities"?" 3771 o : "RFC822 3772 reference left in discussion of date formats" 3774 Final work on ABNF conversion 3775 (): 3777 o Rewrite definition of list rules, deprecate empty list elements. 3779 o Add appendix containing collected and expanded ABNF. 3781 Other changes: 3783 o Rewrite introduction; add mostly new Architecture Section. 3785 o Move definition of quality values from Part 3 into Part 1; make TE 3786 request header field grammar independent of accept-params (defined 3787 in Part 3). 3789 C.8. Since draft-ietf-httpbis-p1-messaging-06 3791 Closed issues: 3793 o : "base for 3794 numeric protocol elements" 3796 o : "comment ABNF" 3798 Partly resolved issues: 3800 o : "205 Bodies" 3801 (took out language that implied that there might be methods for 3802 which a request body MUST NOT be included) 3804 o : "editorial 3805 improvements around HTTP-date" 3807 C.9. Since draft-ietf-httpbis-p1-messaging-07 3809 Closed issues: 3811 o : "Repeating 3812 single-value headers" 3814 o : "increase 3815 connection limit" 3817 o : "IP addresses 3818 in URLs" 3820 o : "take over 3821 HTTP Upgrade Token Registry" 3823 o : "CR and LF in 3824 chunk extension values" 3826 o : "HTTP/0.9 3827 support" 3829 o : "pick IANA 3830 policy (RFC5226) for Transfer Coding / Content Coding" 3832 o : "move 3833 definitions of gzip/deflate/compress to part 1" 3835 o : "disallow 3836 control characters in quoted-pair" 3838 Partly resolved issues: 3840 o : "update IANA 3841 requirements wrt Transfer-Coding values" (add the IANA 3842 Considerations subsection) 3844 C.10. Since draft-ietf-httpbis-p1-messaging-08 3846 Closed issues: 3848 o : "header 3849 parsing, treatment of leading and trailing OWS" 3851 Partly resolved issues: 3853 o : "Placement of 3854 13.5.1 and 13.5.2" 3856 o : "use of term 3857 "word" when talking about header structure" 3859 C.11. Since draft-ietf-httpbis-p1-messaging-09 3861 Closed issues: 3863 o : "Clarification 3864 of the term 'deflate'" 3866 o : "OPTIONS * and 3867 proxies" 3869 o : "MIME-Version 3870 not listed in P1, general header fields" 3872 o : "IANA registry 3873 for content/transfer encodings" 3875 o : "Case- 3876 sensitivity of HTTP-date" 3878 o : "use of term 3879 "word" when talking about header structure" 3881 Partly resolved issues: 3883 o : "Term for the 3884 requested resource's URI" 3886 C.12. Since draft-ietf-httpbis-p1-messaging-10 3888 Closed issues: 3890 o : "Connection 3891 Closing" 3893 o : "Delimiting 3894 messages with multipart/byteranges" 3896 o : "Handling 3897 multiple Content-Length headers" 3899 o : "Clarify 3900 entity / representation / variant terminology" 3902 o : "consider 3903 removing the 'changes from 2068' sections" 3905 Partly resolved issues: 3907 o : "HTTP(s) URI 3908 scheme definitions" 3910 C.13. Since draft-ietf-httpbis-p1-messaging-11 3912 Closed issues: 3914 o : "Trailer 3915 requirements" 3917 o : "Text about 3918 clock requirement for caches belongs in p6" 3920 o : "effective 3921 request URI: handling of missing host in HTTP/1.0" 3923 o : "confusing 3924 Date requirements for clients" 3926 Partly resolved issues: 3928 o : "Handling 3929 multiple Content-Length headers" 3931 C.14. Since draft-ietf-httpbis-p1-messaging-12 3933 Closed issues: 3935 o : "RFC2145 3936 Normative" 3938 o : "HTTP(s) URI 3939 scheme definitions" (tune the requirements on userinfo) 3941 o : "define 3942 'transparent' proxy" 3944 o : "Header 3945 Classification" 3947 o : "Is * usable 3948 as a request-uri for new methods?" 3950 o : "Migrate 3951 Upgrade details from RFC2817" 3953 o : "untangle 3954 ABNFs for header fields" 3956 o : "update RFC 3957 2109 reference" 3959 C.15. Since draft-ietf-httpbis-p1-messaging-13 3961 Closed issues: 3963 o : "Allow is not 3964 in 13.5.2" 3966 o : "Handling 3967 multiple Content-Length headers" 3969 o : "untangle 3970 ABNFs for header fields" 3972 o : "Content- 3973 Length ABNF broken" 3975 C.16. Since draft-ietf-httpbis-p1-messaging-14 3977 Closed issues: 3979 o : "HTTP-Version 3980 should be redefined as fixed length pair of DIGIT . DIGIT" 3982 o : "Recommend 3983 minimum sizes for protocol elements" 3985 o : "Set 3986 expectations around buffering" 3988 o : "Considering 3989 messages in isolation" 3991 C.17. Since draft-ietf-httpbis-p1-messaging-15 3993 Closed issues: 3995 o : "DNS Spoofing 3996 / DNS Binding advice" 3998 o : "move RFCs 3999 2145, 2616, 2817 to Historic status" 4001 o : "\-escaping in 4002 quoted strings" 4004 o : "'Close' 4005 should be reserved in the HTTP header field registry" 4007 C.18. Since draft-ietf-httpbis-p1-messaging-16 4009 Closed issues: 4011 o : "Document 4012 HTTP's error-handling philosophy" 4014 o : "Explain 4015 header registration" 4017 o : "Revise 4018 Acknowledgements Sections" 4020 o : "Retrying 4021 Requests" 4023 o : "Closing the 4024 connection on server error" 4026 C.19. Since draft-ietf-httpbis-p1-messaging-17 4028 Closed issues: 4030 o : "Clarify 'User 4031 Agent'" 4033 o : "Define non- 4034 final responses" 4036 o : "intended 4037 maturity level vs normative references" 4039 o : "Intermediary 4040 rewriting of queries" 4042 o : "Proxy- 4043 Connection and Keep-Alive" 4045 Index 4047 A 4048 absolute-URI form (of request-target) 32 4049 accelerator 13 4050 application/http Media Type 61 4051 asterisk form (of request-target) 31 4052 authority form (of request-target) 32 4054 B 4055 browser 10 4057 C 4058 cache 14 4059 cacheable 15 4060 captive portal 14 4061 chunked (Coding Format) 36 4062 client 10 4063 Coding Format 4064 chunked 36 4065 compress 38 4066 deflate 38 4067 gzip 39 4068 compress (Coding Format) 38 4069 connection 10 4070 Connection header field 49 4071 Content-Length header field 51 4073 D 4074 deflate (Coding Format) 38 4075 downstream 13 4077 E 4078 effective request URI 34 4080 G 4081 gateway 13 4082 Grammar 4083 absolute-URI 18 4084 ALPHA 7 4085 attribute 35 4086 authority 18 4087 BWS 9 4088 chunk 36 4089 chunk-data 36 4090 chunk-ext 36 4091 chunk-ext-name 36 4092 chunk-ext-val 36 4093 chunk-size 36 4094 Chunked-Body 36 4095 comment 26 4096 Connection 50 4097 connection-token 50 4098 Content-Length 51 4099 CR 7 4100 CRLF 7 4101 ctext 26 4102 CTL 7 4103 date2 35 4104 date3 35 4105 DIGIT 7 4106 DQUOTE 7 4107 field-content 23 4108 field-name 23 4109 field-value 23 4110 header-field 23 4111 HEXDIG 7 4112 Host 52 4113 HTAB 7 4114 HTTP-message 21 4115 HTTP-Prot-Name 15 4116 http-URI 18 4117 HTTP-Version 15 4118 https-URI 20 4119 last-chunk 36 4120 LF 7 4121 message-body 27 4122 Method 22 4123 obs-text 26 4124 OCTET 7 4125 OWS 9 4126 path-absolute 18 4127 port 18 4128 product 39 4129 product-version 39 4130 protocol-name 57 4131 protocol-version 57 4132 pseudonym 57 4133 qdtext 26 4134 qdtext-nf 36 4135 query 18 4136 quoted-cpair 27 4137 quoted-pair 26 4138 quoted-str-nf 36 4139 quoted-string 26 4140 qvalue 40 4141 Reason-Phrase 23 4142 received-by 57 4143 received-protocol 57 4144 Request-Line 22 4145 request-target 22 4146 RWS 9 4147 SP 7 4148 special 26 4149 start-line 21 4150 Status-Code 23 4151 Status-Line 23 4152 t-codings 53 4153 tchar 26 4154 TE 53 4155 te-ext 53 4156 te-params 53 4157 token 26 4158 Trailer 54 4159 trailer-part 36 4160 transfer-coding 35 4161 Transfer-Encoding 54 4162 transfer-extension 35 4163 transfer-parameter 35 4164 Upgrade 55 4165 uri-host 18 4166 URI-reference 18 4167 value 35 4168 VCHAR 7 4169 Via 57 4170 word 26 4171 gzip (Coding Format) 39 4173 H 4174 header field 21 4175 Header Fields 4176 Connection 49 4177 Content-Length 51 4178 Host 51 4179 TE 53 4180 Trailer 54 4181 Transfer-Encoding 54 4182 Upgrade 55 4183 Via 57 4184 header section 21 4185 headers 21 4186 Host header field 51 4187 http URI scheme 18 4188 https URI scheme 19 4190 I 4191 inbound 13 4192 interception proxy 14 4193 intermediary 12 4195 M 4196 Media Type 4197 application/http 61 4198 message/http 59 4199 message 10 4200 message/http Media Type 59 4202 N 4203 non-transforming proxy 13 4205 O 4206 origin form (of request-target) 32 4207 origin server 10 4208 outbound 13 4210 P 4211 proxy 13 4213 R 4214 recipient 10 4215 request 10 4216 resource 17 4217 response 10 4218 reverse proxy 13 4220 S 4221 sender 10 4222 server 10 4223 spider 10 4225 T 4226 target resource 34 4227 TE header field 53 4228 Trailer header field 54 4229 Transfer-Encoding header field 54 4230 transforming proxy 13 4231 transparent proxy 14 4232 tunnel 14 4234 U 4235 Upgrade header field 55 4236 upstream 13 4237 URI scheme 4238 http 18 4239 https 19 4240 user agent 10 4242 V 4243 Via header field 57 4245 Authors' Addresses 4247 Roy T. Fielding (editor) 4248 Adobe Systems Incorporated 4249 345 Park Ave 4250 San Jose, CA 95110 4251 USA 4253 EMail: fielding@gbiv.com 4254 URI: http://roy.gbiv.com/ 4256 Jim Gettys 4257 Alcatel-Lucent Bell Labs 4258 21 Oak Knoll Road 4259 Carlisle, MA 01741 4260 USA 4262 EMail: jg@freedesktop.org 4263 URI: http://gettys.wordpress.com/ 4265 Jeffrey C. Mogul 4266 Hewlett-Packard Company 4267 HP Labs, Large Scale Systems Group 4268 1501 Page Mill Road, MS 1177 4269 Palo Alto, CA 94304 4270 USA 4272 EMail: JeffMogul@acm.org 4273 Henrik Frystyk Nielsen 4274 Microsoft Corporation 4275 1 Microsoft Way 4276 Redmond, WA 98052 4277 USA 4279 EMail: henrikn@microsoft.com 4281 Larry Masinter 4282 Adobe Systems Incorporated 4283 345 Park Ave 4284 San Jose, CA 95110 4285 USA 4287 EMail: LMM@acm.org 4288 URI: http://larry.masinter.net/ 4290 Paul J. Leach 4291 Microsoft Corporation 4292 1 Microsoft Way 4293 Redmond, WA 98052 4295 EMail: paulle@microsoft.com 4297 Tim Berners-Lee 4298 World Wide Web Consortium 4299 MIT Computer Science and Artificial Intelligence Laboratory 4300 The Stata Center, Building 32 4301 32 Vassar Street 4302 Cambridge, MA 02139 4303 USA 4305 EMail: timbl@w3.org 4306 URI: http://www.w3.org/People/Berners-Lee/ 4307 Yves Lafon (editor) 4308 World Wide Web Consortium 4309 W3C / ERCIM 4310 2004, rte des Lucioles 4311 Sophia-Antipolis, AM 06902 4312 France 4314 EMail: ylafon@w3.org 4315 URI: http://www.raubacapeu.net/people/yves/ 4317 Julian F. Reschke (editor) 4318 greenbytes GmbH 4319 Hafenweg 16 4320 Muenster, NW 48155 4321 Germany 4323 Phone: +49 251 2807760 4324 Fax: +49 251 2807761 4325 EMail: julian.reschke@greenbytes.de 4326 URI: http://greenbytes.de/tech/webdav/