idnits 2.17.1 draft-ietf-httpbis-p1-messaging-17.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 (October 31, 2011) is 4559 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'BCP97' is defined on line 3168, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO-8859-1' == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p2-semantics-17 == Outdated reference: A later version (-20) exists of draft-ietf-httpbis-p3-payload-17 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p6-cache-17 ** Downref: Normative reference to an Informational RFC: RFC 1950 ** Downref: Normative reference to an Informational RFC: RFC 1951 ** Downref: Normative reference to an Informational RFC: RFC 1952 -- Possible downref: Non-RFC (?) normative reference: ref. 'USASCII' -- Obsolete informational reference (is this intentional?): RFC 2068 (Obsoleted by RFC 2616) -- Obsolete informational reference (is this intentional?): RFC 2145 (Obsoleted by RFC 7230) -- Obsolete informational reference (is this intentional?): RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) -- Obsolete informational reference (is this intentional?): RFC 2818 (Obsoleted by RFC 9110) -- Obsolete informational reference (is this intentional?): RFC 2965 (Obsoleted by RFC 6265) -- Obsolete informational reference (is this intentional?): RFC 4288 (Obsoleted by RFC 6838) -- Obsolete informational reference (is this intentional?): RFC 4395 (Obsoleted by RFC 7595) -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 3 errors (**), 0 flaws (~~), 5 warnings (==), 15 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 HTTPbis Working Group R. Fielding, Ed. 3 Internet-Draft Adobe 4 Obsoletes: 2145,2616 (if approved) J. Gettys 5 Updates: 2817 (if approved) Alcatel-Lucent 6 Intended status: Standards Track J. Mogul 7 Expires: May 3, 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 October 31, 2011 22 HTTP/1.1, part 1: URIs, Connections, and Message Parsing 23 draft-ietf-httpbis-p1-messaging-17 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.18. 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 May 3, 2012. 75 Copyright Notice 77 Copyright (c) 2011 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 . . . . . . . . . . . . . . . . . . . . . . . . 20 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 . . . . . . . . . . . . . . . . . . . . 24 126 3.2.2. Field Length . . . . . . . . . . . . . . . . . . . . . 25 127 3.2.3. Common Field ABNF Rules . . . . . . . . . . . . . . . 25 128 3.3. Message Body . . . . . . . . . . . . . . . . . . . . . . . 27 129 3.4. Handling Incomplete Messages . . . . . . . . . . . . . . . 30 130 3.5. Message Parsing Robustness . . . . . . . . . . . . . . . . 30 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 . . . . . . . . . . . . . . . . . . 68 189 Appendix A. HTTP Version History . . . . . . . . . . . . . . . . 70 190 A.1. Changes from HTTP/1.0 . . . . . . . . . . . . . . . . . . 71 191 A.1.1. Multi-homed Web Servers . . . . . . . . . . . . . . . 71 192 A.1.2. Keep-Alive Connections . . . . . . . . . . . . . . . . 71 194 A.2. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 72 195 Appendix B. Collected ABNF . . . . . . . . . . . . . . . . . . . 73 196 Appendix C. Change Log (to be removed by RFC Editor before 197 publication) . . . . . . . . . . . . . . . . . . . . 76 198 C.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 76 199 C.2. Since draft-ietf-httpbis-p1-messaging-00 . . . . . . . . . 76 200 C.3. Since draft-ietf-httpbis-p1-messaging-01 . . . . . . . . . 78 201 C.4. Since draft-ietf-httpbis-p1-messaging-02 . . . . . . . . . 79 202 C.5. Since draft-ietf-httpbis-p1-messaging-03 . . . . . . . . . 79 203 C.6. Since draft-ietf-httpbis-p1-messaging-04 . . . . . . . . . 80 204 C.7. Since draft-ietf-httpbis-p1-messaging-05 . . . . . . . . . 80 205 C.8. Since draft-ietf-httpbis-p1-messaging-06 . . . . . . . . . 81 206 C.9. Since draft-ietf-httpbis-p1-messaging-07 . . . . . . . . . 82 207 C.10. Since draft-ietf-httpbis-p1-messaging-08 . . . . . . . . . 82 208 C.11. Since draft-ietf-httpbis-p1-messaging-09 . . . . . . . . . 83 209 C.12. Since draft-ietf-httpbis-p1-messaging-10 . . . . . . . . . 83 210 C.13. Since draft-ietf-httpbis-p1-messaging-11 . . . . . . . . . 84 211 C.14. Since draft-ietf-httpbis-p1-messaging-12 . . . . . . . . . 84 212 C.15. Since draft-ietf-httpbis-p1-messaging-13 . . . . . . . . . 85 213 C.16. Since draft-ietf-httpbis-p1-messaging-14 . . . . . . . . . 85 214 C.17. Since draft-ietf-httpbis-p1-messaging-15 . . . . . . . . . 85 215 C.18. Since draft-ietf-httpbis-p1-messaging-16 . . . . . . . . . 86 216 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 218 1. Introduction 220 The Hypertext Transfer Protocol (HTTP) is an application-level 221 request/response protocol that uses extensible semantics and MIME- 222 like message payloads for flexible interaction with network-based 223 hypertext information systems. HTTP relies upon the Uniform Resource 224 Identifier (URI) standard [RFC3986] to indicate the target resource 225 and relationships between resources. Messages are passed in a format 226 similar to that used by Internet mail [RFC5322] and the Multipurpose 227 Internet Mail Extensions (MIME) [RFC2045] (see Appendix A of [Part3] 228 for the differences between HTTP and MIME messages). 230 HTTP is a generic interface protocol for information systems. It is 231 designed to hide the details of how a service is implemented by 232 presenting a uniform interface to clients that is independent of the 233 types of resources provided. Likewise, servers do not need to be 234 aware of each client's purpose: an HTTP request can be considered in 235 isolation rather than being associated with a specific type of client 236 or a predetermined sequence of application steps. The result is a 237 protocol that can be used effectively in many different contexts and 238 for which implementations can evolve independently over time. 240 HTTP is also designed for use as an intermediation protocol for 241 translating communication to and from non-HTTP information systems. 242 HTTP proxies and gateways can provide access to alternative 243 information services by translating their diverse protocols into a 244 hypertext format that can be viewed and manipulated by clients in the 245 same way as HTTP services. 247 One consequence of HTTP flexibility is that the protocol cannot be 248 defined in terms of what occurs behind the interface. Instead, we 249 are limited to defining the syntax of communication, the intent of 250 received communication, and the expected behavior of recipients. If 251 the communication is considered in isolation, then successful actions 252 ought to be reflected in corresponding changes to the observable 253 interface provided by servers. However, since multiple clients might 254 act in parallel and perhaps at cross-purposes, we cannot require that 255 such changes be observable beyond the scope of a single response. 257 This document is Part 1 of the seven-part specification of HTTP, 258 defining the protocol referred to as "HTTP/1.1", obsoleting [RFC2616] 259 and [RFC2145]. Part 1 describes the architectural elements that are 260 used or referred to in HTTP, defines the "http" and "https" URI 261 schemes, describes overall network operation and connection 262 management, and defines HTTP message framing and forwarding 263 requirements. Our goal is to define all of the mechanisms necessary 264 for HTTP message handling that are independent of message semantics, 265 thereby defining the complete set of requirements for message parsers 266 and message-forwarding intermediaries. 268 1.1. Conformance and Error Handling 270 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 271 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 272 document are to be interpreted as described in [RFC2119]. 274 This document defines conformance criteria for several roles in HTTP 275 communication, including Senders, Recipients, Clients, Servers, User- 276 Agents, Origin Servers, Intermediaries, Proxies and Gateways. See 277 Section 2 for definitions of these terms. 279 An implementation is considered conformant if it complies with all of 280 the requirements associated with its role(s). Note that SHOULD-level 281 requirements are relevant here, unless one of the documented 282 exceptions is applicable. 284 This document also uses ABNF to define valid protocol elements 285 (Section 1.2). In addition to the prose requirements placed upon 286 them, Senders MUST NOT generate protocol elements that are invalid. 288 Unless noted otherwise, Recipients MAY take steps to recover a usable 289 protocol element from an invalid construct. However, HTTP does not 290 define specific error handling mechanisms, except in cases where it 291 has direct impact on security. This is because different uses of the 292 protocol require different error handling strategies; for example, a 293 Web browser may wish to transparently recover from a response where 294 the Location header field doesn't parse according to the ABNF, 295 whereby in a systems control protocol using HTTP, this type of error 296 recovery could lead to dangerous consequences. 298 1.2. Syntax Notation 300 This specification uses the Augmented Backus-Naur Form (ABNF) 301 notation of [RFC5234]. 303 The following core rules are included by reference, as defined in 304 [RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF 305 (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote), 306 HEXDIG (hexadecimal 0-9/A-F/a-f), HTAB (horizontal tab), LF (line 307 feed), OCTET (any 8-bit sequence of data), SP (space), and VCHAR (any 308 visible [USASCII] character). 310 As a syntactic convention, ABNF rule names prefixed with "obs-" 311 denote "obsolete" grammar rules that appear for historical reasons. 313 1.2.1. ABNF Extension: #rule 315 The #rule extension to the ABNF rules of [RFC5234] is used to improve 316 readability. 318 A construct "#" is defined, similar to "*", for defining comma- 319 delimited lists of elements. The full form is "#element" 320 indicating at least and at most elements, each separated by a 321 single comma (",") and optional whitespace (OWS, Section 1.2.2). 323 Thus, 325 1#element => element *( OWS "," OWS element ) 327 and: 329 #element => [ 1#element ] 331 and for n >= 1 and m > 1: 333 #element => element *( OWS "," OWS element ) 335 For compatibility with legacy list rules, recipients SHOULD accept 336 empty list elements. In other words, consumers would follow the list 337 productions: 339 #element => [ ( "," / element ) *( OWS "," [ OWS element ] ) ] 341 1#element => *( "," OWS ) element *( OWS "," [ OWS element ] ) 343 Note that empty elements do not contribute to the count of elements 344 present, though. 346 For example, given these ABNF productions: 348 example-list = 1#example-list-elmt 349 example-list-elmt = token ; see Section 3.2.3 351 Then these are valid values for example-list (not including the 352 double quotes, which are present for delimitation only): 354 "foo,bar" 355 "foo ,bar," 356 "foo , ,bar,charlie " 358 But these values would be invalid, as at least one non-empty element 359 is required: 361 "" 362 "," 363 ", ," 365 Appendix B shows the collected ABNF, with the list rules expanded as 366 explained above. 368 1.2.2. Basic Rules 370 This specification uses three rules to denote the use of linear 371 whitespace: OWS (optional whitespace), RWS (required whitespace), and 372 BWS ("bad" whitespace). 374 The OWS rule is used where zero or more linear whitespace octets 375 might appear. OWS SHOULD either not be produced or be produced as a 376 single SP. Multiple OWS octets that occur within field-content 377 SHOULD either be replaced with a single SP or transformed to all SP 378 octets (each octet other than SP replaced with SP) before 379 interpreting the field value or forwarding the message downstream. 381 RWS is used when at least one linear whitespace octet is required to 382 separate field tokens. RWS SHOULD be produced as a single SP. 383 Multiple RWS octets that occur within field-content SHOULD either be 384 replaced with a single SP or transformed to all SP octets before 385 interpreting the field value or forwarding the message downstream. 387 BWS is used where the grammar allows optional whitespace for 388 historical reasons but senders SHOULD NOT produce it in messages. 389 HTTP/1.1 recipients MUST accept such bad optional whitespace and 390 remove it before interpreting the field value or forwarding the 391 message downstream. 393 OWS = *( SP / HTAB / obs-fold ) 394 ; "optional" whitespace 395 RWS = 1*( SP / HTAB / obs-fold ) 396 ; "required" whitespace 397 BWS = OWS 398 ; "bad" whitespace 399 obs-fold = CRLF ( SP / HTAB ) 400 ; obsolete line folding 401 ; see Section 3.2.1 403 2. Architecture 405 HTTP was created for the World Wide Web architecture and has evolved 406 over time to support the scalability needs of a worldwide hypertext 407 system. Much of that architecture is reflected in the terminology 408 and syntax productions used to define HTTP. 410 2.1. Client/Server Messaging 412 HTTP is a stateless request/response protocol that operates by 413 exchanging messages (Section 3) across a reliable transport or 414 session-layer "connection". An HTTP "client" is a program that 415 establishes a connection to a server for the purpose of sending one 416 or more HTTP requests. An HTTP "server" is a program that accepts 417 connections in order to service HTTP requests by sending HTTP 418 responses. 420 Note that the terms client and server refer only to the roles that 421 these programs perform for a particular connection. The same program 422 might act as a client on some connections and a server on others. We 423 use the term "user agent" to refer to the program that initiates a 424 request, such as a WWW browser, editor, or spider (web-traversing 425 robot), and the term "origin server" to refer to the program that can 426 originate authoritative responses to a request. For general 427 requirements, we use the term "sender" to refer to whichever 428 component sent a given message and the term "recipient" to refer to 429 any component that receives the message. 431 Most HTTP communication consists of a retrieval request (GET) for a 432 representation of some resource identified by a URI. In the simplest 433 case, this might be accomplished via a single bidirectional 434 connection (===) between the user agent (UA) and the origin server 435 (O). 437 request > 438 UA ======================================= O 439 < response 441 A client sends an HTTP request to the server in the form of a request 442 message, beginning with a request-line that includes a method, URI, 443 and protocol version (Section 3.1.1), followed by MIME-like header 444 fields containing request modifiers, client information, and payload 445 metadata (Section 3.2), an empty line to indicate the end of the 446 header section, and finally a message body containing the payload 447 body (if any, Section 3.3). 449 A server responds to the client's request by sending an HTTP response 450 message, beginning with a status line that includes the protocol 451 version, a success or error code, and textual reason phrase 452 (Section 3.1.2), followed by MIME-like header fields containing 453 server information, resource metadata, and payload metadata 454 (Section 3.2), an empty line to indicate the end of the header 455 section, and finally a message body containing the payload body (if 456 any, Section 3.3). 458 The following example illustrates a typical message exchange for a 459 GET request on the URI "http://www.example.com/hello.txt": 461 client request: 463 GET /hello.txt HTTP/1.1 464 User-Agent: curl/7.16.3 libcurl/7.16.3 OpenSSL/0.9.7l zlib/1.2.3 465 Host: www.example.com 466 Accept: */* 468 server response: 470 HTTP/1.1 200 OK 471 Date: Mon, 27 Jul 2009 12:28:53 GMT 472 Server: Apache 473 Last-Modified: Wed, 22 Jul 2009 19:15:56 GMT 474 ETag: "34aa387-d-1568eb00" 475 Accept-Ranges: bytes 476 Content-Length: 14 477 Vary: Accept-Encoding 478 Content-Type: text/plain 480 Hello World! 482 2.2. Message Orientation and Buffering 484 Fundamentally, HTTP is a message-based protocol. Although message 485 bodies can be chunked (Section 5.1.1) and implementations often make 486 parts of a message available progressively, this is not required, and 487 some widely-used implementations only make a message available when 488 it is complete. Furthermore, while most proxies will progressively 489 stream messages, some amount of buffering will take place, and some 490 proxies might buffer messages to perform transformations, check 491 content or provide other services. 493 Therefore, extensions to and uses of HTTP cannot rely on the 494 availability of a partial message, or assume that messages will not 495 be buffered. There are strategies that can be used to test for 496 buffering in a given connection, but it should be understood that 497 behaviors can differ across connections, and between requests and 498 responses. 500 Recipients MUST consider every message in a connection in isolation; 501 because HTTP is a stateless protocol, it cannot be assumed that two 502 requests on the same connection are from the same client or share any 503 other common attributes. In particular, intermediaries might mix 504 requests from different clients into a single server connection. 505 Note that some existing HTTP extensions (e.g., [RFC4559]) violate 506 this requirement, thereby potentially causing interoperability and 507 security problems. 509 2.3. Connections and Transport Independence 511 HTTP messaging is independent of the underlying transport or session- 512 layer connection protocol(s). HTTP only presumes a reliable 513 transport with in-order delivery of requests and the corresponding 514 in-order delivery of responses. The mapping of HTTP request and 515 response structures onto the data units of the underlying transport 516 protocol is outside the scope of this specification. 518 The specific connection protocols to be used for an interaction are 519 determined by client configuration and the target resource's URI. 520 For example, the "http" URI scheme (Section 2.7.1) indicates a 521 default connection of TCP over IP, with a default TCP port of 80, but 522 the client might be configured to use a proxy via some other 523 connection port or protocol instead of using the defaults. 525 A connection might be used for multiple HTTP request/response 526 exchanges, as defined in Section 6.1. 528 2.4. Intermediaries 530 HTTP enables the use of intermediaries to satisfy requests through a 531 chain of connections. There are three common forms of HTTP 532 intermediary: proxy, gateway, and tunnel. In some cases, a single 533 intermediary might act as an origin server, proxy, gateway, or 534 tunnel, switching behavior based on the nature of each request. 536 > > > > 537 UA =========== A =========== B =========== C =========== O 538 < < < < 540 The figure above shows three intermediaries (A, B, and C) between the 541 user agent and origin server. A request or response message that 542 travels the whole chain will pass through four separate connections. 543 Some HTTP communication options might apply only to the connection 544 with the nearest, non-tunnel neighbor, only to the end-points of the 545 chain, or to all connections along the chain. Although the diagram 546 is linear, each participant might be engaged in multiple, 547 simultaneous communications. For example, B might be receiving 548 requests from many clients other than A, and/or forwarding requests 549 to servers other than C, at the same time that it is handling A's 550 request. 552 We use the terms "upstream" and "downstream" to describe various 553 requirements in relation to the directional flow of a message: all 554 messages flow from upstream to downstream. Likewise, we use the 555 terms inbound and outbound to refer to directions in relation to the 556 request path: "inbound" means toward the origin server and "outbound" 557 means toward the user agent. 559 A "proxy" is a message forwarding agent that is selected by the 560 client, usually via local configuration rules, to receive requests 561 for some type(s) of absolute URI and attempt to satisfy those 562 requests via translation through the HTTP interface. Some 563 translations are minimal, such as for proxy requests for "http" URIs, 564 whereas other requests might require translation to and from entirely 565 different application-layer protocols. Proxies are often used to 566 group an organization's HTTP requests through a common intermediary 567 for the sake of security, annotation services, or shared caching. 569 An HTTP-to-HTTP proxy is called a "transforming proxy" if it is 570 designed or configured to modify request or response messages in a 571 semantically meaningful way (i.e., modifications, beyond those 572 required by normal HTTP processing, that change the message in a way 573 that would be significant to the original sender or potentially 574 significant to downstream recipients). For example, a transforming 575 proxy might be acting as a shared annotation server (modifying 576 responses to include references to a local annotation database), a 577 malware filter, a format transcoder, or an intranet-to-Internet 578 privacy filter. Such transformations are presumed to be desired by 579 the client (or client organization) that selected the proxy and are 580 beyond the scope of this specification. However, when a proxy is not 581 intended to transform a given message, we use the term "non- 582 transforming proxy" to target requirements that preserve HTTP message 583 semantics. See Section 7.2.4 of [Part2] and Section 3.6 of [Part6] 584 for status and warning codes related to transformations. 586 A "gateway" (a.k.a., "reverse proxy") is a receiving agent that acts 587 as a layer above some other server(s) and translates the received 588 requests to the underlying server's protocol. Gateways are often 589 used to encapsulate legacy or untrusted information services, to 590 improve server performance through "accelerator" caching, and to 591 enable partitioning or load-balancing of HTTP services across 592 multiple machines. 594 A gateway behaves as an origin server on its outbound connection and 595 as a user agent on its inbound connection. All HTTP requirements 596 applicable to an origin server also apply to the outbound 597 communication of a gateway. A gateway communicates with inbound 598 servers using any protocol that it desires, including private 599 extensions to HTTP that are outside the scope of this specification. 601 However, an HTTP-to-HTTP gateway that wishes to interoperate with 602 third-party HTTP servers MUST comply with HTTP user agent 603 requirements on the gateway's inbound connection and MUST implement 604 the Connection (Section 8.1) and Via (Section 8.8) header fields for 605 both connections. 607 A "tunnel" acts as a blind relay between two connections without 608 changing the messages. Once active, a tunnel is not considered a 609 party to the HTTP communication, though the tunnel might have been 610 initiated by an HTTP request. A tunnel ceases to exist when both 611 ends of the relayed connection are closed. Tunnels are used to 612 extend a virtual connection through an intermediary, such as when 613 transport-layer security is used to establish private communication 614 through a shared firewall proxy. 616 In addition, there may exist network intermediaries that are not 617 considered part of the HTTP communication but nevertheless act as 618 filters or redirecting agents (usually violating HTTP semantics, 619 causing security problems, and otherwise making a mess of things). 620 Such a network intermediary, often referred to as an "interception 621 proxy" [RFC3040], "transparent proxy" [RFC1919], or "captive portal", 622 differs from an HTTP proxy because it has not been selected by the 623 client. Instead, the network intermediary redirects outgoing TCP 624 port 80 packets (and occasionally other common port traffic) to an 625 internal HTTP server. Interception proxies are commonly found on 626 public network access points, as a means of enforcing account 627 subscription prior to allowing use of non-local Internet services, 628 and within corporate firewalls to enforce network usage policies. 629 They are indistinguishable from a man-in-the-middle attack. 631 2.5. Caches 633 A "cache" is a local store of previous response messages and the 634 subsystem that controls its message storage, retrieval, and deletion. 635 A cache stores cacheable responses in order to reduce the response 636 time and network bandwidth consumption on future, equivalent 637 requests. Any client or server MAY employ a cache, though a cache 638 cannot be used by a server while it is acting as a tunnel. 640 The effect of a cache is that the request/response chain is shortened 641 if one of the participants along the chain has a cached response 642 applicable to that request. The following illustrates the resulting 643 chain if B has a cached copy of an earlier response from O (via C) 644 for a request which has not been cached by UA or A. 646 > > 647 UA =========== A =========== B - - - - - - C - - - - - - O 648 < < 650 A response is "cacheable" if a cache is allowed to store a copy of 651 the response message for use in answering subsequent requests. Even 652 when a response is cacheable, there might be additional constraints 653 placed by the client or by the origin server on when that cached 654 response can be used for a particular request. HTTP requirements for 655 cache behavior and cacheable responses are defined in Section 2 of 656 [Part6]. 658 There are a wide variety of architectures and configurations of 659 caches and proxies deployed across the World Wide Web and inside 660 large organizations. These systems include national hierarchies of 661 proxy caches to save transoceanic bandwidth, systems that broadcast 662 or multicast cache entries, organizations that distribute subsets of 663 cached data via optical media, and so on. 665 2.6. Protocol Versioning 667 HTTP uses a "." numbering scheme to indicate versions 668 of the protocol. This specification defines version "1.1". The 669 protocol version as a whole indicates the sender's compliance with 670 the set of requirements laid out in that version's corresponding 671 specification of HTTP. 673 The version of an HTTP message is indicated by an HTTP-Version field 674 in the first line of the message. HTTP-Version is case-sensitive. 676 HTTP-Version = HTTP-Prot-Name "/" DIGIT "." DIGIT 677 HTTP-Prot-Name = %x48.54.54.50 ; "HTTP", case-sensitive 679 The HTTP version number consists of two decimal digits separated by a 680 "." (period or decimal point). The first digit ("major version") 681 indicates the HTTP messaging syntax, whereas the second digit ("minor 682 version") indicates the highest minor version to which the sender is 683 at least conditionally compliant and able to understand for future 684 communication. The minor version advertises the sender's 685 communication capabilities even when the sender is only using a 686 backwards-compatible subset of the protocol, thereby letting the 687 recipient know that more advanced features can be used in response 688 (by servers) or in future requests (by clients). 690 When an HTTP/1.1 message is sent to an HTTP/1.0 recipient [RFC1945] 691 or a recipient whose version is unknown, the HTTP/1.1 message is 692 constructed such that it can be interpreted as a valid HTTP/1.0 693 message if all of the newer features are ignored. This specification 694 places recipient-version requirements on some new features so that a 695 compliant sender will only use compatible features until it has 696 determined, through configuration or the receipt of a message, that 697 the recipient supports HTTP/1.1. 699 The interpretation of an HTTP header field does not change between 700 minor versions of the same major version, though the default behavior 701 of a recipient in the absence of such a field can change. Unless 702 specified otherwise, header fields defined in HTTP/1.1 are defined 703 for all versions of HTTP/1.x. In particular, the Host and Connection 704 header fields ought to be implemented by all HTTP/1.x implementations 705 whether or not they advertise compliance with HTTP/1.1. 707 New header fields can be defined such that, when they are understood 708 by a recipient, they might override or enhance the interpretation of 709 previously defined header fields. When an implementation receives an 710 unrecognized header field, the recipient MUST ignore that header 711 field for local processing regardless of the message's HTTP version. 712 An unrecognized header field received by a proxy MUST be forwarded 713 downstream unless the header field's field-name is listed in the 714 message's Connection header-field (see Section 8.1). These 715 requirements allow HTTP's functionality to be enhanced without 716 requiring prior update of all compliant intermediaries. 718 Intermediaries that process HTTP messages (i.e., all intermediaries 719 other than those acting as a tunnel) MUST send their own HTTP-Version 720 in forwarded messages. In other words, they MUST NOT blindly forward 721 the first line of an HTTP message without ensuring that the protocol 722 version matches what the intermediary understands, and is at least 723 conditionally compliant to, for both the receiving and sending of 724 messages. Forwarding an HTTP message without rewriting the HTTP- 725 Version might result in communication errors when downstream 726 recipients use the message sender's version to determine what 727 features are safe to use for later communication with that sender. 729 An HTTP client SHOULD send a request version equal to the highest 730 version for which the client is at least conditionally compliant and 731 whose major version is no higher than the highest version supported 732 by the server, if this is known. An HTTP client MUST NOT send a 733 version for which it is not at least conditionally compliant. 735 An HTTP client MAY send a lower request version if it is known that 736 the server incorrectly implements the HTTP specification, but only 737 after the client has attempted at least one normal request and 738 determined from the response status or header fields (e.g., Server) 739 that the server improperly handles higher request versions. 741 An HTTP server SHOULD send a response version equal to the highest 742 version for which the server is at least conditionally compliant and 743 whose major version is less than or equal to the one received in the 744 request. An HTTP server MUST NOT send a version for which it is not 745 at least conditionally compliant. A server MAY send a 505 (HTTP 746 Version Not Supported) response if it cannot send a response using 747 the major version used in the client's request. 749 An HTTP server MAY send an HTTP/1.0 response to an HTTP/1.0 request 750 if it is known or suspected that the client incorrectly implements 751 the HTTP specification and is incapable of correctly processing later 752 version responses, such as when a client fails to parse the version 753 number correctly or when an intermediary is known to blindly forward 754 the HTTP-Version even when it doesn't comply with the given minor 755 version of the protocol. Such protocol downgrades SHOULD NOT be 756 performed unless triggered by specific client attributes, such as 757 when one or more of the request header fields (e.g., User-Agent) 758 uniquely match the values sent by a client known to be in error. 760 The intention of HTTP's versioning design is that the major number 761 will only be incremented if an incompatible message syntax is 762 introduced, and that the minor number will only be incremented when 763 changes made to the protocol have the effect of adding to the message 764 semantics or implying additional capabilities of the sender. 765 However, the minor version was not incremented for the changes 766 introduced between [RFC2068] and [RFC2616], and this revision is 767 specifically avoiding any such changes to the protocol. 769 2.7. Uniform Resource Identifiers 771 Uniform Resource Identifiers (URIs) [RFC3986] are used throughout 772 HTTP as the means for identifying resources. URI references are used 773 to target requests, indicate redirects, and define relationships. 774 HTTP does not limit what a resource might be; it merely defines an 775 interface that can be used to interact with a resource via HTTP. 776 More information on the scope of URIs and resources can be found in 777 [RFC3986]. 779 This specification adopts the definitions of "URI-reference", 780 "absolute-URI", "relative-part", "port", "host", "path-abempty", 781 "path-absolute", "query", and "authority" from the URI generic syntax 782 [RFC3986]. In addition, we define a partial-URI rule for protocol 783 elements that allow a relative URI but not a fragment. 785 URI-reference = 786 absolute-URI = 787 relative-part = 788 authority = 789 path-abempty = 790 path-absolute = 791 port = 792 query = 793 uri-host = 794 partial-URI = relative-part [ "?" query ] 796 Each protocol element in HTTP that allows a URI reference will 797 indicate in its ABNF production whether the element allows any form 798 of reference (URI-reference), only a URI in absolute form (absolute- 799 URI), only the path and optional query components, or some 800 combination of the above. Unless otherwise indicated, URI references 801 are parsed relative to the effective request URI, which defines the 802 default base URI for references in both the request and its 803 corresponding response. 805 2.7.1. http URI scheme 807 The "http" URI scheme is hereby defined for the purpose of minting 808 identifiers according to their association with the hierarchical 809 namespace governed by a potential HTTP origin server listening for 810 TCP connections on a given port. 812 http-URI = "http:" "//" authority path-abempty [ "?" query ] 814 The HTTP origin server is identified by the generic syntax's 815 authority component, which includes a host identifier and optional 816 TCP port ([RFC3986], Section 3.2.2). The remainder of the URI, 817 consisting of both the hierarchical path component and optional query 818 component, serves as an identifier for a potential resource within 819 that origin server's name space. 821 If the host identifier is provided as an IP literal or IPv4 address, 822 then the origin server is any listener on the indicated TCP port at 823 that IP address. If host is a registered name, then that name is 824 considered an indirect identifier and the recipient might use a name 825 resolution service, such as DNS, to find the address of a listener 826 for that host. The host MUST NOT be empty; if an "http" URI is 827 received with an empty host, then it MUST be rejected as invalid. If 828 the port subcomponent is empty or not given, then TCP port 80 is 829 assumed (the default reserved port for WWW services). 831 Regardless of the form of host identifier, access to that host is not 832 implied by the mere presence of its name or address. The host might 833 or might not exist and, even when it does exist, might or might not 834 be running an HTTP server or listening to the indicated port. The 835 "http" URI scheme makes use of the delegated nature of Internet names 836 and addresses to establish a naming authority (whatever entity has 837 the ability to place an HTTP server at that Internet name or address) 838 and allows that authority to determine which names are valid and how 839 they might be used. 841 When an "http" URI is used within a context that calls for access to 842 the indicated resource, a client MAY attempt access by resolving the 843 host to an IP address, establishing a TCP connection to that address 844 on the indicated port, and sending an HTTP request message 845 (Section 3) containing the URI's identifying data (Section 4) to the 846 server. If the server responds to that request with a non-interim 847 HTTP response message, as described in Section 4 of [Part2], then 848 that response is considered an authoritative answer to the client's 849 request. 851 Although HTTP is independent of the transport protocol, the "http" 852 scheme is specific to TCP-based services because the name delegation 853 process depends on TCP for establishing authority. An HTTP service 854 based on some other underlying connection protocol would presumably 855 be identified using a different URI scheme, just as the "https" 856 scheme (below) is used for servers that require an SSL/TLS transport 857 layer on a connection. Other protocols might also be used to provide 858 access to "http" identified resources -- it is only the authoritative 859 interface used for mapping the namespace that is specific to TCP. 861 The URI generic syntax for authority also includes a deprecated 862 userinfo subcomponent ([RFC3986], Section 3.2.1) for including user 863 authentication information in the URI. Some implementations make use 864 of the userinfo component for internal configuration of 865 authentication information, such as within command invocation 866 options, configuration files, or bookmark lists, even though such 867 usage might expose a user identifier or password. Senders MUST NOT 868 include a userinfo subcomponent (and its "@" delimiter) when 869 transmitting an "http" URI in a message. Recipients of HTTP messages 870 that contain a URI reference SHOULD parse for the existence of 871 userinfo and treat its presence as an error, likely indicating that 872 the deprecated subcomponent is being used to obscure the authority 873 for the sake of phishing attacks. 875 2.7.2. https URI scheme 877 The "https" URI scheme is hereby defined for the purpose of minting 878 identifiers according to their association with the hierarchical 879 namespace governed by a potential HTTP origin server listening for 880 SSL/TLS-secured connections on a given TCP port. 882 All of the requirements listed above for the "http" scheme are also 883 requirements for the "https" scheme, except that a default TCP port 884 of 443 is assumed if the port subcomponent is empty or not given, and 885 the TCP connection MUST be secured for privacy through the use of 886 strong encryption prior to sending the first HTTP request. 888 https-URI = "https:" "//" authority path-abempty [ "?" query ] 890 Unlike the "http" scheme, responses to "https" identified requests 891 are never "public" and thus MUST NOT be reused for shared caching. 892 They can, however, be reused in a private cache if the message is 893 cacheable by default in HTTP or specifically indicated as such by the 894 Cache-Control header field (Section 3.2 of [Part6]). 896 Resources made available via the "https" scheme have no shared 897 identity with the "http" scheme even if their resource identifiers 898 indicate the same authority (the same host listening to the same TCP 899 port). They are distinct name spaces and are considered to be 900 distinct origin servers. However, an extension to HTTP that is 901 defined to apply to entire host domains, such as the Cookie protocol 902 [RFC6265], can allow information set by one service to impact 903 communication with other services within a matching group of host 904 domains. 906 The process for authoritative access to an "https" identified 907 resource is defined in [RFC2818]. 909 2.7.3. http and https URI Normalization and Comparison 911 Since the "http" and "https" schemes conform to the URI generic 912 syntax, such URIs are normalized and compared according to the 913 algorithm defined in [RFC3986], Section 6, using the defaults 914 described above for each scheme. 916 If the port is equal to the default port for a scheme, the normal 917 form is to elide the port subcomponent. Likewise, an empty path 918 component is equivalent to an absolute path of "/", so the normal 919 form is to provide a path of "/" instead. The scheme and host are 920 case-insensitive and normally provided in lowercase; all other 921 components are compared in a case-sensitive manner. Characters other 922 than those in the "reserved" set are equivalent to their percent- 923 encoded octets (see [RFC3986], Section 2.1): the normal form is to 924 not encode them. 926 For example, the following three URIs are equivalent: 928 http://example.com:80/~smith/home.html 929 http://EXAMPLE.com/%7Esmith/home.html 930 http://EXAMPLE.com:/%7esmith/home.html 932 3. Message Format 934 All HTTP/1.1 messages consist of a start-line followed by a sequence 935 of octets in a format similar to the Internet Message Format 936 [RFC5322]: zero or more header fields (collectively referred to as 937 the "headers" or the "header section"), an empty line indicating the 938 end of the header section, and an optional message-body. 940 HTTP-message = start-line 941 *( header-field CRLF ) 942 CRLF 943 [ message-body ] 945 The normal procedure for parsing an HTTP message is to read the 946 start-line into a structure, read each header field into a hash table 947 by field name until the empty line, and then use the parsed data to 948 determine if a message-body is expected. If a message-body has been 949 indicated, then it is read as a stream until an amount of octets 950 equal to the message-body length is read or the connection is closed. 952 Recipients MUST parse an HTTP message as a sequence of octets in an 953 encoding that is a superset of US-ASCII [USASCII]. Parsing an HTTP 954 message as a stream of Unicode characters, without regard for the 955 specific encoding, creates security vulnerabilities due to the 956 varying ways that string processing libraries handle invalid 957 multibyte character sequences that contain the octet LF (%x0A). 958 String-based parsers can only be safely used within protocol elements 959 after the element has been extracted from the message, such as within 960 a header field-value after message parsing has delineated the 961 individual fields. 963 3.1. Start Line 965 An HTTP message can either be a request from client to server or a 966 response from server to client. Syntactically, the two types of 967 message differ only in the start-line, which is either a Request-Line 968 (for requests) or a Status-Line (for responses), and in the algorithm 969 for determining the length of the message-body (Section 3.3). In 970 theory, a client could receive requests and a server could receive 971 responses, distinguishing them by their different start-line formats, 972 but in practice servers are implemented to only expect a request (a 973 response is interpreted as an unknown or invalid request method) and 974 clients are implemented to only expect a response. 976 start-line = Request-Line / Status-Line 978 Implementations MUST NOT send whitespace between the start-line and 979 the first header field. The presence of such whitespace in a request 980 might be an attempt to trick a server into ignoring that field or 981 processing the line after it as a new request, either of which might 982 result in a security vulnerability if other implementations within 983 the request chain interpret the same message differently. Likewise, 984 the presence of such whitespace in a response might be ignored by 985 some clients or cause others to cease parsing. 987 3.1.1. Request-Line 989 The Request-Line begins with a method token, followed by a single 990 space (SP), the request-target, another single space (SP), the 991 protocol version, and ending with CRLF. 993 Request-Line = Method SP request-target SP HTTP-Version CRLF 995 3.1.1.1. Method 997 The Method token indicates the request method to be performed on the 998 target resource. The request method is case-sensitive. 1000 Method = token 1002 See Section 2 of [Part2] for further information, such as the list of 1003 methods defined by this specification, the IANA registry, and 1004 considerations for new methods. 1006 3.1.1.2. request-target 1008 The request-target identifies the target resource upon which to apply 1009 the request. The four options for request-target are described in 1010 Section 4.1. 1012 request-target = "*" 1013 / absolute-URI 1014 / ( path-absolute [ "?" query ] ) 1015 / authority 1017 HTTP does not place a pre-defined limit on the length of a request- 1018 target. A server MUST be prepared to receive URIs of unbounded 1019 length and respond with the 414 (URI Too Long) status code if the 1020 received request-target would be longer than the server wishes to 1021 handle (see Section 7.4.15 of [Part2]). 1023 Various ad-hoc limitations on request-target length are found in 1024 practice. It is RECOMMENDED that all HTTP senders and recipients 1025 support request-target lengths of 8000 or more octets. 1027 Note: Fragments ([RFC3986], Section 3.5) are not part of the 1028 request-target and thus will not be transmitted in an HTTP 1029 request. 1031 3.1.2. Response Status-Line 1033 The first line of a Response message is the Status-Line, consisting 1034 of the protocol version, a space (SP), the status code, another 1035 space, a possibly-empty textual phrase describing the status code, 1036 and ending with CRLF. 1038 Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF 1040 3.1.2.1. Status Code 1042 The Status-Code element is a 3-digit integer result code of the 1043 attempt to understand and satisfy the request. See Section 4 of 1044 [Part2] for further information, such as the list of status codes 1045 defined by this specification, the IANA registry, and considerations 1046 for new status codes. 1048 Status-Code = 3DIGIT 1050 3.1.2.2. Reason Phrase 1052 The Reason Phrase exists for the sole purpose of providing a textual 1053 description associated with the numeric status code, out of deference 1054 to earlier Internet application protocols that were more frequently 1055 used with interactive text clients. A client SHOULD ignore the 1056 content of the Reason Phrase. 1058 Reason-Phrase = *( HTAB / SP / VCHAR / obs-text ) 1060 3.2. Header Fields 1062 Each HTTP header field consists of a case-insensitive field name 1063 followed by a colon (":"), optional whitespace, and the field value. 1065 header-field = field-name ":" OWS field-value BWS 1066 field-name = token 1067 field-value = *( field-content / obs-fold ) 1068 field-content = *( HTAB / SP / VCHAR / obs-text ) 1070 The field-name token labels the corresponding field-value as having 1071 the semantics defined by that header field. For example, the Date 1072 header field is defined in Section 9.2 of [Part2] as containing the 1073 origination timestamp for the message in which it appears. 1075 HTTP header fields are fully extensible: there is no limit on the 1076 introduction of new field names, each presumably defining new 1077 semantics, or on the number of header fields used in a given message. 1078 Existing fields are defined in each part of this specification and in 1079 many other specifications outside the standards process. New header 1080 fields can be introduced without changing the protocol version if 1081 their defined semantics allow them to be safely ignored by recipients 1082 that do not recognize them. 1084 New HTTP header fields SHOULD be registered with IANA according to 1085 the procedures in Section 3.1 of [Part2]. Unrecognized header fields 1086 MUST be forwarded by a proxy unless the field-name is listed in the 1087 Connection header field (Section 8.1) or the proxy is specifically 1088 configured to block or otherwise transform such fields. Unrecognized 1089 header fields SHOULD be ignored by other recipients. 1091 The order in which header fields with differing field names are 1092 received is not significant. However, it is "good practice" to send 1093 header fields that contain control data first, such as Host on 1094 requests and Date on responses, so that implementations can decide 1095 when not to handle a message as early as possible. A server MUST 1096 wait until the entire header section is received before interpreting 1097 a request message, since later header fields might include 1098 conditionals, authentication credentials, or deliberately misleading 1099 duplicate header fields that would impact request processing. 1101 Multiple header fields with the same field name MUST NOT be sent in a 1102 message unless the entire field value for that header field is 1103 defined as a comma-separated list [i.e., #(values)]. Multiple header 1104 fields with the same field name can be combined into one "field-name: 1105 field-value" pair, without changing the semantics of the message, by 1106 appending each subsequent field value to the combined field value in 1107 order, separated by a comma. The order in which header fields with 1108 the same field name are received is therefore significant to the 1109 interpretation of the combined field value; a proxy MUST NOT change 1110 the order of these field values when forwarding a message. 1112 Note: The "Set-Cookie" header field as implemented in practice can 1113 occur multiple times, but does not use the list syntax, and thus 1114 cannot be combined into a single line ([RFC6265]). (See Appendix 1115 A.2.3 of [Kri2001] for details.) Also note that the Set-Cookie2 1116 header field specified in [RFC2965] does not share this problem. 1118 3.2.1. Field Parsing 1120 No whitespace is allowed between the header field-name and colon. In 1121 the past, differences in the handling of such whitespace have led to 1122 security vulnerabilities in request routing and response handling. 1123 Any received request message that contains whitespace between a 1124 header field-name and colon MUST be rejected with a response code of 1125 400 (Bad Request). A proxy MUST remove any such whitespace from a 1126 response message before forwarding the message downstream. 1128 A field value MAY be preceded by optional whitespace (OWS); a single 1129 SP is preferred. The field value does not include any leading or 1130 trailing white space: OWS occurring before the first non-whitespace 1131 octet of the field value or after the last non-whitespace octet of 1132 the field value is ignored and SHOULD be removed before further 1133 processing (as this does not change the meaning of the header field). 1135 Historically, HTTP header field values could be extended over 1136 multiple lines by preceding each extra line with at least one space 1137 or horizontal tab (obs-fold). This specification deprecates such 1138 line folding except within the message/http media type 1139 (Section 9.3.1). HTTP senders MUST NOT produce messages that include 1140 line folding (i.e., that contain any field-content that matches the 1141 obs-fold rule) unless the message is intended for packaging within 1142 the message/http media type. HTTP recipients SHOULD accept line 1143 folding and replace any embedded obs-fold whitespace with either a 1144 single SP or a matching number of SP octets (to avoid buffer copying) 1145 prior to interpreting the field value or forwarding the message 1146 downstream. 1148 Historically, HTTP has allowed field content with text in the ISO- 1149 8859-1 [ISO-8859-1] character encoding and supported other character 1150 sets only through use of [RFC2047] encoding. In practice, most HTTP 1151 header field values use only a subset of the US-ASCII character 1152 encoding [USASCII]. Newly defined header fields SHOULD limit their 1153 field values to US-ASCII octets. Recipients SHOULD treat other (obs- 1154 text) octets in field content as opaque data. 1156 3.2.2. Field Length 1158 HTTP does not place a pre-defined limit on the length of header 1159 fields, either in isolation or as a set. A server MUST be prepared 1160 to receive request header fields of unbounded length and respond with 1161 a 4xx status code if the received header field(s) would be longer 1162 than the server wishes to handle. 1164 A client that receives response headers that are longer than it 1165 wishes to handle can only treat it as a server error. 1167 Various ad-hoc limitations on header length are found in practice. 1168 It is RECOMMENDED that all HTTP senders and recipients support 1169 messages whose combined header fields have 4000 or more octets. 1171 3.2.3. Common Field ABNF Rules 1173 Many HTTP/1.1 header field values consist of words (token or quoted- 1174 string) separated by whitespace or special characters. These special 1175 characters MUST be in a quoted string to be used within a parameter 1176 value (as defined in Section 5.1). 1178 word = token / quoted-string 1180 token = 1*tchar 1182 tchar = "!" / "#" / "$" / "%" / "&" / "'" / "*" 1183 / "+" / "-" / "." / "^" / "_" / "`" / "|" / "~" 1184 / DIGIT / ALPHA 1185 ; any VCHAR, except special 1187 special = "(" / ")" / "<" / ">" / "@" / "," 1188 / ";" / ":" / "\" / DQUOTE / "/" / "[" 1189 / "]" / "?" / "=" / "{" / "}" 1191 A string of text is parsed as a single word if it is quoted using 1192 double-quote marks. 1194 quoted-string = DQUOTE *( qdtext / quoted-pair ) DQUOTE 1195 qdtext = OWS / %x21 / %x23-5B / %x5D-7E / obs-text 1196 obs-text = %x80-FF 1198 The backslash octet ("\") can be used as a single-octet quoting 1199 mechanism within quoted-string constructs: 1201 quoted-pair = "\" ( HTAB / SP / VCHAR / obs-text ) 1203 Recipients that process the value of the quoted-string MUST handle a 1204 quoted-pair as if it were replaced by the octet following the 1205 backslash. 1207 Senders SHOULD NOT escape octets in quoted-strings that do not 1208 require escaping (i.e., other than DQUOTE and the backslash octet). 1210 Comments can be included in some HTTP header fields by surrounding 1211 the comment text with parentheses. Comments are only allowed in 1212 fields containing "comment" as part of their field value definition. 1214 comment = "(" *( ctext / quoted-cpair / comment ) ")" 1215 ctext = OWS / %x21-27 / %x2A-5B / %x5D-7E / obs-text 1217 The backslash octet ("\") can be used as a single-octet quoting 1218 mechanism within comment constructs: 1220 quoted-cpair = "\" ( HTAB / SP / VCHAR / obs-text ) 1222 Senders SHOULD NOT escape octets in comments that do not require 1223 escaping (i.e., other than the backslash octet "\" and the 1224 parentheses "(" and ")"). 1226 3.3. Message Body 1228 The message-body (if any) of an HTTP message is used to carry the 1229 payload body associated with the request or response. 1231 message-body = *OCTET 1233 The message-body differs from the payload body only when a transfer- 1234 coding has been applied, as indicated by the Transfer-Encoding header 1235 field (Section 8.6). If more than one Transfer-Encoding header field 1236 is present in a message, the multiple field-values MUST be combined 1237 into one field-value, according to the algorithm defined in 1238 Section 3.2, before determining the message-body length. 1240 When one or more transfer-codings are applied to a payload in order 1241 to form the message-body, the Transfer-Encoding header field MUST 1242 contain the list of transfer-codings applied. Transfer-Encoding is a 1243 property of the message, not of the payload, and thus MAY be added or 1244 removed by any implementation along the request/response chain under 1245 the constraints found in Section 5.1. 1247 If a message is received that has multiple Content-Length header 1248 fields (Section 8.2) with field-values consisting of the same decimal 1249 value, or a single Content-Length header field with a field value 1250 containing a list of identical decimal values (e.g., "Content-Length: 1251 42, 42"), indicating that duplicate Content-Length header fields have 1252 been generated or combined by an upstream message processor, then the 1253 recipient MUST either reject the message as invalid or replace the 1254 duplicated field-values with a single valid Content-Length field 1255 containing that decimal value prior to determining the message-body 1256 length. 1258 The rules for when a message-body is allowed in a message differ for 1259 requests and responses. 1261 The presence of a message-body in a request is signaled by the 1262 inclusion of a Content-Length or Transfer-Encoding header field in 1263 the request's header fields, even if the request method does not 1264 define any use for a message-body. This allows the request message 1265 framing algorithm to be independent of method semantics. 1267 For response messages, whether or not a message-body is included with 1268 a message is dependent on both the request method and the response 1269 status code (Section 3.1.2.1). Responses to the HEAD request method 1270 never include a message-body because the associated response header 1271 fields (e.g., Transfer-Encoding, Content-Length, etc.) only indicate 1272 what their values would have been if the request method had been GET. 1273 All 1xx (Informational), 204 (No Content), and 304 (Not Modified) 1274 responses MUST NOT include a message-body. All other responses do 1275 include a message-body, although the body MAY be of zero length. 1277 The length of the message-body is determined by one of the following 1278 (in order of precedence): 1280 1. Any response to a HEAD request and any response with a status 1281 code of 100-199, 204, or 304 is always terminated by the first 1282 empty line after the header fields, regardless of the header 1283 fields present in the message, and thus cannot contain a message- 1284 body. 1286 2. If a Transfer-Encoding header field is present and the "chunked" 1287 transfer-coding (Section 5.1) is the final encoding, the message- 1288 body length is determined by reading and decoding the chunked 1289 data until the transfer-coding indicates the data is complete. 1291 If a Transfer-Encoding header field is present in a response and 1292 the "chunked" transfer-coding is not the final encoding, the 1293 message-body length is determined by reading the connection until 1294 it is closed by the server. If a Transfer-Encoding header field 1295 is present in a request and the "chunked" transfer-coding is not 1296 the final encoding, the message-body length cannot be determined 1297 reliably; the server MUST respond with the 400 (Bad Request) 1298 status code and then close the connection. 1300 If a message is received with both a Transfer-Encoding header 1301 field and a Content-Length header field, the Transfer-Encoding 1302 overrides the Content-Length. Such a message might indicate an 1303 attempt to perform request or response smuggling (bypass of 1304 security-related checks on message routing or content) and thus 1305 ought to be handled as an error. The provided Content-Length 1306 MUST be removed, prior to forwarding the message downstream, or 1307 replaced with the real message-body length after the transfer- 1308 coding is decoded. 1310 3. If a message is received without Transfer-Encoding and with 1311 either multiple Content-Length header fields having differing 1312 field-values or a single Content-Length header field having an 1313 invalid value, then the message framing is invalid and MUST be 1314 treated as an error to prevent request or response smuggling. If 1315 this is a request message, the server MUST respond with a 400 1316 (Bad Request) status code and then close the connection. If this 1317 is a response message received by a proxy, the proxy MUST discard 1318 the received response, send a 502 (Bad Gateway) status code as 1319 its downstream response, and then close the connection. If this 1320 is a response message received by a user-agent, it MUST be 1321 treated as an error by discarding the message and closing the 1322 connection. 1324 4. If a valid Content-Length header field is present without 1325 Transfer-Encoding, its decimal value defines the message-body 1326 length in octets. If the actual number of octets sent in the 1327 message is less than the indicated Content-Length, the recipient 1328 MUST consider the message to be incomplete and treat the 1329 connection as no longer usable. If the actual number of octets 1330 sent in the message is more than the indicated Content-Length, 1331 the recipient MUST only process the message-body up to the field 1332 value's number of octets; the remainder of the message MUST 1333 either be discarded or treated as the next message in a pipeline. 1334 For the sake of robustness, a user-agent MAY attempt to detect 1335 and correct such an error in message framing if it is parsing the 1336 response to the last request on a connection and the connection 1337 has been closed by the server. 1339 5. If this is a request message and none of the above are true, then 1340 the message-body length is zero (no message-body is present). 1342 6. Otherwise, this is a response message without a declared message- 1343 body length, so the message-body length is determined by the 1344 number of octets received prior to the server closing the 1345 connection. 1347 Since there is no way to distinguish a successfully completed, close- 1348 delimited message from a partially-received message interrupted by 1349 network failure, implementations SHOULD use encoding or length- 1350 delimited messages whenever possible. The close-delimiting feature 1351 exists primarily for backwards compatibility with HTTP/1.0. 1353 A server MAY reject a request that contains a message-body but not a 1354 Content-Length by responding with 411 (Length Required). 1356 Unless a transfer-coding other than "chunked" has been applied, a 1357 client that sends a request containing a message-body SHOULD use a 1358 valid Content-Length header field if the message-body length is known 1359 in advance, rather than the "chunked" encoding, since some existing 1360 services respond to "chunked" with a 411 (Length Required) status 1361 code even though they understand the chunked encoding. This is 1362 typically because such services are implemented via a gateway that 1363 requires a content-length in advance of being called and the server 1364 is unable or unwilling to buffer the entire request before 1365 processing. 1367 A client that sends a request containing a message-body MUST include 1368 a valid Content-Length header field if it does not know the server 1369 will handle HTTP/1.1 (or later) requests; such knowledge can be in 1370 the form of specific user configuration or by remembering the version 1371 of a prior received response. 1373 3.4. Handling Incomplete Messages 1375 Request messages that are prematurely terminated, possibly due to a 1376 cancelled connection or a server-imposed time-out exception, MUST 1377 result in closure of the connection; sending an HTTP/1.1 error 1378 response prior to closing the connection is OPTIONAL. 1380 Response messages that are prematurely terminated, usually by closure 1381 of the connection prior to receiving the expected number of octets or 1382 by failure to decode a transfer-encoded message-body, MUST be 1383 recorded as incomplete. A response that terminates in the middle of 1384 the header block (before the empty line is received) cannot be 1385 assumed to convey the full semantics of the response and MUST be 1386 treated as an error. 1388 A message-body that uses the chunked transfer encoding is incomplete 1389 if the zero-sized chunk that terminates the encoding has not been 1390 received. A message that uses a valid Content-Length is incomplete 1391 if the size of the message-body received (in octets) is less than the 1392 value given by Content-Length. A response that has neither chunked 1393 transfer encoding nor Content-Length is terminated by closure of the 1394 connection, and thus is considered complete regardless of the number 1395 of message-body octets received, provided that the header block was 1396 received intact. 1398 A user agent MUST NOT render an incomplete response message-body as 1399 if it were complete (i.e., some indication must be given to the user 1400 that an error occurred). Cache requirements for incomplete responses 1401 are defined in Section 2.1 of [Part6]. 1403 A server MUST read the entire request message-body or close the 1404 connection after sending its response, since otherwise the remaining 1405 data on a persistent connection would be misinterpreted as the next 1406 request. Likewise, a client MUST read the entire response message- 1407 body if it intends to reuse the same connection for a subsequent 1408 request. Pipelining multiple requests on a connection is described 1409 in Section 6.1.2.2. 1411 3.5. Message Parsing Robustness 1413 Older HTTP/1.0 client implementations might send an extra CRLF after 1414 a POST request as a lame workaround for some early server 1415 applications that failed to read message-body content that was not 1416 terminated by a line-ending. An HTTP/1.1 client MUST NOT preface or 1417 follow a request with an extra CRLF. If terminating the request 1418 message-body with a line-ending is desired, then the client MUST 1419 include the terminating CRLF octets as part of the message-body 1420 length. 1422 In the interest of robustness, servers SHOULD ignore at least one 1423 empty line received where a Request-Line is expected. In other 1424 words, if the server is reading the protocol stream at the beginning 1425 of a message and receives a CRLF first, it SHOULD ignore the CRLF. 1426 Likewise, although the line terminator for the start-line and header 1427 fields is the sequence CRLF, we recommend that recipients recognize a 1428 single LF as a line terminator and ignore any CR. 1430 When a server listening only for HTTP request messages, or processing 1431 what appears from the start-line to be an HTTP request message, 1432 receives a sequence of octets that does not match the HTTP-message 1433 grammar aside from the robustness exceptions listed above, the server 1434 MUST respond with an HTTP/1.1 400 (Bad Request) response. 1436 4. Message Routing 1438 In most cases, the user agent is provided a URI reference from which 1439 it determines an absolute URI for identifying the target resource. 1440 When a request to the resource is initiated, all or part of that URI 1441 is used to construct the HTTP request-target. 1443 4.1. Types of Request Target 1445 The four options for request-target are dependent on the nature of 1446 the request. 1448 The asterisk "*" form of request-target, which MUST NOT be used with 1449 any request method other than OPTIONS, means that the request applies 1450 to the server as a whole (the listening process) rather than to a 1451 specific named resource at that server. For example, 1453 OPTIONS * HTTP/1.1 1455 The "absolute-URI" form is REQUIRED when the request is being made to 1456 a proxy. The proxy is requested to either forward the request or 1457 service it from a valid cache, and then return the response. Note 1458 that the proxy MAY forward the request on to another proxy or 1459 directly to the server specified by the absolute-URI. In order to 1460 avoid request loops, a proxy that forwards requests to other proxies 1461 MUST be able to recognize and exclude all of its own server names, 1462 including any aliases, local variations, and the numeric IP address. 1463 An example Request-Line would be: 1465 GET http://www.example.org/pub/WWW/TheProject.html HTTP/1.1 1467 To allow for transition to absolute-URIs in all requests in future 1468 versions of HTTP, all HTTP/1.1 servers MUST accept the absolute-URI 1469 form in requests, even though HTTP/1.1 clients will only generate 1470 them in requests to proxies. 1472 If a proxy receives a host name that is not a fully qualified domain 1473 name, it MAY add its domain to the host name it received. If a proxy 1474 receives a fully qualified domain name, the proxy MUST NOT change the 1475 host name. 1477 The "authority form" is only used by the CONNECT request method 1478 (Section 6.9 of [Part2]). 1480 The most common form of request-target is that used when making a 1481 request to an origin server ("origin form"). In this case, the 1482 absolute path and query components of the URI MUST be transmitted as 1483 the request-target, and the authority component MUST be transmitted 1484 in a Host header field. For example, a client wishing to retrieve a 1485 representation of the resource, as identified above, directly from 1486 the origin server would open (or reuse) a TCP connection to port 80 1487 of the host "www.example.org" and send the lines: 1489 GET /pub/WWW/TheProject.html HTTP/1.1 1490 Host: www.example.org 1492 followed by the remainder of the Request. Note that the origin form 1493 of request-target always starts with an absolute path; if the target 1494 resource's URI path is empty, then an absolute path of "/" MUST be 1495 provided in the request-target. 1497 If a proxy receives an OPTIONS request with an absolute-URI form of 1498 request-target in which the URI has an empty path and no query 1499 component, then the last proxy on the request chain MUST use a 1500 request-target of "*" when it forwards the request to the indicated 1501 origin server. 1503 For example, the request 1505 OPTIONS http://www.example.org:8001 HTTP/1.1 1507 would be forwarded by the final proxy as 1509 OPTIONS * HTTP/1.1 1510 Host: www.example.org:8001 1512 after connecting to port 8001 of host "www.example.org". 1514 The request-target is transmitted in the format specified in 1515 Section 2.7.1. If the request-target is percent-encoded ([RFC3986], 1516 Section 2.1), the origin server MUST decode the request-target in 1517 order to properly interpret the request. Servers SHOULD respond to 1518 invalid request-targets with an appropriate status code. 1520 A non-transforming proxy MUST NOT rewrite the "path-absolute" part of 1521 the received request-target when forwarding it to the next inbound 1522 server, except as noted above to replace a null path-absolute with 1523 "/" or "*". 1525 Note: The "no rewrite" rule prevents the proxy from changing the 1526 meaning of the request when the origin server is improperly using 1527 a non-reserved URI character for a reserved purpose. Implementors 1528 need to be aware that some pre-HTTP/1.1 proxies have been known to 1529 rewrite the request-target. 1531 4.2. The Resource Identified by a Request 1533 The exact resource identified by an Internet request is determined by 1534 examining both the request-target and the Host header field. 1536 An origin server that does not allow resources to differ by the 1537 requested host MAY ignore the Host header field value when 1538 determining the resource identified by an HTTP/1.1 request. (But see 1539 Appendix A.1.1 for other requirements on Host support in HTTP/1.1.) 1541 An origin server that does differentiate resources based on the host 1542 requested (sometimes referred to as virtual hosts or vanity host 1543 names) MUST use the following rules for determining the requested 1544 resource on an HTTP/1.1 request: 1546 1. If request-target is an absolute-URI, the host is part of the 1547 request-target. Any Host header field value in the request MUST 1548 be ignored. 1550 2. If the request-target is not an absolute-URI, and the request 1551 includes a Host header field, the host is determined by the Host 1552 header field value. 1554 3. If the host as determined by rule 1 or 2 is not a valid host on 1555 the server, the response MUST be a 400 (Bad Request) error 1556 message. 1558 Recipients of an HTTP/1.0 request that lacks a Host header field MAY 1559 attempt to use heuristics (e.g., examination of the URI path for 1560 something unique to a particular host) in order to determine what 1561 exact resource is being requested. 1563 4.3. Effective Request URI 1565 HTTP requests often do not carry the absolute URI ([RFC3986], Section 1566 4.3) for the target resource; instead, the URI needs to be inferred 1567 from the request-target, Host header field, and connection context. 1568 The result of this process is called the "effective request URI". 1569 The "target resource" is the resource identified by the effective 1570 request URI. 1572 If the request-target is an absolute-URI, then the effective request 1573 URI is the request-target. 1575 If the request-target uses the path-absolute form or the asterisk 1576 form, and the Host header field is present, then the effective 1577 request URI is constructed by concatenating 1579 o the scheme name: "http" if the request was received over an 1580 insecure TCP connection, or "https" when received over a SSL/ 1581 TLS-secured TCP connection, 1583 o the octet sequence "://", 1585 o the authority component, as specified in the Host header field 1586 (Section 8.3), and 1588 o the request-target obtained from the Request-Line, unless the 1589 request-target is just the asterisk "*". 1591 If the request-target uses the path-absolute form or the asterisk 1592 form, and the Host header field is not present, then the effective 1593 request URI is undefined. 1595 Otherwise, when request-target uses the authority form, the effective 1596 request URI is undefined. 1598 Example 1: the effective request URI for the message 1600 GET /pub/WWW/TheProject.html HTTP/1.1 1601 Host: www.example.org:8080 1603 (received over an insecure TCP connection) is "http", plus "://", 1604 plus the authority component "www.example.org:8080", plus the 1605 request-target "/pub/WWW/TheProject.html", thus 1606 "http://www.example.org:8080/pub/WWW/TheProject.html". 1608 Example 2: the effective request URI for the message 1610 OPTIONS * HTTP/1.1 1611 Host: www.example.org 1613 (received over an SSL/TLS secured TCP connection) is "https", plus 1614 "://", plus the authority component "www.example.org", thus 1615 "https://www.example.org". 1617 Effective request URIs are compared using the rules described in 1618 Section 2.7.3, except that empty path components MUST NOT be treated 1619 as equivalent to an absolute path of "/". 1621 5. Protocol Parameters 1623 5.1. Transfer Codings 1625 Transfer-coding values are used to indicate an encoding 1626 transformation that has been, can be, or might need to be applied to 1627 a payload body in order to ensure "safe transport" through the 1628 network. This differs from a content coding in that the transfer- 1629 coding is a property of the message rather than a property of the 1630 representation that is being transferred. 1632 transfer-coding = "chunked" ; Section 5.1.1 1633 / "compress" ; Section 5.1.2.1 1634 / "deflate" ; Section 5.1.2.2 1635 / "gzip" ; Section 5.1.2.3 1636 / transfer-extension 1637 transfer-extension = token *( OWS ";" OWS transfer-parameter ) 1639 Parameters are in the form of attribute/value pairs. 1641 transfer-parameter = attribute BWS "=" BWS value 1642 attribute = token 1643 value = word 1645 All transfer-coding values are case-insensitive. HTTP/1.1 uses 1646 transfer-coding values in the TE header field (Section 8.4) and in 1647 the Transfer-Encoding header field (Section 8.6). 1649 Transfer-codings are analogous to the Content-Transfer-Encoding 1650 values of MIME, which were designed to enable safe transport of 1651 binary data over a 7-bit transport service ([RFC2045], Section 6). 1652 However, safe transport has a different focus for an 8bit-clean 1653 transfer protocol. In HTTP, the only unsafe characteristic of 1654 message-bodies is the difficulty in determining the exact message 1655 body length (Section 3.3), or the desire to encrypt data over a 1656 shared transport. 1658 A server that receives a request message with a transfer-coding it 1659 does not understand SHOULD respond with 501 (Not Implemented) and 1660 then close the connection. A server MUST NOT send transfer-codings 1661 to an HTTP/1.0 client. 1663 5.1.1. Chunked Transfer Coding 1665 The chunked encoding modifies the body of a message in order to 1666 transfer it as a series of chunks, each with its own size indicator, 1667 followed by an OPTIONAL trailer containing header fields. This 1668 allows dynamically produced content to be transferred along with the 1669 information necessary for the recipient to verify that it has 1670 received the full message. 1672 Chunked-Body = *chunk 1673 last-chunk 1674 trailer-part 1675 CRLF 1677 chunk = chunk-size [ chunk-ext ] CRLF 1678 chunk-data CRLF 1679 chunk-size = 1*HEXDIG 1680 last-chunk = 1*("0") [ chunk-ext ] CRLF 1682 chunk-ext = *( ";" chunk-ext-name 1683 [ "=" chunk-ext-val ] ) 1684 chunk-ext-name = token 1685 chunk-ext-val = token / quoted-str-nf 1686 chunk-data = 1*OCTET ; a sequence of chunk-size octets 1687 trailer-part = *( header-field CRLF ) 1689 quoted-str-nf = DQUOTE *( qdtext-nf / quoted-pair ) DQUOTE 1690 ; like quoted-string, but disallowing line folding 1691 qdtext-nf = HTAB / SP / %x21 / %x23-5B / %x5D-7E / obs-text 1693 The chunk-size field is a string of hex digits indicating the size of 1694 the chunk-data in octets. The chunked encoding is ended by any chunk 1695 whose size is zero, followed by the trailer, which is terminated by 1696 an empty line. 1698 The trailer allows the sender to include additional HTTP header 1699 fields at the end of the message. The Trailer header field can be 1700 used to indicate which header fields are included in a trailer (see 1701 Section 8.5). 1703 A server using chunked transfer-coding in a response MUST NOT use the 1704 trailer for any header fields unless at least one of the following is 1705 true: 1707 1. the request included a TE header field that indicates "trailers" 1708 is acceptable in the transfer-coding of the response, as 1709 described in Section 8.4; or, 1711 2. the trailer fields consist entirely of optional metadata, and the 1712 recipient could use the message (in a manner acceptable to the 1713 server where the field originated) without receiving it. In 1714 other words, the server that generated the header (often but not 1715 always the origin server) is willing to accept the possibility 1716 that the trailer fields might be silently discarded along the 1717 path to the client. 1719 This requirement prevents an interoperability failure when the 1720 message is being received by an HTTP/1.1 (or later) proxy and 1721 forwarded to an HTTP/1.0 recipient. It avoids a situation where 1722 compliance with the protocol would have necessitated a possibly 1723 infinite buffer on the proxy. 1725 A process for decoding the "chunked" transfer-coding can be 1726 represented in pseudo-code as: 1728 length := 0 1729 read chunk-size, chunk-ext (if any) and CRLF 1730 while (chunk-size > 0) { 1731 read chunk-data and CRLF 1732 append chunk-data to decoded-body 1733 length := length + chunk-size 1734 read chunk-size and CRLF 1735 } 1736 read header-field 1737 while (header-field not empty) { 1738 append header-field to existing header fields 1739 read header-field 1740 } 1741 Content-Length := length 1742 Remove "chunked" from Transfer-Encoding 1744 All HTTP/1.1 applications MUST be able to receive and decode the 1745 "chunked" transfer-coding and MUST ignore chunk-ext extensions they 1746 do not understand. 1748 Since "chunked" is the only transfer-coding required to be understood 1749 by HTTP/1.1 recipients, it plays a crucial role in delimiting 1750 messages on a persistent connection. Whenever a transfer-coding is 1751 applied to a payload body in a request, the final transfer-coding 1752 applied MUST be "chunked". If a transfer-coding is applied to a 1753 response payload body, then either the final transfer-coding applied 1754 MUST be "chunked" or the message MUST be terminated by closing the 1755 connection. When the "chunked" transfer-coding is used, it MUST be 1756 the last transfer-coding applied to form the message-body. The 1757 "chunked" transfer-coding MUST NOT be applied more than once in a 1758 message-body. 1760 5.1.2. Compression Codings 1762 The codings defined below can be used to compress the payload of a 1763 message. 1765 Note: Use of program names for the identification of encoding 1766 formats is not desirable and is discouraged for future encodings. 1767 Their use here is representative of historical practice, not good 1768 design. 1770 Note: For compatibility with previous implementations of HTTP, 1771 applications SHOULD consider "x-gzip" and "x-compress" to be 1772 equivalent to "gzip" and "compress" respectively. 1774 5.1.2.1. Compress Coding 1776 The "compress" format is produced by the common UNIX file compression 1777 program "compress". This format is an adaptive Lempel-Ziv-Welch 1778 coding (LZW). 1780 5.1.2.2. Deflate Coding 1782 The "deflate" format is defined as the "deflate" compression 1783 mechanism (described in [RFC1951]) used inside the "zlib" data format 1784 ([RFC1950]). 1786 Note: Some incorrect implementations send the "deflate" compressed 1787 data without the zlib wrapper. 1789 5.1.2.3. Gzip Coding 1791 The "gzip" format is produced by the file compression program "gzip" 1792 (GNU zip), as described in [RFC1952]. This format is a Lempel-Ziv 1793 coding (LZ77) with a 32 bit CRC. 1795 5.1.3. Transfer Coding Registry 1797 The HTTP Transfer Coding Registry defines the name space for the 1798 transfer coding names. 1800 Registrations MUST include the following fields: 1802 o Name 1804 o Description 1806 o Pointer to specification text 1808 Names of transfer codings MUST NOT overlap with names of content 1809 codings (Section 2.2 of [Part3]), unless the encoding transformation 1810 is identical (as it is the case for the compression codings defined 1811 in Section 5.1.2). 1813 Values to be added to this name space require a specification (see 1814 "Specification Required" in Section 4.1 of [RFC5226]), and MUST 1815 conform to the purpose of transfer coding defined in this section. 1817 The registry itself is maintained at 1818 . 1820 5.2. Product Tokens 1822 Product tokens are used to allow communicating applications to 1823 identify themselves by software name and version. Most fields using 1824 product tokens also allow sub-products which form a significant part 1825 of the application to be listed, separated by whitespace. By 1826 convention, the products are listed in order of their significance 1827 for identifying the application. 1829 product = token ["/" product-version] 1830 product-version = token 1832 Examples: 1834 User-Agent: CERN-LineMode/2.15 libwww/2.17b3 1835 Server: Apache/0.8.4 1837 Product tokens SHOULD be short and to the point. They MUST NOT be 1838 used for advertising or other non-essential information. Although 1839 any token octet MAY appear in a product-version, this token SHOULD 1840 only be used for a version identifier (i.e., successive versions of 1841 the same product SHOULD only differ in the product-version portion of 1842 the product value). 1844 5.3. Quality Values 1846 Both transfer codings (TE request header field, Section 8.4) and 1847 content negotiation (Section 5 of [Part3]) use short "floating point" 1848 numbers to indicate the relative importance ("weight") of various 1849 negotiable parameters. A weight is normalized to a real number in 1850 the range 0 through 1, where 0 is the minimum and 1 the maximum 1851 value. If a parameter has a quality value of 0, then content with 1852 this parameter is "not acceptable" for the client. HTTP/1.1 1853 applications MUST NOT generate more than three digits after the 1854 decimal point. User configuration of these values SHOULD also be 1855 limited in this fashion. 1857 qvalue = ( "0" [ "." 0*3DIGIT ] ) 1858 / ( "1" [ "." 0*3("0") ] ) 1860 Note: "Quality values" is a misnomer, since these values merely 1861 represent relative degradation in desired quality. 1863 6. Connections 1865 6.1. Persistent Connections 1867 6.1.1. Purpose 1869 Prior to persistent connections, a separate TCP connection was 1870 established for each request, increasing the load on HTTP servers and 1871 causing congestion on the Internet. The use of inline images and 1872 other associated data often requires a client to make multiple 1873 requests of the same server in a short amount of time. Analysis of 1874 these performance problems and results from a prototype 1875 implementation are available [Pad1995] [Spe]. Implementation 1876 experience and measurements of actual HTTP/1.1 implementations show 1877 good results [Nie1997]. Alternatives have also been explored, for 1878 example, T/TCP [Tou1998]. 1880 Persistent HTTP connections have a number of advantages: 1882 o By opening and closing fewer TCP connections, CPU time is saved in 1883 routers and hosts (clients, servers, proxies, gateways, tunnels, 1884 or caches), and memory used for TCP protocol control blocks can be 1885 saved in hosts. 1887 o HTTP requests and responses can be pipelined on a connection. 1888 Pipelining allows a client to make multiple requests without 1889 waiting for each response, allowing a single TCP connection to be 1890 used much more efficiently, with much lower elapsed time. 1892 o Network congestion is reduced by reducing the number of packets 1893 caused by TCP opens, and by allowing TCP sufficient time to 1894 determine the congestion state of the network. 1896 o Latency on subsequent requests is reduced since there is no time 1897 spent in TCP's connection opening handshake. 1899 o HTTP can evolve more gracefully, since errors can be reported 1900 without the penalty of closing the TCP connection. Clients using 1901 future versions of HTTP might optimistically try a new feature, 1902 but if communicating with an older server, retry with old 1903 semantics after an error is reported. 1905 HTTP implementations SHOULD implement persistent connections. 1907 6.1.2. Overall Operation 1909 A significant difference between HTTP/1.1 and earlier versions of 1910 HTTP is that persistent connections are the default behavior of any 1911 HTTP connection. That is, unless otherwise indicated, the client 1912 SHOULD assume that the server will maintain a persistent connection, 1913 even after error responses from the server. 1915 Persistent connections provide a mechanism by which a client and a 1916 server can signal the close of a TCP connection. This signaling 1917 takes place using the Connection header field (Section 8.1). Once a 1918 close has been signaled, the client MUST NOT send any more requests 1919 on that connection. 1921 6.1.2.1. Negotiation 1923 An HTTP/1.1 server MAY assume that a HTTP/1.1 client intends to 1924 maintain a persistent connection unless a Connection header field 1925 including the connection-token "close" was sent in the request. If 1926 the server chooses to close the connection immediately after sending 1927 the response, it SHOULD send a Connection header field including the 1928 connection-token "close". 1930 An HTTP/1.1 client MAY expect a connection to remain open, but would 1931 decide to keep it open based on whether the response from a server 1932 contains a Connection header field with the connection-token close. 1934 In case the client does not want to maintain a connection for more 1935 than that request, it SHOULD send a Connection header field including 1936 the connection-token close. 1938 If either the client or the server sends the close token in the 1939 Connection header field, that request becomes the last one for the 1940 connection. 1942 Clients and servers SHOULD NOT assume that a persistent connection is 1943 maintained for HTTP versions less than 1.1 unless it is explicitly 1944 signaled. See Appendix A.1.2 for more information on backward 1945 compatibility with HTTP/1.0 clients. 1947 In order to remain persistent, all messages on the connection MUST 1948 have a self-defined message length (i.e., one not defined by closure 1949 of the connection), as described in Section 3.3. 1951 6.1.2.2. Pipelining 1953 A client that supports persistent connections MAY "pipeline" its 1954 requests (i.e., send multiple requests without waiting for each 1955 response). A server MUST send its responses to those requests in the 1956 same order that the requests were received. 1958 Clients which assume persistent connections and pipeline immediately 1959 after connection establishment SHOULD be prepared to retry their 1960 connection if the first pipelined attempt fails. If a client does 1961 such a retry, it MUST NOT pipeline before it knows the connection is 1962 persistent. Clients MUST also be prepared to resend their requests 1963 if the server closes the connection before sending all of the 1964 corresponding responses. 1966 Clients SHOULD NOT pipeline requests using non-idempotent request 1967 methods or non-idempotent sequences of request methods (see Section 1968 6.1.2 of [Part2]). Otherwise, a premature termination of the 1969 transport connection could lead to indeterminate results. A client 1970 wishing to send a non-idempotent request SHOULD wait to send that 1971 request until it has received the response status line for the 1972 previous request. 1974 6.1.3. Proxy Servers 1976 It is especially important that proxies correctly implement the 1977 properties of the Connection header field as specified in 1978 Section 8.1. 1980 The proxy server MUST signal persistent connections separately with 1981 its clients and the origin servers (or other proxy servers) that it 1982 connects to. Each persistent connection applies to only one 1983 transport link. 1985 A proxy server MUST NOT establish a HTTP/1.1 persistent connection 1986 with an HTTP/1.0 client (but see Section 19.7.1 of [RFC2068] for 1987 information and discussion of the problems with the Keep-Alive header 1988 field implemented by many HTTP/1.0 clients). 1990 6.1.3.1. End-to-end and Hop-by-hop Header Fields 1992 For the purpose of defining the behavior of caches and non-caching 1993 proxies, we divide HTTP header fields into two categories: 1995 o End-to-end header fields, which are transmitted to the ultimate 1996 recipient of a request or response. End-to-end header fields in 1997 responses MUST be stored as part of a cache entry and MUST be 1998 transmitted in any response formed from a cache entry. 2000 o Hop-by-hop header fields, which are meaningful only for a single 2001 transport-level connection, and are not stored by caches or 2002 forwarded by proxies. 2004 The following HTTP/1.1 header fields are hop-by-hop header fields: 2006 o Connection 2008 o Keep-Alive 2010 o Proxy-Authenticate 2012 o Proxy-Authorization 2014 o TE 2016 o Trailer 2018 o Transfer-Encoding 2020 o Upgrade 2022 All other header fields defined by HTTP/1.1 are end-to-end header 2023 fields. 2025 Other hop-by-hop header fields MUST be listed in a Connection header 2026 field (Section 8.1). 2028 6.1.3.2. Non-modifiable Header Fields 2030 Some features of HTTP/1.1, such as Digest Authentication, depend on 2031 the value of certain end-to-end header fields. A non-transforming 2032 proxy SHOULD NOT modify an end-to-end header field unless the 2033 definition of that header field requires or specifically allows that. 2035 A non-transforming proxy MUST NOT modify any of the following fields 2036 in a request or response, and it MUST NOT add any of these fields if 2037 not already present: 2039 o Allow 2041 o Content-Location 2043 o Content-MD5 2045 o ETag 2047 o Last-Modified 2049 o Server 2051 A non-transforming proxy MUST NOT modify any of the following fields 2052 in a response: 2054 o Expires 2056 but it MAY add any of these fields if not already present. If an 2057 Expires header field is added, it MUST be given a field-value 2058 identical to that of the Date header field in that response. 2060 A proxy MUST NOT modify or add any of the following fields in a 2061 message that contains the no-transform cache-control directive, or in 2062 any request: 2064 o Content-Encoding 2066 o Content-Range 2068 o Content-Type 2070 A transforming proxy MAY modify or add these fields to a message that 2071 does not include no-transform, but if it does so, it MUST add a 2072 Warning 214 (Transformation applied) if one does not already appear 2073 in the message (see Section 3.6 of [Part6]). 2075 Warning: Unnecessary modification of end-to-end header fields 2076 might cause authentication failures if stronger authentication 2077 mechanisms are introduced in later versions of HTTP. Such 2078 authentication mechanisms MAY rely on the values of header fields 2079 not listed here. 2081 A non-transforming proxy MUST preserve the message payload ([Part3]), 2082 though it MAY change the message-body through application or removal 2083 of a transfer-coding (Section 5.1). 2085 6.1.4. Practical Considerations 2087 Servers will usually have some time-out value beyond which they will 2088 no longer maintain an inactive connection. Proxy servers might make 2089 this a higher value since it is likely that the client will be making 2090 more connections through the same server. The use of persistent 2091 connections places no requirements on the length (or existence) of 2092 this time-out for either the client or the server. 2094 When a client or server wishes to time-out it SHOULD issue a graceful 2095 close on the transport connection. Clients and servers SHOULD both 2096 constantly watch for the other side of the transport close, and 2097 respond to it as appropriate. If a client or server does not detect 2098 the other side's close promptly it could cause unnecessary resource 2099 drain on the network. 2101 A client, server, or proxy MAY close the transport connection at any 2102 time. For example, a client might have started to send a new request 2103 at the same time that the server has decided to close the "idle" 2104 connection. From the server's point of view, the connection is being 2105 closed while it was idle, but from the client's point of view, a 2106 request is in progress. 2108 Clients (including proxies) SHOULD limit the number of simultaneous 2109 connections that they maintain to a given server (including proxies). 2111 Previous revisions of HTTP gave a specific number of connections as a 2112 ceiling, but this was found to be impractical for many applications. 2113 As a result, this specification does not mandate a particular maximum 2114 number of connections, but instead encourages clients to be 2115 conservative when opening multiple connections. 2117 In particular, while using multiple connections avoids the "head-of- 2118 line blocking" problem (whereby a request that takes significant 2119 server-side processing and/or has a large payload can block 2120 subsequent requests on the same connection), each connection used 2121 consumes server resources (sometimes significantly), and furthermore 2122 using multiple connections can cause undesirable side effects in 2123 congested networks. 2125 Note that servers might reject traffic that they deem abusive, 2126 including an excessive number of connections from a client. 2128 6.1.5. Retrying Requests 2130 Senders can close the transport connection at any time. Therefore, 2131 clients, servers, and proxies MUST be able to recover from 2132 asynchronous close events. Client software MAY reopen the transport 2133 connection and retransmit the aborted sequence of requests without 2134 user interaction so long as the request sequence is idempotent (see 2135 Section 6.1.2 of [Part2]). Non-idempotent request methods or 2136 sequences MUST NOT be automatically retried, although user agents MAY 2137 offer a human operator the choice of retrying the request(s). 2138 Confirmation by user-agent software with semantic understanding of 2139 the application MAY substitute for user confirmation. The automatic 2140 retry SHOULD NOT be repeated if the second sequence of requests 2141 fails. 2143 6.2. Message Transmission Requirements 2145 6.2.1. Persistent Connections and Flow Control 2147 HTTP/1.1 servers SHOULD maintain persistent connections and use TCP's 2148 flow control mechanisms to resolve temporary overloads, rather than 2149 terminating connections with the expectation that clients will retry. 2150 The latter technique can exacerbate network congestion. 2152 6.2.2. Monitoring Connections for Error Status Messages 2154 An HTTP/1.1 (or later) client sending a message-body SHOULD monitor 2155 the network connection for an error status code while it is 2156 transmitting the request. If the client sees an error status code, 2157 it SHOULD immediately cease transmitting the body. If the body is 2158 being sent using a "chunked" encoding (Section 5.1), a zero length 2159 chunk and empty trailer MAY be used to prematurely mark the end of 2160 the message. If the body was preceded by a Content-Length header 2161 field, the client MUST close the connection. 2163 6.2.3. Use of the 100 (Continue) Status 2165 The purpose of the 100 (Continue) status code (see Section 7.1.1 of 2166 [Part2]) is to allow a client that is sending a request message with 2167 a request body to determine if the origin server is willing to accept 2168 the request (based on the request header fields) before the client 2169 sends the request body. In some cases, it might either be 2170 inappropriate or highly inefficient for the client to send the body 2171 if the server will reject the message without looking at the body. 2173 Requirements for HTTP/1.1 clients: 2175 o If a client will wait for a 100 (Continue) response before sending 2176 the request body, it MUST send an Expect header field (Section 9.3 2177 of [Part2]) with the "100-continue" expectation. 2179 o A client MUST NOT send an Expect header field (Section 9.3 of 2180 [Part2]) with the "100-continue" expectation if it does not intend 2181 to send a request body. 2183 Because of the presence of older implementations, the protocol allows 2184 ambiguous situations in which a client might send "Expect: 100- 2185 continue" without receiving either a 417 (Expectation Failed) or a 2186 100 (Continue) status code. Therefore, when a client sends this 2187 header field to an origin server (possibly via a proxy) from which it 2188 has never seen a 100 (Continue) status code, the client SHOULD NOT 2189 wait for an indefinite period before sending the request body. 2191 Requirements for HTTP/1.1 origin servers: 2193 o Upon receiving a request which includes an Expect header field 2194 with the "100-continue" expectation, an origin server MUST either 2195 respond with 100 (Continue) status code and continue to read from 2196 the input stream, or respond with a final status code. The origin 2197 server MUST NOT wait for the request body before sending the 100 2198 (Continue) response. If it responds with a final status code, it 2199 MAY close the transport connection or it MAY continue to read and 2200 discard the rest of the request. It MUST NOT perform the request 2201 method if it returns a final status code. 2203 o An origin server SHOULD NOT send a 100 (Continue) response if the 2204 request message does not include an Expect header field with the 2205 "100-continue" expectation, and MUST NOT send a 100 (Continue) 2206 response if such a request comes from an HTTP/1.0 (or earlier) 2207 client. There is an exception to this rule: for compatibility 2208 with [RFC2068], a server MAY send a 100 (Continue) status code in 2209 response to an HTTP/1.1 PUT or POST request that does not include 2210 an Expect header field with the "100-continue" expectation. This 2211 exception, the purpose of which is to minimize any client 2212 processing delays associated with an undeclared wait for 100 2213 (Continue) status code, applies only to HTTP/1.1 requests, and not 2214 to requests with any other HTTP-version value. 2216 o An origin server MAY omit a 100 (Continue) response if it has 2217 already received some or all of the request body for the 2218 corresponding request. 2220 o An origin server that sends a 100 (Continue) response MUST 2221 ultimately send a final status code, once the request body is 2222 received and processed, unless it terminates the transport 2223 connection prematurely. 2225 o If an origin server receives a request that does not include an 2226 Expect header field with the "100-continue" expectation, the 2227 request includes a request body, and the server responds with a 2228 final status code before reading the entire request body from the 2229 transport connection, then the server SHOULD NOT close the 2230 transport connection until it has read the entire request, or 2231 until the client closes the connection. Otherwise, the client 2232 might not reliably receive the response message. However, this 2233 requirement is not be construed as preventing a server from 2234 defending itself against denial-of-service attacks, or from badly 2235 broken client implementations. 2237 Requirements for HTTP/1.1 proxies: 2239 o If a proxy receives a request that includes an Expect header field 2240 with the "100-continue" expectation, and the proxy either knows 2241 that the next-hop server complies with HTTP/1.1 or higher, or does 2242 not know the HTTP version of the next-hop server, it MUST forward 2243 the request, including the Expect header field. 2245 o If the proxy knows that the version of the next-hop server is 2246 HTTP/1.0 or lower, it MUST NOT forward the request, and it MUST 2247 respond with a 417 (Expectation Failed) status code. 2249 o Proxies SHOULD maintain a record of the HTTP version numbers 2250 received from recently-referenced next-hop servers. 2252 o A proxy MUST NOT forward a 100 (Continue) response if the request 2253 message was received from an HTTP/1.0 (or earlier) client and did 2254 not include an Expect header field with the "100-continue" 2255 expectation. This requirement overrides the general rule for 2256 forwarding of 1xx responses (see Section 7.1 of [Part2]). 2258 7. Miscellaneous notes that might disappear 2260 7.1. Scheme aliases considered harmful 2262 [[TBD-aliases-harmful: describe why aliases like webcal are 2263 harmful.]] 2265 7.2. Use of HTTP for proxy communication 2267 [[TBD-proxy-other: Configured to use HTTP to proxy HTTP or other 2268 protocols.]] 2270 7.3. Interception of HTTP for access control 2272 [[TBD-intercept: Interception of HTTP traffic for initiating access 2273 control.]] 2275 7.4. Use of HTTP by other protocols 2277 [[TBD-profiles: Profiles of HTTP defined by other protocol. 2278 Extensions of HTTP like WebDAV.]] 2280 7.5. Use of HTTP by media type specification 2282 [[TBD-hypertext: Instructions on composing HTTP requests via 2283 hypertext formats.]] 2285 8. Header Field Definitions 2287 This section defines the syntax and semantics of HTTP header fields 2288 related to message origination, framing, and routing. 2290 +-------------------+---------------+ 2291 | Header Field Name | Defined in... | 2292 +-------------------+---------------+ 2293 | Connection | Section 8.1 | 2294 | Content-Length | Section 8.2 | 2295 | Host | Section 8.3 | 2296 | TE | Section 8.4 | 2297 | Trailer | Section 8.5 | 2298 | Transfer-Encoding | Section 8.6 | 2299 | Upgrade | Section 8.7 | 2300 | Via | Section 8.8 | 2301 +-------------------+---------------+ 2303 8.1. Connection 2305 The "Connection" header field allows the sender to specify options 2306 that are desired only for that particular connection. Such 2307 connection options MUST be removed or replaced before the message can 2308 be forwarded downstream by a proxy or gateway. This mechanism also 2309 allows the sender to indicate which HTTP header fields used in the 2310 message are only intended for the immediate recipient ("hop-by-hop"), 2311 as opposed to all recipients on the chain ("end-to-end"), enabling 2312 the message to be self-descriptive and allowing future connection- 2313 specific extensions to be deployed in HTTP without fear that they 2314 will be blindly forwarded by previously deployed intermediaries. 2316 The Connection header field's value has the following grammar: 2318 Connection = 1#connection-token 2319 connection-token = token 2321 A proxy or gateway MUST parse a received Connection header field 2322 before a message is forwarded and, for each connection-token in this 2323 field, remove any header field(s) from the message with the same name 2324 as the connection-token, and then remove the Connection header field 2325 itself or replace it with the sender's own connection options for the 2326 forwarded message. 2328 A sender MUST NOT include field-names in the Connection header field- 2329 value for fields that are defined as expressing constraints for all 2330 recipients in the request or response chain, such as the Cache- 2331 Control header field (Section 3.2 of [Part6]). 2333 The connection options do not have to correspond to a header field 2334 present in the message, since a connection-specific header field 2335 might not be needed if there are no parameters associated with that 2336 connection option. Recipients that trigger certain connection 2337 behavior based on the presence of connection options MUST do so based 2338 on the presence of the connection-token rather than only the presence 2339 of the optional header field. In other words, if the connection 2340 option is received as a header field but not indicated within the 2341 Connection field-value, then the recipient MUST ignore the 2342 connection-specific header field because it has likely been forwarded 2343 by an intermediary that is only partially compliant. 2345 When defining new connection options, specifications ought to 2346 carefully consider existing deployed header fields and ensure that 2347 the new connection-token does not share the same name as an unrelated 2348 header field that might already be deployed. Defining a new 2349 connection-token essentially reserves that potential field-name for 2350 carrying additional information related to the connection option, 2351 since it would be unwise for senders to use that field-name for 2352 anything else. 2354 HTTP/1.1 defines the "close" connection option for the sender to 2355 signal that the connection will be closed after completion of the 2356 response. For example, 2358 Connection: close 2360 in either the request or the response header fields indicates that 2361 the connection SHOULD NOT be considered "persistent" (Section 6.1) 2362 after the current request/response is complete. 2364 An HTTP/1.1 client that does not support persistent connections MUST 2365 include the "close" connection option in every request message. 2367 An HTTP/1.1 server that does not support persistent connections MUST 2368 include the "close" connection option in every response message that 2369 does not have a 1xx (Informational) status code. 2371 8.2. Content-Length 2373 The "Content-Length" header field indicates the size of the message- 2374 body, in decimal number of octets, for any message other than a 2375 response to a HEAD request or a response with a status code of 304. 2376 In the case of a response to a HEAD request, Content-Length indicates 2377 the size of the payload body (not including any potential transfer- 2378 coding) that would have been sent had the request been a GET. In the 2379 case of a 304 (Not Modified) response to a GET request, Content- 2380 Length indicates the size of the payload body (not including any 2381 potential transfer-coding) that would have been sent in a 200 (OK) 2382 response. 2384 Content-Length = 1*DIGIT 2386 An example is 2388 Content-Length: 3495 2390 Implementations SHOULD use this field to indicate the message-body 2391 length when no transfer-coding is being applied and the payload's 2392 body length can be determined prior to being transferred. 2393 Section 3.3 describes how recipients determine the length of a 2394 message-body. 2396 Any Content-Length greater than or equal to zero is a valid value. 2398 Note that the use of this field in HTTP is significantly different 2399 from the corresponding definition in MIME, where it is an optional 2400 field used within the "message/external-body" content-type. 2402 8.3. Host 2404 The "Host" header field in a request provides the host and port 2405 information from the target resource's URI, enabling the origin 2406 server to distinguish between resources while servicing requests for 2407 multiple host names on a single IP address. Since the Host field- 2408 value is critical information for handling a request, it SHOULD be 2409 sent as the first header field following the Request-Line. 2411 Host = uri-host [ ":" port ] ; Section 2.7.1 2413 A client MUST send a Host header field in all HTTP/1.1 request 2414 messages. If the target resource's URI includes an authority 2415 component, then the Host field-value MUST be identical to that 2416 authority component after excluding any userinfo (Section 2.7.1). If 2417 the authority component is missing or undefined for the target 2418 resource's URI, then the Host header field MUST be sent with an empty 2419 field-value. 2421 For example, a GET request to the origin server for 2422 would begin with: 2424 GET /pub/WWW/ HTTP/1.1 2425 Host: www.example.org 2427 The Host header field MUST be sent in an HTTP/1.1 request even if the 2428 request-target is in the form of an absolute-URI, since this allows 2429 the Host information to be forwarded through ancient HTTP/1.0 proxies 2430 that might not have implemented Host. 2432 When an HTTP/1.1 proxy receives a request with a request-target in 2433 the form of an absolute-URI, the proxy MUST ignore the received Host 2434 header field (if any) and instead replace it with the host 2435 information of the request-target. When a proxy forwards a request, 2436 it MUST generate the Host header field based on the received 2437 absolute-URI rather than the received Host. 2439 Since the Host header field acts as an application-level routing 2440 mechanism, it is a frequent target for malware seeking to poison a 2441 shared cache or redirect a request to an unintended server. An 2442 interception proxy is particularly vulnerable if it relies on the 2443 Host header field value for redirecting requests to internal servers, 2444 or for use as a cache key in a shared cache, without first verifying 2445 that the intercepted connection is targeting a valid IP address for 2446 that host. 2448 A server MUST respond with a 400 (Bad Request) status code to any 2449 HTTP/1.1 request message that lacks a Host header field and to any 2450 request message that contains more than one Host header field or a 2451 Host header field with an invalid field-value. 2453 See Sections 4.2 and A.1.1 for other requirements relating to Host. 2455 8.4. TE 2457 The "TE" header field indicates what extension transfer-codings it is 2458 willing to accept in the response, and whether or not it is willing 2459 to accept trailer fields in a chunked transfer-coding. 2461 Its value consists of the keyword "trailers" and/or a comma-separated 2462 list of extension transfer-coding names with optional accept 2463 parameters (as described in Section 5.1). 2465 TE = #t-codings 2466 t-codings = "trailers" / ( transfer-extension [ te-params ] ) 2467 te-params = OWS ";" OWS "q=" qvalue *( te-ext ) 2468 te-ext = OWS ";" OWS token [ "=" word ] 2470 The presence of the keyword "trailers" indicates that the client is 2471 willing to accept trailer fields in a chunked transfer-coding, as 2472 defined in Section 5.1.1. This keyword is reserved for use with 2473 transfer-coding values even though it does not itself represent a 2474 transfer-coding. 2476 Examples of its use are: 2478 TE: deflate 2479 TE: 2480 TE: trailers, deflate;q=0.5 2482 The TE header field only applies to the immediate connection. 2483 Therefore, the keyword MUST be supplied within a Connection header 2484 field (Section 8.1) whenever TE is present in an HTTP/1.1 message. 2486 A server tests whether a transfer-coding is acceptable, according to 2487 a TE field, using these rules: 2489 1. The "chunked" transfer-coding is always acceptable. If the 2490 keyword "trailers" is listed, the client indicates that it is 2491 willing to accept trailer fields in the chunked response on 2492 behalf of itself and any downstream clients. The implication is 2493 that, if given, the client is stating that either all downstream 2494 clients are willing to accept trailer fields in the forwarded 2495 response, or that it will attempt to buffer the response on 2496 behalf of downstream recipients. 2498 Note: HTTP/1.1 does not define any means to limit the size of a 2499 chunked response such that a client can be assured of buffering 2500 the entire response. 2502 2. If the transfer-coding being tested is one of the transfer- 2503 codings listed in the TE field, then it is acceptable unless it 2504 is accompanied by a qvalue of 0. (As defined in Section 5.3, a 2505 qvalue of 0 means "not acceptable".) 2507 3. If multiple transfer-codings are acceptable, then the acceptable 2508 transfer-coding with the highest non-zero qvalue is preferred. 2509 The "chunked" transfer-coding always has a qvalue of 1. 2511 If the TE field-value is empty or if no TE field is present, the only 2512 transfer-coding is "chunked". A message with no transfer-coding is 2513 always acceptable. 2515 8.5. Trailer 2517 The "Trailer" header field indicates that the given set of header 2518 fields is present in the trailer of a message encoded with chunked 2519 transfer-coding. 2521 Trailer = 1#field-name 2523 An HTTP/1.1 message SHOULD include a Trailer header field in a 2524 message using chunked transfer-coding with a non-empty trailer. 2525 Doing so allows the recipient to know which header fields to expect 2526 in the trailer. 2528 If no Trailer header field is present, the trailer SHOULD NOT include 2529 any header fields. See Section 5.1.1 for restrictions on the use of 2530 trailer fields in a "chunked" transfer-coding. 2532 Message header fields listed in the Trailer header field MUST NOT 2533 include the following header fields: 2535 o Transfer-Encoding 2537 o Content-Length 2539 o Trailer 2541 8.6. Transfer-Encoding 2543 The "Transfer-Encoding" header field indicates what transfer-codings 2544 (if any) have been applied to the message body. It differs from 2545 Content-Encoding (Section 2.2 of [Part3]) in that transfer-codings 2546 are a property of the message (and therefore are removed by 2547 intermediaries), whereas content-codings are not. 2549 Transfer-Encoding = 1#transfer-coding 2551 Transfer-codings are defined in Section 5.1. An example is: 2553 Transfer-Encoding: chunked 2555 If multiple encodings have been applied to a representation, the 2556 transfer-codings MUST be listed in the order in which they were 2557 applied. Additional information about the encoding parameters MAY be 2558 provided by other header fields not defined by this specification. 2560 Many older HTTP/1.0 applications do not understand the Transfer- 2561 Encoding header field. 2563 8.7. Upgrade 2565 The "Upgrade" header field allows the client to specify what 2566 additional communication protocols it would like to use, if the 2567 server chooses to switch protocols. Servers can use it to indicate 2568 what protocols they are willing to switch to. 2570 Upgrade = 1#product 2572 For example, 2574 Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11 2576 The Upgrade header field is intended to provide a simple mechanism 2577 for transition from HTTP/1.1 to some other, incompatible protocol. 2578 It does so by allowing the client to advertise its desire to use 2579 another protocol, such as a later version of HTTP with a higher major 2580 version number, even though the current request has been made using 2581 HTTP/1.1. This eases the difficult transition between incompatible 2582 protocols by allowing the client to initiate a request in the more 2583 commonly supported protocol while indicating to the server that it 2584 would like to use a "better" protocol if available (where "better" is 2585 determined by the server, possibly according to the nature of the 2586 request method or target resource). 2588 The Upgrade header field only applies to switching application-layer 2589 protocols upon the existing transport-layer connection. Upgrade 2590 cannot be used to insist on a protocol change; its acceptance and use 2591 by the server is optional. The capabilities and nature of the 2592 application-layer communication after the protocol change is entirely 2593 dependent upon the new protocol chosen, although the first action 2594 after changing the protocol MUST be a response to the initial HTTP 2595 request containing the Upgrade header field. 2597 The Upgrade header field only applies to the immediate connection. 2598 Therefore, the upgrade keyword MUST be supplied within a Connection 2599 header field (Section 8.1) whenever Upgrade is present in an HTTP/1.1 2600 message. 2602 The Upgrade header field cannot be used to indicate a switch to a 2603 protocol on a different connection. For that purpose, it is more 2604 appropriate to use a 3xx redirection response (Section 7.3 of 2605 [Part2]). 2607 Servers MUST include the "Upgrade" header field in 101 (Switching 2608 Protocols) responses to indicate which protocol(s) are being switched 2609 to, and MUST include it in 426 (Upgrade Required) responses to 2610 indicate acceptable protocols to upgrade to. Servers MAY include it 2611 in any other response to indicate that they are willing to upgrade to 2612 one of the specified protocols. 2614 This specification only defines the protocol name "HTTP" for use by 2615 the family of Hypertext Transfer Protocols, as defined by the HTTP 2616 version rules of Section 2.6 and future updates to this 2617 specification. Additional tokens can be registered with IANA using 2618 the registration procedure defined below. 2620 8.7.1. Upgrade Token Registry 2622 The HTTP Upgrade Token Registry defines the name space for product 2623 tokens used to identify protocols in the Upgrade header field. Each 2624 registered token is associated with contact information and an 2625 optional set of specifications that details how the connection will 2626 be processed after it has been upgraded. 2628 Registrations are allowed on a First Come First Served basis as 2629 described in Section 4.1 of [RFC5226]. The specifications need not 2630 be IETF documents or be subject to IESG review. Registrations are 2631 subject to the following rules: 2633 1. A token, once registered, stays registered forever. 2635 2. The registration MUST name a responsible party for the 2636 registration. 2638 3. The registration MUST name a point of contact. 2640 4. The registration MAY name a set of specifications associated with 2641 that token. Such specifications need not be publicly available. 2643 5. The responsible party MAY change the registration at any time. 2644 The IANA will keep a record of all such changes, and make them 2645 available upon request. 2647 6. The responsible party for the first registration of a "product" 2648 token MUST approve later registrations of a "version" token 2649 together with that "product" token before they can be registered. 2651 7. If absolutely required, the IESG MAY reassign the responsibility 2652 for a token. This will normally only be used in the case when a 2653 responsible party cannot be contacted. 2655 8.8. Via 2657 The "Via" header field MUST be sent by a proxy or gateway to indicate 2658 the intermediate protocols and recipients between the user agent and 2659 the server on requests, and between the origin server and the client 2660 on responses. It is analogous to the "Received" field used by email 2661 systems (Section 3.6.7 of [RFC5322]) and is intended to be used for 2662 tracking message forwards, avoiding request loops, and identifying 2663 the protocol capabilities of all senders along the request/response 2664 chain. 2666 Via = 1#( received-protocol RWS received-by 2667 [ RWS comment ] ) 2668 received-protocol = [ protocol-name "/" ] protocol-version 2669 protocol-name = token 2670 protocol-version = token 2671 received-by = ( uri-host [ ":" port ] ) / pseudonym 2672 pseudonym = token 2674 The received-protocol indicates the protocol version of the message 2675 received by the server or client along each segment of the request/ 2676 response chain. The received-protocol version is appended to the Via 2677 field value when the message is forwarded so that information about 2678 the protocol capabilities of upstream applications remains visible to 2679 all recipients. 2681 The protocol-name is excluded if and only if it would be "HTTP". The 2682 received-by field is normally the host and optional port number of a 2683 recipient server or client that subsequently forwarded the message. 2684 However, if the real host is considered to be sensitive information, 2685 it MAY be replaced by a pseudonym. If the port is not given, it MAY 2686 be assumed to be the default port of the received-protocol. 2688 Multiple Via field values represent each proxy or gateway that has 2689 forwarded the message. Each recipient MUST append its information 2690 such that the end result is ordered according to the sequence of 2691 forwarding applications. 2693 Comments MAY be used in the Via header field to identify the software 2694 of each recipient, analogous to the User-Agent and Server header 2695 fields. However, all comments in the Via field are optional and MAY 2696 be removed by any recipient prior to forwarding the message. 2698 For example, a request message could be sent from an HTTP/1.0 user 2699 agent to an internal proxy code-named "fred", which uses HTTP/1.1 to 2700 forward the request to a public proxy at p.example.net, which 2701 completes the request by forwarding it to the origin server at 2702 www.example.com. The request received by www.example.com would then 2703 have the following Via header field: 2705 Via: 1.0 fred, 1.1 p.example.net (Apache/1.1) 2707 A proxy or gateway used as a portal through a network firewall SHOULD 2708 NOT forward the names and ports of hosts within the firewall region 2709 unless it is explicitly enabled to do so. If not enabled, the 2710 received-by host of any host behind the firewall SHOULD be replaced 2711 by an appropriate pseudonym for that host. 2713 For organizations that have strong privacy requirements for hiding 2714 internal structures, a proxy or gateway MAY combine an ordered 2715 subsequence of Via header field entries with identical received- 2716 protocol values into a single such entry. For example, 2718 Via: 1.0 ricky, 1.1 ethel, 1.1 fred, 1.0 lucy 2720 could be collapsed to 2722 Via: 1.0 ricky, 1.1 mertz, 1.0 lucy 2724 Senders SHOULD NOT combine multiple entries unless they are all under 2725 the same organizational control and the hosts have already been 2726 replaced by pseudonyms. Senders MUST NOT combine entries which have 2727 different received-protocol values. 2729 9. IANA Considerations 2731 9.1. Header Field Registration 2733 The Message Header Field Registry located at shall be 2735 updated with the permanent registrations below (see [RFC3864]): 2737 +-------------------+----------+----------+-------------+ 2738 | Header Field Name | Protocol | Status | Reference | 2739 +-------------------+----------+----------+-------------+ 2740 | Connection | http | standard | Section 8.1 | 2741 | Content-Length | http | standard | Section 8.2 | 2742 | Host | http | standard | Section 8.3 | 2743 | TE | http | standard | Section 8.4 | 2744 | Trailer | http | standard | Section 8.5 | 2745 | Transfer-Encoding | http | standard | Section 8.6 | 2746 | Upgrade | http | standard | Section 8.7 | 2747 | Via | http | standard | Section 8.8 | 2748 +-------------------+----------+----------+-------------+ 2750 Furthermore, the header field name "Close" shall be registered as 2751 "reserved", as its use as HTTP header field would be in conflict with 2752 the use of the "close" connection option for the "Connection" header 2753 field (Section 8.1). 2755 +-------------------+----------+----------+-------------+ 2756 | Header Field Name | Protocol | Status | Reference | 2757 +-------------------+----------+----------+-------------+ 2758 | Close | http | reserved | Section 9.1 | 2759 +-------------------+----------+----------+-------------+ 2761 The change controller is: "IETF (iesg@ietf.org) - Internet 2762 Engineering Task Force". 2764 9.2. URI Scheme Registration 2766 The entries for the "http" and "https" URI Schemes in the registry 2767 located at shall 2768 be updated to point to Sections 2.7.1 and 2.7.2 of this document (see 2769 [RFC4395]). 2771 9.3. Internet Media Type Registrations 2773 This document serves as the specification for the Internet media 2774 types "message/http" and "application/http". The following is to be 2775 registered with IANA (see [RFC4288]). 2777 9.3.1. Internet Media Type message/http 2779 The message/http type can be used to enclose a single HTTP request or 2780 response message, provided that it obeys the MIME restrictions for 2781 all "message" types regarding line length and encodings. 2783 Type name: message 2785 Subtype name: http 2787 Required parameters: none 2789 Optional parameters: version, msgtype 2791 version: The HTTP-Version number of the enclosed message (e.g., 2792 "1.1"). If not present, the version can be determined from the 2793 first line of the body. 2795 msgtype: The message type -- "request" or "response". If not 2796 present, the type can be determined from the first line of the 2797 body. 2799 Encoding considerations: only "7bit", "8bit", or "binary" are 2800 permitted 2802 Security considerations: none 2804 Interoperability considerations: none 2806 Published specification: This specification (see Section 9.3.1). 2808 Applications that use this media type: 2810 Additional information: 2812 Magic number(s): none 2814 File extension(s): none 2816 Macintosh file type code(s): none 2818 Person and email address to contact for further information: See 2819 Authors Section. 2821 Intended usage: COMMON 2823 Restrictions on usage: none 2825 Author/Change controller: IESG 2827 9.3.2. Internet Media Type application/http 2829 The application/http type can be used to enclose a pipeline of one or 2830 more HTTP request or response messages (not intermixed). 2832 Type name: application 2834 Subtype name: http 2836 Required parameters: none 2838 Optional parameters: version, msgtype 2840 version: The HTTP-Version number of the enclosed messages (e.g., 2841 "1.1"). If not present, the version can be determined from the 2842 first line of the body. 2844 msgtype: The message type -- "request" or "response". If not 2845 present, the type can be determined from the first line of the 2846 body. 2848 Encoding considerations: HTTP messages enclosed by this type are in 2849 "binary" format; use of an appropriate Content-Transfer-Encoding 2850 is required when transmitted via E-mail. 2852 Security considerations: none 2854 Interoperability considerations: none 2856 Published specification: This specification (see Section 9.3.2). 2858 Applications that use this media type: 2860 Additional information: 2862 Magic number(s): none 2864 File extension(s): none 2866 Macintosh file type code(s): none 2868 Person and email address to contact for further information: See 2869 Authors Section. 2871 Intended usage: COMMON 2872 Restrictions on usage: none 2874 Author/Change controller: IESG 2876 9.4. Transfer Coding Registry 2878 The registration procedure for HTTP Transfer Codings is now defined 2879 by Section 5.1.3 of this document. 2881 The HTTP Transfer Codings Registry located at 2882 shall be updated 2883 with the registrations below: 2885 +----------+--------------------------------------+-----------------+ 2886 | Name | Description | Reference | 2887 +----------+--------------------------------------+-----------------+ 2888 | chunked | Transfer in a series of chunks | Section 5.1.1 | 2889 | compress | UNIX "compress" program method | Section 5.1.2.1 | 2890 | deflate | "deflate" compression mechanism | Section 5.1.2.2 | 2891 | | ([RFC1951]) used inside the "zlib" | | 2892 | | data format ([RFC1950]) | | 2893 | gzip | Same as GNU zip [RFC1952] | Section 5.1.2.3 | 2894 +----------+--------------------------------------+-----------------+ 2896 9.5. Upgrade Token Registration 2898 The registration procedure for HTTP Upgrade Tokens -- previously 2899 defined in Section 7.2 of [RFC2817] -- is now defined by 2900 Section 8.7.1 of this document. 2902 The HTTP Status Code Registry located at 2903 shall be 2904 updated with the registration below: 2906 +-------+---------------------------+-------------------------------+ 2907 | Value | Description | Reference | 2908 +-------+---------------------------+-------------------------------+ 2909 | HTTP | Hypertext Transfer | Section 2.6 of this | 2910 | | Protocol | specification | 2911 +-------+---------------------------+-------------------------------+ 2913 10. Security Considerations 2915 This section is meant to inform application developers, information 2916 providers, and users of the security limitations in HTTP/1.1 as 2917 described by this document. The discussion does not include 2918 definitive solutions to the problems revealed, though it does make 2919 some suggestions for reducing security risks. 2921 10.1. Personal Information 2923 HTTP clients are often privy to large amounts of personal information 2924 (e.g., the user's name, location, mail address, passwords, encryption 2925 keys, etc.), and SHOULD be very careful to prevent unintentional 2926 leakage of this information. We very strongly recommend that a 2927 convenient interface be provided for the user to control 2928 dissemination of such information, and that designers and 2929 implementors be particularly careful in this area. History shows 2930 that errors in this area often create serious security and/or privacy 2931 problems and generate highly adverse publicity for the implementor's 2932 company. 2934 10.2. Abuse of Server Log Information 2936 A server is in the position to save personal data about a user's 2937 requests which might identify their reading patterns or subjects of 2938 interest. This information is clearly confidential in nature and its 2939 handling can be constrained by law in certain countries. People 2940 using HTTP to provide data are responsible for ensuring that such 2941 material is not distributed without the permission of any individuals 2942 that are identifiable by the published results. 2944 10.3. Attacks Based On File and Path Names 2946 Implementations of HTTP origin servers SHOULD be careful to restrict 2947 the documents returned by HTTP requests to be only those that were 2948 intended by the server administrators. If an HTTP server translates 2949 HTTP URIs directly into file system calls, the server MUST take 2950 special care not to serve files that were not intended to be 2951 delivered to HTTP clients. For example, UNIX, Microsoft Windows, and 2952 other operating systems use ".." as a path component to indicate a 2953 directory level above the current one. On such a system, an HTTP 2954 server MUST disallow any such construct in the request-target if it 2955 would otherwise allow access to a resource outside those intended to 2956 be accessible via the HTTP server. Similarly, files intended for 2957 reference only internally to the server (such as access control 2958 files, configuration files, and script code) MUST be protected from 2959 inappropriate retrieval, since they might contain sensitive 2960 information. Experience has shown that minor bugs in such HTTP 2961 server implementations have turned into security risks. 2963 10.4. DNS-related Attacks 2965 HTTP clients rely heavily on the Domain Name Service (DNS), and are 2966 thus generally prone to security attacks based on the deliberate 2967 misassociation of IP addresses and DNS names not protected by DNSSec. 2968 Clients need to be cautious in assuming the validity of an IP number/ 2969 DNS name association unless the response is protected by DNSSec 2970 ([RFC4033]). 2972 10.5. Proxies and Caching 2974 By their very nature, HTTP proxies are men-in-the-middle, and 2975 represent an opportunity for man-in-the-middle attacks. Compromise 2976 of the systems on which the proxies run can result in serious 2977 security and privacy problems. Proxies have access to security- 2978 related information, personal information about individual users and 2979 organizations, and proprietary information belonging to users and 2980 content providers. A compromised proxy, or a proxy implemented or 2981 configured without regard to security and privacy considerations, 2982 might be used in the commission of a wide range of potential attacks. 2984 Proxy operators need to protect the systems on which proxies run as 2985 they would protect any system that contains or transports sensitive 2986 information. In particular, log information gathered at proxies 2987 often contains highly sensitive personal information, and/or 2988 information about organizations. Log information needs to be 2989 carefully guarded, and appropriate guidelines for use need to be 2990 developed and followed. (Section 10.2). 2992 Proxy implementors need to consider the privacy and security 2993 implications of their design and coding decisions, and of the 2994 configuration options they provide to proxy operators (especially the 2995 default configuration). 2997 Users of a proxy need to be aware that proxies are no trustworthier 2998 than the people who run them; HTTP itself cannot solve this problem. 3000 The judicious use of cryptography, when appropriate, might suffice to 3001 protect against a broad range of security and privacy attacks. Such 3002 cryptography is beyond the scope of the HTTP/1.1 specification. 3004 10.6. Protocol Element Size Overflows 3006 Because HTTP uses mostly textual, character-delimited fields, 3007 attackers can overflow buffers in implementations, and/or perform a 3008 Denial of Service against implementations that accept fields with 3009 unlimited lengths. 3011 To promote interoperability, this specification makes specific 3012 recommendations for size limits on request-targets (Section 3.1.1.2) 3013 and blocks of header fields (Section 3.2). These are minimum 3014 recommendations, chosen to be supportable even by implementations 3015 with limited resources; it is expected that most implementations will 3016 choose substantially higher limits. 3018 This specification also provides a way for servers to reject messages 3019 that have request-targets that are too long (Section 7.4.15 of 3020 [Part2]) or request entities that are too large (Section 7.4 of 3021 [Part2]). 3023 Other fields (including but not limited to request methods, response 3024 status phrases, header field-names, and body chunks) SHOULD be 3025 limited by implementations carefully, so as to not impede 3026 interoperability. 3028 10.7. Denial of Service Attacks on Proxies 3030 They exist. They are hard to defend against. Research continues. 3031 Beware. 3033 11. Acknowledgments 3035 This document revision builds on the work that went into RFC 2616 and 3036 its predecessors. See Section 16 of [RFC2616] for detailed 3037 acknowledgements. 3039 Since 1999, many contributors have helped by reporting bugs, asking 3040 smart questions, drafting and reviewing text, and discussing open 3041 issues: 3043 Adam Barth, Adam Roach, Addison Phillips, Adrian Chadd, Adrien de 3044 Croy, Alan Ford, Alan Ruttenberg, Albert Lunde, Alex Rousskov, Alexey 3045 Melnikov, Alisha Smith, Amichai Rothman, Amit Klein, Amos Jeffries, 3046 Andreas Maier, Andreas Petersson, Anne van Kesteren, Anthony Bryan, 3047 Asbjorn Ulsberg, Balachander Krishnamurthy, Barry Leiba, Ben Laurie, 3048 Benjamin Niven-Jenkins, Bil Corry, Bill Burke, Bjoern Hoehrmann, Bob 3049 Scheifler, Boris Zbarsky, Brett Slatkin, Brian Kell, Brian McBarron, 3050 Brian Pane, Brian Smith, Bryce Nesbitt, Carl Kugler, Charles Fry, 3051 Chris Newman, Cyrus Daboo, Dale Robert Anderson, Dan Winship, Daniel 3052 Stenberg, Dave Cridland, Dave Crocker, Dave Kristol, David Booth, 3053 David Singer, David W. Morris, Diwakar Shetty, Drummond Reed, Duane 3054 Wessels, Edward Lee, Eliot Lear, Eran Hammer-Lahav, Eric D. Williams, 3055 Eric J. Bowman, Eric Lawrence, Erik Aronesty, Florian Weimer, Frank 3056 Ellermann, Fred Bohle, Geoffrey Sneddon, Gervase Markham, Greg 3057 Wilkins, Harald Tveit Alvestrand, Harry Halpin, Helge Hess, Henrik 3058 Nordstrom, Henry S. Thompson, Henry Story, Howard Melman, Hugo Haas, 3059 Ian Hickson, Ingo Struck, J. Ross Nicoll, James H. Manger, James 3060 Lacey, James M. Snell, Jamie Lokier, Jan Algermissen, Jeff Hodges 3061 (for coming up with the term 'effective Request-URI'), Jeff Walden, 3062 Jim Luther, Joe D. Williams, Joe Gregorio, Joe Orton, John C. 3063 Klensin, John C. Mallery, John Cowan, John Kemp, John Panzer, John 3064 Schneider, John Stracke, Jonas Sicking, Jonathan Moore, Jonathan 3065 Rees, Jordi Ros, Joris Dobbelsteen, Josh Cohen, Julien Pierre, 3066 Jungshik Shin, Justin Chapweske, Justin Erenkrantz, Justin James, 3067 Kalvinder Singh, Karl Dubost, Keith Hoffman, Keith Moore, Koen 3068 Holtman, Konstantin Voronkov, Kris Zyp, Lisa Dusseault, Maciej 3069 Stachowiak, Marc Schneider, Marc Slemko, Mark Baker, Mark Nottingham 3070 (Working Group chair), Mark Pauley, Martin J. Duerst, Martin Thomson, 3071 Matt Lynch, Matthew Cox, Max Clark, Michael Burrows, Michael 3072 Hausenblas, Mike Amundsen, Mike Kelly, Mike Schinkel, Miles Sabin, 3073 Mykyta Yevstifeyev, Nathan Rixham, Nicholas Shanks, Nico Williams, 3074 Nicolas Alvarez, Noah Slater, Pablo Castro, Pat Hayes, Patrick R. 3075 McManus, Paul E. Jones, Paul Hoffman, Paul Marquess, Peter Saint- 3076 Andre, Peter Watkins, Phil Archer, Phillip Hallam-Baker, Poul-Henning 3077 Kamp, Preethi Natarajan, Reto Bachmann-Gmuer, Richard Cyganiak, 3078 Robert Brewer, Robert Collins, Robert O'Callahan, Robert Olofsson, 3079 Robert Sayre, Robert Siemer, Robert de Wilde, Roberto Javier Godoy, 3080 Ronny Widjaja, S. Mike Dierken, Salvatore Loreto, Sam Johnston, Sam 3081 Ruby, Scott Lawrence (for maintaining the original issues list), Sean 3082 B. Palmer, Shane McCarron, Stefan Eissing, Stefan Tilkov, Stefanos 3083 Harhalakis, Stephane Bortzmeyer, Stuart Williams, Subbu Allamaraju, 3084 Sylvain Hellegouarch, Tapan Divekar, Thomas Broyer, Thomas Nordin, 3085 Thomas Roessler, Tim Morgan, Tim Olsen, Travis Snoozy, Tyler Close, 3086 Vincent Murphy, Wenbo Zhu, Werner Baumann, Wilbur Streett, Wilfredo 3087 Sanchez Vega, William A. Rowe Jr., William Chan, Willy Tarreau, 3088 Xiaoshu Wang, Yaron Goland, Yngve Nysaeter Pettersen, Yogesh Bang, 3089 Yutaka Oiwa, and Zed A. Shaw. 3091 12. References 3093 12.1. Normative References 3095 [ISO-8859-1] International Organization for Standardization, 3096 "Information technology -- 8-bit single-byte coded 3097 graphic character sets -- Part 1: Latin alphabet No. 3098 1", ISO/IEC 8859-1:1998, 1998. 3100 [Part2] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., 3101 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., 3102 Ed., and J. Reschke, Ed., "HTTP/1.1, part 2: Message 3103 Semantics", draft-ietf-httpbis-p2-semantics-17 (work in 3104 progress), October 2011. 3106 [Part3] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., 3107 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., 3108 Ed., and J. Reschke, Ed., "HTTP/1.1, part 3: Message 3109 Payload and Content Negotiation", 3110 draft-ietf-httpbis-p3-payload-17 (work in progress), 3111 October 2011. 3113 [Part6] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., 3114 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., 3115 Ed., Nottingham, M., Ed., and J. Reschke, Ed., 3116 "HTTP/1.1, part 6: Caching", 3117 draft-ietf-httpbis-p6-cache-17 (work in progress), 3118 October 2011. 3120 [RFC1950] Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data 3121 Format Specification version 3.3", RFC 1950, May 1996. 3123 RFC 1950 is an Informational RFC, thus it might be less 3124 stable than this specification. On the other hand, 3125 this downward reference was present since the 3126 publication of RFC 2068 in 1997, therefore it is 3127 unlikely to cause problems in practice. See also 3128 [BCP97]. 3130 [RFC1951] Deutsch, P., "DEFLATE Compressed Data Format 3131 Specification version 1.3", RFC 1951, May 1996. 3133 RFC 1951 is an Informational RFC, thus it might be less 3134 stable than this specification. On the other hand, 3135 this downward reference was present since the 3136 publication of RFC 2068 in 1997, therefore it is 3137 unlikely to cause problems in practice. See also 3138 [BCP97]. 3140 [RFC1952] Deutsch, P., Gailly, J-L., Adler, M., Deutsch, L., and 3141 G. Randers-Pehrson, "GZIP file format specification 3142 version 4.3", RFC 1952, May 1996. 3144 RFC 1952 is an Informational RFC, thus it might be less 3145 stable than this specification. On the other hand, 3146 this downward reference was present since the 3147 publication of RFC 2068 in 1997, therefore it is 3148 unlikely to cause problems in practice. See also 3149 [BCP97]. 3151 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3152 Requirement Levels", BCP 14, RFC 2119, March 1997. 3154 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, 3155 "Uniform Resource Identifier (URI): Generic Syntax", 3156 STD 66, RFC 3986, January 2005. 3158 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for 3159 Syntax Specifications: ABNF", STD 68, RFC 5234, 3160 January 2008. 3162 [USASCII] American National Standards Institute, "Coded Character 3163 Set -- 7-bit American Standard Code for Information 3164 Interchange", ANSI X3.4, 1986. 3166 12.2. Informative References 3168 [BCP97] Klensin, J. and S. Hartman, "Handling Normative 3169 References to Standards-Track Documents", BCP 97, 3170 RFC 4897, June 2007. 3172 [Kri2001] Kristol, D., "HTTP Cookies: Standards, Privacy, and 3173 Politics", ACM Transactions on Internet Technology Vol. 3174 1, #2, November 2001, 3175 . 3177 [Nie1997] Frystyk, H., Gettys, J., Prud'hommeaux, E., Lie, H., 3178 and C. Lilley, "Network Performance Effects of 3179 HTTP/1.1, CSS1, and PNG", ACM Proceedings of the ACM 3180 SIGCOMM '97 conference on Applications, technologies, 3181 architectures, and protocols for computer communication 3182 SIGCOMM '97, September 1997, 3183 . 3185 [Pad1995] Padmanabhan, V. and J. Mogul, "Improving HTTP Latency", 3186 Computer Networks and ISDN Systems v. 28, pp. 25-35, 3187 December 1995, 3188 . 3190 [RFC1919] Chatel, M., "Classical versus Transparent IP Proxies", 3191 RFC 1919, March 1996. 3193 [RFC1945] Berners-Lee, T., Fielding, R., and H. Nielsen, 3194 "Hypertext Transfer Protocol -- HTTP/1.0", RFC 1945, 3195 May 1996. 3197 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet 3198 Mail Extensions (MIME) Part One: Format of Internet 3199 Message Bodies", RFC 2045, November 1996. 3201 [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail 3202 Extensions) Part Three: Message Header Extensions for 3203 Non-ASCII Text", RFC 2047, November 1996. 3205 [RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and 3206 T. Berners-Lee, "Hypertext Transfer Protocol -- 3207 HTTP/1.1", RFC 2068, January 1997. 3209 [RFC2145] Mogul, J., Fielding, R., Gettys, J., and H. Nielsen, 3210 "Use and Interpretation of HTTP Version Numbers", 3211 RFC 2145, May 1997. 3213 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 3214 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 3215 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 3217 [RFC2817] Khare, R. and S. Lawrence, "Upgrading to TLS Within 3218 HTTP/1.1", RFC 2817, May 2000. 3220 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 3222 [RFC2965] Kristol, D. and L. Montulli, "HTTP State Management 3223 Mechanism", RFC 2965, October 2000. 3225 [RFC3040] Cooper, I., Melve, I., and G. Tomlinson, "Internet Web 3226 Replication and Caching Taxonomy", RFC 3040, 3227 January 2001. 3229 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration 3230 Procedures for Message Header Fields", BCP 90, 3231 RFC 3864, September 2004. 3233 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 3234 Rose, "DNS Security Introduction and Requirements", 3235 RFC 4033, March 2005. 3237 [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications 3238 and Registration Procedures", BCP 13, RFC 4288, 3239 December 2005. 3241 [RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines 3242 and Registration Procedures for New URI Schemes", 3243 BCP 115, RFC 4395, February 2006. 3245 [RFC4559] Jaganathan, K., Zhu, L., and J. Brezak, "SPNEGO-based 3246 Kerberos and NTLM HTTP Authentication in Microsoft 3247 Windows", RFC 4559, June 2006. 3249 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing 3250 an IANA Considerations Section in RFCs", BCP 26, 3251 RFC 5226, May 2008. 3253 [RFC5322] Resnick, P., "Internet Message Format", RFC 5322, 3254 October 2008. 3256 [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, 3257 April 2011. 3259 [Spe] Spero, S., "Analysis of HTTP Performance Problems", 3260 . 3262 [Tou1998] Touch, J., Heidemann, J., and K. Obraczka, "Analysis of 3263 HTTP Performance", ISI Research Report ISI/RR-98-463, 3264 Aug 1998, . 3266 (original report dated Aug. 1996) 3268 Appendix A. HTTP Version History 3270 HTTP has been in use by the World-Wide Web global information 3271 initiative since 1990. The first version of HTTP, later referred to 3272 as HTTP/0.9, was a simple protocol for hypertext data transfer across 3273 the Internet with only a single request method (GET) and no metadata. 3274 HTTP/1.0, as defined by [RFC1945], added a range of request methods 3275 and MIME-like messaging that could include metadata about the data 3276 transferred and modifiers on the request/response semantics. 3277 However, HTTP/1.0 did not sufficiently take into consideration the 3278 effects of hierarchical proxies, caching, the need for persistent 3279 connections, or name-based virtual hosts. The proliferation of 3280 incompletely-implemented applications calling themselves "HTTP/1.0" 3281 further necessitated a protocol version change in order for two 3282 communicating applications to determine each other's true 3283 capabilities. 3285 HTTP/1.1 remains compatible with HTTP/1.0 by including more stringent 3286 requirements that enable reliable implementations, adding only those 3287 new features that will either be safely ignored by an HTTP/1.0 3288 recipient or only sent when communicating with a party advertising 3289 compliance with HTTP/1.1. 3291 It is beyond the scope of a protocol specification to mandate 3292 compliance with previous versions. HTTP/1.1 was deliberately 3293 designed, however, to make supporting previous versions easy. We 3294 would expect a general-purpose HTTP/1.1 server to understand any 3295 valid request in the format of HTTP/1.0 and respond appropriately 3296 with an HTTP/1.1 message that only uses features understood (or 3297 safely ignored) by HTTP/1.0 clients. Likewise, would expect an 3298 HTTP/1.1 client to understand any valid HTTP/1.0 response. 3300 Since HTTP/0.9 did not support header fields in a request, there is 3301 no mechanism for it to support name-based virtual hosts (selection of 3302 resource by inspection of the Host header field). Any server that 3303 implements name-based virtual hosts ought to disable support for 3304 HTTP/0.9. Most requests that appear to be HTTP/0.9 are, in fact, 3305 badly constructed HTTP/1.x requests wherein a buggy client failed to 3306 properly encode linear whitespace found in a URI reference and placed 3307 in the request-target. 3309 A.1. Changes from HTTP/1.0 3311 This section summarizes major differences between versions HTTP/1.0 3312 and HTTP/1.1. 3314 A.1.1. Multi-homed Web Servers 3316 The requirements that clients and servers support the Host header 3317 field (Section 8.3), report an error if it is missing from an 3318 HTTP/1.1 request, and accept absolute URIs (Section 3.1.1.2) are 3319 among the most important changes defined by HTTP/1.1. 3321 Older HTTP/1.0 clients assumed a one-to-one relationship of IP 3322 addresses and servers; there was no other established mechanism for 3323 distinguishing the intended server of a request than the IP address 3324 to which that request was directed. The Host header field was 3325 introduced during the development of HTTP/1.1 and, though it was 3326 quickly implemented by most HTTP/1.0 browsers, additional 3327 requirements were placed on all HTTP/1.1 requests in order to ensure 3328 complete adoption. At the time of this writing, most HTTP-based 3329 services are dependent upon the Host header field for targeting 3330 requests. 3332 A.1.2. Keep-Alive Connections 3334 For most implementations of HTTP/1.0, each connection is established 3335 by the client prior to the request and closed by the server after 3336 sending the response. However, some implementations implement the 3337 Keep-Alive version of persistent connections described in Section 3338 19.7.1 of [RFC2068]. 3340 Some clients and servers might wish to be compatible with some 3341 previous implementations of persistent connections in HTTP/1.0 3342 clients and servers. Persistent connections in HTTP/1.0 are 3343 explicitly negotiated as they are not the default behavior. HTTP/1.0 3344 experimental implementations of persistent connections are faulty, 3345 and the new facilities in HTTP/1.1 are designed to rectify these 3346 problems. The problem was that some existing HTTP/1.0 clients might 3347 send Keep-Alive to a proxy server that doesn't understand Connection, 3348 which would then erroneously forward it to the next inbound server, 3349 which would establish the Keep-Alive connection and result in a hung 3350 HTTP/1.0 proxy waiting for the close on the response. The result is 3351 that HTTP/1.0 clients must be prevented from using Keep-Alive when 3352 talking to proxies. 3354 However, talking to proxies is the most important use of persistent 3355 connections, so that prohibition is clearly unacceptable. Therefore, 3356 we need some other mechanism for indicating a persistent connection 3357 is desired, which is safe to use even when talking to an old proxy 3358 that ignores Connection. Persistent connections are the default for 3359 HTTP/1.1 messages; we introduce a new keyword (Connection: close) for 3360 declaring non-persistence. See Section 8.1. 3362 A.2. Changes from RFC 2616 3364 Empty list elements in list productions have been deprecated. 3365 (Section 1.2.1) 3367 Rules about implicit linear whitespace between certain grammar 3368 productions have been removed; now it's only allowed when 3369 specifically pointed out in the ABNF. (Section 1.2.2) 3371 Clarify that the string "HTTP" in the HTTP-Version ABFN production is 3372 case sensitive. Restrict the version numbers to be single digits due 3373 to the fact that implementations are known to handle multi-digit 3374 version numbers incorrectly. (Section 2.6) 3376 Require that invalid whitespace around field-names be rejected. 3377 (Section 3.2) 3379 The NUL octet is no longer allowed in comment and quoted-string text. 3380 The quoted-pair rule no longer allows escaping control characters 3381 other than HTAB. Non-ASCII content in header fields and reason 3382 phrase has been obsoleted and made opaque (the TEXT rule was 3383 removed). (Section 3.2.3) 3385 Require recipients to handle bogus Content-Length header fields as 3386 errors. (Section 3.3) 3388 Remove reference to non-existent identity transfer-coding value 3389 tokens. (Sections 3.3 and 5.1) 3391 Update use of abs_path production from RFC 1808 to the path-absolute 3392 + query components of RFC 3986. State that the asterisk form is 3393 allowed for the OPTIONS request method only. (Section 3.1.1.2) 3395 Clarification that the chunk length does not include the count of the 3396 octets in the chunk header and trailer. Furthermore disallowed line 3397 folding in chunk extensions. (Section 5.1.1) 3399 Remove hard limit of two connections per server. Remove requirement 3400 to retry a sequence of requests as long it was idempotent. Remove 3401 requirements about when servers are allowed to close connections 3402 prematurely. (Section 6.1.4) 3403 Remove requirement to retry requests under certain cirumstances when 3404 the server prematurely closes the connection. (Section 6.2) 3406 Change ABNF productions for header fields to only define the field 3407 value. (Section 8) 3409 Clarify exactly when close connection options must be sent. 3410 (Section 8.1) 3412 Define the semantics of the "Upgrade" header field in responses other 3413 than 101 (this was incorporated from [RFC2817]). (Section 8.7) 3415 Appendix B. Collected ABNF 3417 BWS = OWS 3419 Chunked-Body = *chunk last-chunk trailer-part CRLF 3420 Connection = *( "," OWS ) connection-token *( OWS "," [ OWS 3421 connection-token ] ) 3422 Content-Length = 1*DIGIT 3424 HTTP-Prot-Name = %x48.54.54.50 ; HTTP 3425 HTTP-Version = HTTP-Prot-Name "/" DIGIT "." DIGIT 3426 HTTP-message = start-line *( header-field CRLF ) CRLF [ message-body 3427 ] 3428 Host = uri-host [ ":" port ] 3430 Method = token 3432 OWS = *( SP / HTAB / obs-fold ) 3434 RWS = 1*( SP / HTAB / obs-fold ) 3435 Reason-Phrase = *( HTAB / SP / VCHAR / obs-text ) 3436 Request-Line = Method SP request-target SP HTTP-Version CRLF 3438 Status-Code = 3DIGIT 3439 Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF 3441 TE = [ ( "," / t-codings ) *( OWS "," [ OWS t-codings ] ) ] 3442 Trailer = *( "," OWS ) field-name *( OWS "," [ OWS field-name ] ) 3443 Transfer-Encoding = *( "," OWS ) transfer-coding *( OWS "," [ OWS 3444 transfer-coding ] ) 3446 URI-reference = 3447 Upgrade = *( "," OWS ) product *( OWS "," [ OWS product ] ) 3448 Via = *( "," OWS ) received-protocol RWS received-by [ RWS comment ] 3449 *( OWS "," [ OWS received-protocol RWS received-by [ RWS comment ] ] 3450 ) 3452 absolute-URI = 3453 attribute = token 3454 authority = 3456 chunk = chunk-size [ chunk-ext ] CRLF chunk-data CRLF 3457 chunk-data = 1*OCTET 3458 chunk-ext = *( ";" chunk-ext-name [ "=" chunk-ext-val ] ) 3459 chunk-ext-name = token 3460 chunk-ext-val = token / quoted-str-nf 3461 chunk-size = 1*HEXDIG 3462 comment = "(" *( ctext / quoted-cpair / comment ) ")" 3463 connection-token = token 3464 ctext = OWS / %x21-27 ; '!'-''' 3465 / %x2A-5B ; '*'-'[' 3466 / %x5D-7E ; ']'-'~' 3467 / obs-text 3469 field-content = *( HTAB / SP / VCHAR / obs-text ) 3470 field-name = token 3471 field-value = *( field-content / obs-fold ) 3473 header-field = field-name ":" OWS field-value BWS 3474 http-URI = "http://" authority path-abempty [ "?" query ] 3475 https-URI = "https://" authority path-abempty [ "?" query ] 3477 last-chunk = 1*"0" [ chunk-ext ] CRLF 3479 message-body = *OCTET 3481 obs-fold = CRLF ( SP / HTAB ) 3482 obs-text = %x80-FF 3484 partial-URI = relative-part [ "?" query ] 3485 path-abempty = 3486 path-absolute = 3487 port = 3488 product = token [ "/" product-version ] 3489 product-version = token 3490 protocol-name = token 3491 protocol-version = token 3492 pseudonym = token 3493 qdtext = OWS / "!" / %x23-5B ; '#'-'[' 3494 / %x5D-7E ; ']'-'~' 3495 / obs-text 3496 qdtext-nf = HTAB / SP / "!" / %x23-5B ; '#'-'[' 3497 / %x5D-7E ; ']'-'~' 3498 / obs-text 3499 query = 3500 quoted-cpair = "\" ( HTAB / SP / VCHAR / obs-text ) 3501 quoted-pair = "\" ( HTAB / SP / VCHAR / obs-text ) 3502 quoted-str-nf = DQUOTE *( qdtext-nf / quoted-pair ) DQUOTE 3503 quoted-string = DQUOTE *( qdtext / quoted-pair ) DQUOTE 3504 qvalue = ( "0" [ "." *3DIGIT ] ) / ( "1" [ "." *3"0" ] ) 3506 received-by = ( uri-host [ ":" port ] ) / pseudonym 3507 received-protocol = [ protocol-name "/" ] protocol-version 3508 relative-part = 3509 request-target = "*" / absolute-URI / ( path-absolute [ "?" query ] ) 3510 / authority 3512 special = "(" / ")" / "<" / ">" / "@" / "," / ";" / ":" / "\" / 3513 DQUOTE / "/" / "[" / "]" / "?" / "=" / "{" / "}" 3514 start-line = Request-Line / Status-Line 3516 t-codings = "trailers" / ( transfer-extension [ te-params ] ) 3517 tchar = "!" / "#" / "$" / "%" / "&" / "'" / "*" / "+" / "-" / "." / 3518 "^" / "_" / "`" / "|" / "~" / DIGIT / ALPHA 3519 te-ext = OWS ";" OWS token [ "=" word ] 3520 te-params = OWS ";" OWS "q=" qvalue *te-ext 3521 token = 1*tchar 3522 trailer-part = *( header-field CRLF ) 3523 transfer-coding = "chunked" / "compress" / "deflate" / "gzip" / 3524 transfer-extension 3525 transfer-extension = token *( OWS ";" OWS transfer-parameter ) 3526 transfer-parameter = attribute BWS "=" BWS value 3528 uri-host = 3530 value = word 3532 word = token / quoted-string 3533 ABNF diagnostics: 3535 ; Chunked-Body defined but not used 3536 ; Connection defined but not used 3537 ; Content-Length defined but not used 3538 ; HTTP-message defined but not used 3539 ; Host defined but not used 3540 ; TE defined but not used 3541 ; Trailer defined but not used 3542 ; Transfer-Encoding defined but not used 3543 ; URI-reference defined but not used 3544 ; Upgrade defined but not used 3545 ; Via defined but not used 3546 ; http-URI defined but not used 3547 ; https-URI defined but not used 3548 ; partial-URI defined but not used 3549 ; special defined but not used 3551 Appendix C. Change Log (to be removed by RFC Editor before publication) 3553 C.1. Since RFC 2616 3555 Extracted relevant partitions from [RFC2616]. 3557 C.2. Since draft-ietf-httpbis-p1-messaging-00 3559 Closed issues: 3561 o : "HTTP Version 3562 should be case sensitive" 3563 () 3565 o : "'unsafe' 3566 characters" () 3568 o : "Chunk Size 3569 Definition" () 3571 o : "Message Length" 3572 () 3574 o : "Media Type 3575 Registrations" () 3577 o : "URI includes 3578 query" () 3580 o : "No close on 3581 1xx responses" () 3583 o : "Remove 3584 'identity' token references" 3585 () 3587 o : "Import query 3588 BNF" 3590 o : "qdtext BNF" 3592 o : "Normative and 3593 Informative references" 3595 o : "RFC2606 3596 Compliance" 3598 o : "RFC977 3599 reference" 3601 o : "RFC1700 3602 references" 3604 o : "inconsistency 3605 in date format explanation" 3607 o : "Date reference 3608 typo" 3610 o : "Informative 3611 references" 3613 o : "ISO-8859-1 3614 Reference" 3616 o : "Normative up- 3617 to-date references" 3619 Other changes: 3621 o Update media type registrations to use RFC4288 template. 3623 o Use names of RFC4234 core rules DQUOTE and HTAB, fix broken ABNF 3624 for chunk-data (work in progress on 3625 ) 3627 C.3. Since draft-ietf-httpbis-p1-messaging-01 3629 Closed issues: 3631 o : "Bodies on GET 3632 (and other) requests" 3634 o : "Updating to 3635 RFC4288" 3637 o : "Status Code 3638 and Reason Phrase" 3640 o : "rel_path not 3641 used" 3643 Ongoing work on ABNF conversion 3644 (): 3646 o Get rid of duplicate BNF rule names ("host" -> "uri-host", 3647 "trailer" -> "trailer-part"). 3649 o Avoid underscore character in rule names ("http_URL" -> "http- 3650 URL", "abs_path" -> "path-absolute"). 3652 o Add rules for terms imported from URI spec ("absoluteURI", 3653 "authority", "path-absolute", "port", "query", "relativeURI", 3654 "host) -- these will have to be updated when switching over to 3655 RFC3986. 3657 o Synchronize core rules with RFC5234. 3659 o Get rid of prose rules that span multiple lines. 3661 o Get rid of unused rules LOALPHA and UPALPHA. 3663 o Move "Product Tokens" section (back) into Part 1, as "token" is 3664 used in the definition of the Upgrade header field. 3666 o Add explicit references to BNF syntax and rules imported from 3667 other parts of the specification. 3669 o Rewrite prose rule "token" in terms of "tchar", rewrite prose rule 3670 "TEXT". 3672 C.4. Since draft-ietf-httpbis-p1-messaging-02 3674 Closed issues: 3676 o : "HTTP-date vs. 3677 rfc1123-date" 3679 o : "WS in quoted- 3680 pair" 3682 Ongoing work on IANA Message Header Field Registration 3683 (): 3685 o Reference RFC 3984, and update header field registrations for 3686 headers defined in this document. 3688 Ongoing work on ABNF conversion 3689 (): 3691 o Replace string literals when the string really is case-sensitive 3692 (HTTP-Version). 3694 C.5. Since draft-ietf-httpbis-p1-messaging-03 3696 Closed issues: 3698 o : "Connection 3699 closing" 3701 o : "Move 3702 registrations and registry information to IANA Considerations" 3704 o : "need new URL 3705 for PAD1995 reference" 3707 o : "IANA 3708 Considerations: update HTTP URI scheme registration" 3710 o : "Cite HTTPS 3711 URI scheme definition" 3713 o : "List-type 3714 headers vs Set-Cookie" 3716 Ongoing work on ABNF conversion 3717 (): 3719 o Replace string literals when the string really is case-sensitive 3720 (HTTP-Date). 3722 o Replace HEX by HEXDIG for future consistence with RFC 5234's core 3723 rules. 3725 C.6. Since draft-ietf-httpbis-p1-messaging-04 3727 Closed issues: 3729 o : "Out-of-date 3730 reference for URIs" 3732 o : "RFC 2822 is 3733 updated by RFC 5322" 3735 Ongoing work on ABNF conversion 3736 (): 3738 o Use "/" instead of "|" for alternatives. 3740 o Get rid of RFC822 dependency; use RFC5234 plus extensions instead. 3742 o Only reference RFC 5234's core rules. 3744 o Introduce new ABNF rules for "bad" whitespace ("BWS"), optional 3745 whitespace ("OWS") and required whitespace ("RWS"). 3747 o Rewrite ABNFs to spell out whitespace rules, factor out header 3748 field value format definitions. 3750 C.7. Since draft-ietf-httpbis-p1-messaging-05 3752 Closed issues: 3754 o : "Header LWS" 3756 o : "Sort 1.3 3757 Terminology" 3759 o : "RFC2047 3760 encoded words" 3762 o : "Character 3763 Encodings in TEXT" 3765 o : "Line Folding" 3766 o : "OPTIONS * and 3767 proxies" 3769 o : "Reason-Phrase 3770 BNF" 3772 o : "Use of TEXT" 3774 o : "Join 3775 "Differences Between HTTP Entities and RFC 2045 Entities"?" 3777 o : "RFC822 3778 reference left in discussion of date formats" 3780 Final work on ABNF conversion 3781 (): 3783 o Rewrite definition of list rules, deprecate empty list elements. 3785 o Add appendix containing collected and expanded ABNF. 3787 Other changes: 3789 o Rewrite introduction; add mostly new Architecture Section. 3791 o Move definition of quality values from Part 3 into Part 1; make TE 3792 request header field grammar independent of accept-params (defined 3793 in Part 3). 3795 C.8. Since draft-ietf-httpbis-p1-messaging-06 3797 Closed issues: 3799 o : "base for 3800 numeric protocol elements" 3802 o : "comment ABNF" 3804 Partly resolved issues: 3806 o : "205 Bodies" 3807 (took out language that implied that there might be methods for 3808 which a request body MUST NOT be included) 3810 o : "editorial 3811 improvements around HTTP-date" 3813 C.9. Since draft-ietf-httpbis-p1-messaging-07 3815 Closed issues: 3817 o : "Repeating 3818 single-value headers" 3820 o : "increase 3821 connection limit" 3823 o : "IP addresses 3824 in URLs" 3826 o : "take over 3827 HTTP Upgrade Token Registry" 3829 o : "CR and LF in 3830 chunk extension values" 3832 o : "HTTP/0.9 3833 support" 3835 o : "pick IANA 3836 policy (RFC5226) for Transfer Coding / Content Coding" 3838 o : "move 3839 definitions of gzip/deflate/compress to part 1" 3841 o : "disallow 3842 control characters in quoted-pair" 3844 Partly resolved issues: 3846 o : "update IANA 3847 requirements wrt Transfer-Coding values" (add the IANA 3848 Considerations subsection) 3850 C.10. Since draft-ietf-httpbis-p1-messaging-08 3852 Closed issues: 3854 o : "header 3855 parsing, treatment of leading and trailing OWS" 3857 Partly resolved issues: 3859 o : "Placement of 3860 13.5.1 and 13.5.2" 3862 o : "use of term 3863 "word" when talking about header structure" 3865 C.11. Since draft-ietf-httpbis-p1-messaging-09 3867 Closed issues: 3869 o : "Clarification 3870 of the term 'deflate'" 3872 o : "OPTIONS * and 3873 proxies" 3875 o : "MIME-Version 3876 not listed in P1, general header fields" 3878 o : "IANA registry 3879 for content/transfer encodings" 3881 o : "Case- 3882 sensitivity of HTTP-date" 3884 o : "use of term 3885 "word" when talking about header structure" 3887 Partly resolved issues: 3889 o : "Term for the 3890 requested resource's URI" 3892 C.12. Since draft-ietf-httpbis-p1-messaging-10 3894 Closed issues: 3896 o : "Connection 3897 Closing" 3899 o : "Delimiting 3900 messages with multipart/byteranges" 3902 o : "Handling 3903 multiple Content-Length headers" 3905 o : "Clarify 3906 entity / representation / variant terminology" 3908 o : "consider 3909 removing the 'changes from 2068' sections" 3911 Partly resolved issues: 3913 o : "HTTP(s) URI 3914 scheme definitions" 3916 C.13. Since draft-ietf-httpbis-p1-messaging-11 3918 Closed issues: 3920 o : "Trailer 3921 requirements" 3923 o : "Text about 3924 clock requirement for caches belongs in p6" 3926 o : "effective 3927 request URI: handling of missing host in HTTP/1.0" 3929 o : "confusing 3930 Date requirements for clients" 3932 Partly resolved issues: 3934 o : "Handling 3935 multiple Content-Length headers" 3937 C.14. Since draft-ietf-httpbis-p1-messaging-12 3939 Closed issues: 3941 o : "RFC2145 3942 Normative" 3944 o : "HTTP(s) URI 3945 scheme definitions" (tune the requirements on userinfo) 3947 o : "define 3948 'transparent' proxy" 3950 o : "Header 3951 Classification" 3953 o : "Is * usable 3954 as a request-uri for new methods?" 3956 o : "Migrate 3957 Upgrade details from RFC2817" 3959 o : "untangle 3960 ABNFs for header fields" 3962 o : "update RFC 3963 2109 reference" 3965 C.15. Since draft-ietf-httpbis-p1-messaging-13 3967 Closed issues: 3969 o : "Allow is not 3970 in 13.5.2" 3972 o : "Handling 3973 multiple Content-Length headers" 3975 o : "untangle 3976 ABNFs for header fields" 3978 o : "Content- 3979 Length ABNF broken" 3981 C.16. Since draft-ietf-httpbis-p1-messaging-14 3983 Closed issues: 3985 o : "HTTP-Version 3986 should be redefined as fixed length pair of DIGIT . DIGIT" 3988 o : "Recommend 3989 minimum sizes for protocol elements" 3991 o : "Set 3992 expectations around buffering" 3994 o : "Considering 3995 messages in isolation" 3997 C.17. Since draft-ietf-httpbis-p1-messaging-15 3999 Closed issues: 4001 o : "DNS Spoofing 4002 / DNS Binding advice" 4004 o : "move RFCs 4005 2145, 2616, 2817 to Historic status" 4007 o : "\-escaping in 4008 quoted strings" 4010 o : "'Close' 4011 should be reserved in the HTTP header field registry" 4013 C.18. Since draft-ietf-httpbis-p1-messaging-16 4015 Closed issues: 4017 o : "Document 4018 HTTP's error-handling philosophy" 4020 o : "Explain 4021 header registration" 4023 o : "Revise 4024 Acknowledgements Sections" 4026 o : "Retrying 4027 Requests" 4029 o : "Closing the 4030 connection on server error" 4032 Index 4034 A 4035 absolute-URI form (of request-target) 31 4036 accelerator 13 4037 application/http Media Type 61 4038 asterisk form (of request-target) 31 4039 authority form (of request-target) 32 4041 B 4042 browser 10 4044 C 4045 cache 14 4046 cacheable 15 4047 captive portal 14 4048 chunked (Coding Format) 36 4049 client 10 4050 Coding Format 4051 chunked 36 4052 compress 38 4053 deflate 38 4054 gzip 39 4056 compress (Coding Format) 38 4057 connection 10 4058 Connection header field 49 4059 Content-Length header field 51 4061 D 4062 deflate (Coding Format) 38 4063 downstream 13 4065 E 4066 effective request URI 34 4068 G 4069 gateway 13 4070 Grammar 4071 absolute-URI 17 4072 ALPHA 7 4073 attribute 35 4074 authority 17 4075 BWS 9 4076 chunk 36 4077 chunk-data 36 4078 chunk-ext 36 4079 chunk-ext-name 36 4080 chunk-ext-val 36 4081 chunk-size 36 4082 Chunked-Body 36 4083 comment 26 4084 Connection 50 4085 connection-token 50 4086 Content-Length 51 4087 CR 7 4088 CRLF 7 4089 ctext 26 4090 CTL 7 4091 date2 35 4092 date3 35 4093 DIGIT 7 4094 DQUOTE 7 4095 field-content 23 4096 field-name 23 4097 field-value 23 4098 header-field 23 4099 HEXDIG 7 4100 Host 52 4101 HTAB 7 4102 HTTP-message 21 4103 HTTP-Prot-Name 15 4104 http-URI 18 4105 HTTP-Version 15 4106 https-URI 19 4107 last-chunk 36 4108 LF 7 4109 message-body 27 4110 Method 22 4111 obs-text 26 4112 OCTET 7 4113 OWS 9 4114 path-absolute 17 4115 port 17 4116 product 39 4117 product-version 39 4118 protocol-name 57 4119 protocol-version 57 4120 pseudonym 57 4121 qdtext 26 4122 qdtext-nf 36 4123 query 17 4124 quoted-cpair 26 4125 quoted-pair 26 4126 quoted-str-nf 36 4127 quoted-string 26 4128 qvalue 40 4129 Reason-Phrase 23 4130 received-by 57 4131 received-protocol 57 4132 Request-Line 22 4133 request-target 22 4134 RWS 9 4135 SP 7 4136 special 26 4137 start-line 21 4138 Status-Code 23 4139 Status-Line 23 4140 t-codings 53 4141 tchar 26 4142 TE 53 4143 te-ext 53 4144 te-params 53 4145 token 26 4146 Trailer 54 4147 trailer-part 36 4148 transfer-coding 35 4149 Transfer-Encoding 54 4150 transfer-extension 35 4151 transfer-parameter 35 4152 Upgrade 55 4153 uri-host 17 4154 URI-reference 17 4155 value 35 4156 VCHAR 7 4157 Via 57 4158 word 26 4159 gzip (Coding Format) 39 4161 H 4162 header field 20 4163 Header Fields 4164 Connection 49 4165 Content-Length 51 4166 Host 51 4167 TE 53 4168 Trailer 54 4169 Transfer-Encoding 54 4170 Upgrade 55 4171 Via 57 4172 header section 20 4173 headers 20 4174 Host header field 51 4175 http URI scheme 18 4176 https URI scheme 19 4178 I 4179 inbound 13 4180 interception proxy 14 4181 intermediary 12 4183 M 4184 Media Type 4185 application/http 61 4186 message/http 59 4187 message 10 4188 message/http Media Type 59 4190 N 4191 non-transforming proxy 13 4193 O 4194 origin form (of request-target) 32 4195 origin server 10 4196 outbound 13 4198 P 4199 proxy 13 4201 R 4202 recipient 10 4203 request 10 4204 resource 17 4205 response 10 4206 reverse proxy 13 4208 S 4209 sender 10 4210 server 10 4211 spider 10 4213 T 4214 target resource 34 4215 TE header field 53 4216 Trailer header field 54 4217 Transfer-Encoding header field 54 4218 transforming proxy 13 4219 transparent proxy 14 4220 tunnel 14 4222 U 4223 Upgrade header field 55 4224 upstream 13 4225 URI scheme 4226 http 18 4227 https 19 4228 user agent 10 4230 V 4231 Via header field 57 4233 Authors' Addresses 4235 Roy T. Fielding (editor) 4236 Adobe Systems Incorporated 4237 345 Park Ave 4238 San Jose, CA 95110 4239 USA 4241 EMail: fielding@gbiv.com 4242 URI: http://roy.gbiv.com/ 4243 Jim Gettys 4244 Alcatel-Lucent Bell Labs 4245 21 Oak Knoll Road 4246 Carlisle, MA 01741 4247 USA 4249 EMail: jg@freedesktop.org 4250 URI: http://gettys.wordpress.com/ 4252 Jeffrey C. Mogul 4253 Hewlett-Packard Company 4254 HP Labs, Large Scale Systems Group 4255 1501 Page Mill Road, MS 1177 4256 Palo Alto, CA 94304 4257 USA 4259 EMail: JeffMogul@acm.org 4261 Henrik Frystyk Nielsen 4262 Microsoft Corporation 4263 1 Microsoft Way 4264 Redmond, WA 98052 4265 USA 4267 EMail: henrikn@microsoft.com 4269 Larry Masinter 4270 Adobe Systems Incorporated 4271 345 Park Ave 4272 San Jose, CA 95110 4273 USA 4275 EMail: LMM@acm.org 4276 URI: http://larry.masinter.net/ 4278 Paul J. Leach 4279 Microsoft Corporation 4280 1 Microsoft Way 4281 Redmond, WA 98052 4283 EMail: paulle@microsoft.com 4284 Tim Berners-Lee 4285 World Wide Web Consortium 4286 MIT Computer Science and Artificial Intelligence Laboratory 4287 The Stata Center, Building 32 4288 32 Vassar Street 4289 Cambridge, MA 02139 4290 USA 4292 EMail: timbl@w3.org 4293 URI: http://www.w3.org/People/Berners-Lee/ 4295 Yves Lafon (editor) 4296 World Wide Web Consortium 4297 W3C / ERCIM 4298 2004, rte des Lucioles 4299 Sophia-Antipolis, AM 06902 4300 France 4302 EMail: ylafon@w3.org 4303 URI: http://www.raubacapeu.net/people/yves/ 4305 Julian F. Reschke (editor) 4306 greenbytes GmbH 4307 Hafenweg 16 4308 Muenster, NW 48155 4309 Germany 4311 Phone: +49 251 2807760 4312 Fax: +49 251 2807761 4313 EMail: julian.reschke@greenbytes.de 4314 URI: http://greenbytes.de/tech/webdav/