diff options
Diffstat (limited to 'doc/rfc/rfc9112.txt')
| -rw-r--r-- | doc/rfc/rfc9112.txt | 2461 |
1 files changed, 2461 insertions, 0 deletions
diff --git a/doc/rfc/rfc9112.txt b/doc/rfc/rfc9112.txt new file mode 100644 index 0000000..b84d1f7 --- /dev/null +++ b/doc/rfc/rfc9112.txt @@ -0,0 +1,2461 @@ + + + + +Internet Engineering Task Force (IETF) R. Fielding, Ed. +Request for Comments: 9112 Adobe +STD: 99 M. Nottingham, Ed. +Obsoletes: 7230 Fastly +Category: Standards Track J. Reschke, Ed. +ISSN: 2070-1721 greenbytes + June 2022 + + + HTTP/1.1 + +Abstract + + The Hypertext Transfer Protocol (HTTP) is a stateless application- + level protocol for distributed, collaborative, hypertext information + systems. This document specifies the HTTP/1.1 message syntax, + message parsing, connection management, and related security + concerns. + + This document obsoletes portions of RFC 7230. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + https://www.rfc-editor.org/info/rfc9112. + +Copyright Notice + + Copyright (c) 2022 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (https://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Revised BSD License text as described in Section 4.e of the + Trust Legal Provisions and are provided without warranty as described + in the Revised BSD License. + + This document may contain material from IETF Documents or IETF + Contributions published or made publicly available before November + 10, 2008. The person(s) controlling the copyright in some of this + material may not have granted the IETF Trust the right to allow + modifications of such material outside the IETF Standards Process. + Without obtaining an adequate license from the person(s) controlling + the copyright in such materials, this document may not be modified + outside the IETF Standards Process, and derivative works of it may + not be created outside the IETF Standards Process, except to format + it for publication as an RFC or to translate it into languages other + than English. + +Table of Contents + + 1. Introduction + 1.1. Requirements Notation + 1.2. Syntax Notation + 2. Message + 2.1. Message Format + 2.2. Message Parsing + 2.3. HTTP Version + 3. Request Line + 3.1. Method + 3.2. Request Target + 3.2.1. origin-form + 3.2.2. absolute-form + 3.2.3. authority-form + 3.2.4. asterisk-form + 3.3. Reconstructing the Target URI + 4. Status Line + 5. Field Syntax + 5.1. Field Line Parsing + 5.2. Obsolete Line Folding + 6. Message Body + 6.1. Transfer-Encoding + 6.2. Content-Length + 6.3. Message Body Length + 7. Transfer Codings + 7.1. Chunked Transfer Coding + 7.1.1. Chunk Extensions + 7.1.2. Chunked Trailer Section + 7.1.3. Decoding Chunked + 7.2. Transfer Codings for Compression + 7.3. Transfer Coding Registry + 7.4. Negotiating Transfer Codings + 8. Handling Incomplete Messages + 9. Connection Management + 9.1. Establishment + 9.2. Associating a Response to a Request + 9.3. Persistence + 9.3.1. Retrying Requests + 9.3.2. Pipelining + 9.4. Concurrency + 9.5. Failures and Timeouts + 9.6. Tear-down + 9.7. TLS Connection Initiation + 9.8. TLS Connection Closure + 10. Enclosing Messages as Data + 10.1. Media Type message/http + 10.2. Media Type application/http + 11. Security Considerations + 11.1. Response Splitting + 11.2. Request Smuggling + 11.3. Message Integrity + 11.4. Message Confidentiality + 12. IANA Considerations + 12.1. Field Name Registration + 12.2. Media Type Registration + 12.3. Transfer Coding Registration + 12.4. ALPN Protocol ID Registration + 13. References + 13.1. Normative References + 13.2. Informative References + Appendix A. Collected ABNF + Appendix B. Differences between HTTP and MIME + B.1. MIME-Version + B.2. Conversion to Canonical Form + B.3. Conversion of Date Formats + B.4. Conversion of Content-Encoding + B.5. Conversion of Content-Transfer-Encoding + B.6. MHTML and Line Length Limitations + Appendix C. Changes from Previous RFCs + C.1. Changes from HTTP/0.9 + C.2. Changes from HTTP/1.0 + C.2.1. Multihomed Web Servers + C.2.2. Keep-Alive Connections + C.2.3. Introduction of Transfer-Encoding + C.3. Changes from RFC 7230 + Acknowledgements + Index + Authors' Addresses + +1. Introduction + + The Hypertext Transfer Protocol (HTTP) is a stateless application- + level request/response protocol that uses extensible semantics and + self-descriptive messages for flexible interaction with network-based + hypertext information systems. HTTP/1.1 is defined by: + + * This document + + * "HTTP Semantics" [HTTP] + + * "HTTP Caching" [CACHING] + + This document specifies how HTTP semantics are conveyed using the + HTTP/1.1 message syntax, framing, and connection management + mechanisms. Its goal is to define the complete set of requirements + for HTTP/1.1 message parsers and message-forwarding intermediaries. + + This document obsoletes the portions of RFC 7230 related to HTTP/1.1 + messaging and connection management, with the changes being + summarized in Appendix C.3. The other parts of RFC 7230 are + obsoleted by "HTTP Semantics" [HTTP]. + +1.1. Requirements Notation + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and + "OPTIONAL" in this document are to be interpreted as described in + BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all + capitals, as shown here. + + Conformance criteria and considerations regarding error handling are + defined in Section 2 of [HTTP]. + +1.2. Syntax Notation + + This specification uses the Augmented Backus-Naur Form (ABNF) + notation of [RFC5234], extended with the notation for case- + sensitivity in strings defined in [RFC7405]. + + It also uses a list extension, defined in Section 5.6.1 of [HTTP], + that allows for compact definition of comma-separated lists using a + "#" operator (similar to how the "*" operator indicates repetition). + Appendix A shows the collected grammar with all list operators + expanded to standard ABNF notation. + + As a convention, ABNF rule names prefixed with "obs-" denote obsolete + grammar rules that appear for historical reasons. + + The following core rules are included by reference, as defined in + [RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF + (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote), + HEXDIG (hexadecimal 0-9/A-F/a-f), HTAB (horizontal tab), LF (line + feed), OCTET (any 8-bit sequence of data), SP (space), and VCHAR (any + visible [USASCII] character). + + The rules below are defined in [HTTP]: + + BWS = <BWS, see [HTTP], Section 5.6.3> + OWS = <OWS, see [HTTP], Section 5.6.3> + RWS = <RWS, see [HTTP], Section 5.6.3> + absolute-path = <absolute-path, see [HTTP], Section 4.1> + field-name = <field-name, see [HTTP], Section 5.1> + field-value = <field-value, see [HTTP], Section 5.5> + obs-text = <obs-text, see [HTTP], Section 5.6.4> + quoted-string = <quoted-string, see [HTTP], Section 5.6.4> + token = <token, see [HTTP], Section 5.6.2> + transfer-coding = + <transfer-coding, see [HTTP], Section 10.1.4> + + The rules below are defined in [URI]: + + absolute-URI = <absolute-URI, see [URI], Section 4.3> + authority = <authority, see [URI], Section 3.2> + uri-host = <host, see [URI], Section 3.2.2> + port = <port, see [URI], Section 3.2.3> + query = <query, see [URI], Section 3.4> + +2. Message + + HTTP/1.1 clients and servers communicate by sending messages. See + Section 3 of [HTTP] for the general terminology and core concepts of + HTTP. + +2.1. Message Format + + An HTTP/1.1 message consists of a start-line followed by a CRLF and a + sequence of octets in a format similar to the Internet Message Format + [RFC5322]: zero or more header field lines (collectively referred to + as the "headers" or the "header section"), an empty line indicating + the end of the header section, and an optional message body. + + HTTP-message = start-line CRLF + *( field-line CRLF ) + CRLF + [ message-body ] + + A message can be either a request from client to server or a response + from server to client. Syntactically, the two types of messages + differ only in the start-line, which is either a request-line (for + requests) or a status-line (for responses), and in the algorithm for + determining the length of the message body (Section 6). + + start-line = request-line / status-line + + In theory, a client could receive requests and a server could receive + responses, distinguishing them by their different start-line formats. + In practice, servers are implemented to only expect a request (a + response is interpreted as an unknown or invalid request method), and + clients are implemented to only expect a response. + + HTTP makes use of some protocol elements similar to the Multipurpose + Internet Mail Extensions (MIME) [RFC2045]. See Appendix B for the + differences between HTTP and MIME messages. + +2.2. Message Parsing + + The normal procedure for parsing an HTTP message is to read the + start-line into a structure, read each header field line into a hash + table by field name until the empty line, and then use the parsed + data to determine if a message body is expected. If a message body + has been indicated, then it is read as a stream until an amount of + octets equal to the message body length is read or the connection is + closed. + + A recipient MUST parse an HTTP message as a sequence of octets in an + encoding that is a superset of US-ASCII [USASCII]. Parsing an HTTP + message as a stream of Unicode characters, without regard for the + specific encoding, creates security vulnerabilities due to the + varying ways that string processing libraries handle invalid + multibyte character sequences that contain the octet LF (%x0A). + String-based parsers can only be safely used within protocol elements + after the element has been extracted from the message, such as within + a header field line value after message parsing has delineated the + individual field lines. + + Although the line terminator for the start-line and fields is the + sequence CRLF, a recipient MAY recognize a single LF as a line + terminator and ignore any preceding CR. + + A sender MUST NOT generate a bare CR (a CR character not immediately + followed by LF) within any protocol elements other than the content. + A recipient of such a bare CR MUST consider that element to be + invalid or replace each bare CR with SP before processing the element + or forwarding the message. + + Older HTTP/1.0 user agent implementations might send an extra CRLF + after a POST request as a workaround for some early server + applications that failed to read message body content that was not + terminated by a line-ending. An HTTP/1.1 user agent MUST NOT preface + or follow a request with an extra CRLF. If terminating the request + message body with a line-ending is desired, then the user agent MUST + count the terminating CRLF octets as part of the message body length. + + In the interest of robustness, a server that is expecting to receive + and parse a request-line SHOULD ignore at least one empty line (CRLF) + received prior to the request-line. + + A sender MUST NOT send whitespace between the start-line and the + first header field. + + A recipient that receives whitespace between the start-line and the + first header field MUST either reject the message as invalid or + consume each whitespace-preceded line without further processing of + it (i.e., ignore the entire line, along with any subsequent lines + preceded by whitespace, until a properly formed header field is + received or the header section is terminated). Rejection or removal + of invalid whitespace-preceded lines is necessary to prevent their + misinterpretation by downstream recipients that might be vulnerable + to request smuggling (Section 11.2) or response splitting + (Section 11.1) attacks. + + When a server listening only for HTTP request messages, or processing + what appears from the start-line to be an HTTP request message, + receives a sequence of octets that does not match the HTTP-message + grammar aside from the robustness exceptions listed above, the server + SHOULD respond with a 400 (Bad Request) response and close the + connection. + +2.3. HTTP Version + + HTTP uses a "<major>.<minor>" numbering scheme to indicate versions + of the protocol. This specification defines version "1.1". + Section 2.5 of [HTTP] specifies the semantics of HTTP version + numbers. + + The version of an HTTP/1.x message is indicated by an HTTP-version + field in the start-line. HTTP-version is case-sensitive. + + HTTP-version = HTTP-name "/" DIGIT "." DIGIT + HTTP-name = %s"HTTP" + + When an HTTP/1.1 message is sent to an HTTP/1.0 recipient [HTTP/1.0] + or a recipient whose version is unknown, the HTTP/1.1 message is + constructed such that it can be interpreted as a valid HTTP/1.0 + message if all of the newer features are ignored. This specification + places recipient-version requirements on some new features so that a + conformant sender will only use compatible features until it has + determined, through configuration or the receipt of a message, that + the recipient supports HTTP/1.1. + + Intermediaries that process HTTP messages (i.e., all intermediaries + other than those acting as tunnels) MUST send their own HTTP-version + in forwarded messages, unless it is purposefully downgraded as a + workaround for an upstream issue. In other words, an intermediary is + not allowed to blindly forward the start-line without ensuring that + the protocol version in that message matches a version to which that + intermediary is conformant for both the receiving and sending of + messages. Forwarding an HTTP message without rewriting the HTTP- + version might result in communication errors when downstream + recipients use the message sender's version to determine what + features are safe to use for later communication with that sender. + + A server MAY send an HTTP/1.0 response to an HTTP/1.1 request if it + is known or suspected that the client incorrectly implements the HTTP + specification and is incapable of correctly processing later version + responses, such as when a client fails to parse the version number + correctly or when an intermediary is known to blindly forward the + HTTP-version even when it doesn't conform to the given minor version + of the protocol. Such protocol downgrades SHOULD NOT be performed + unless triggered by specific client attributes, such as when one or + more of the request header fields (e.g., User-Agent) uniquely match + the values sent by a client known to be in error. + +3. Request Line + + A request-line begins with a method token, followed by a single space + (SP), the request-target, and another single space (SP), and ends + with the protocol version. + + request-line = method SP request-target SP HTTP-version + + Although the request-line grammar rule requires that each of the + component elements be separated by a single SP octet, recipients MAY + instead parse on whitespace-delimited word boundaries and, aside from + the CRLF terminator, treat any form of whitespace as the SP separator + while ignoring preceding or trailing whitespace; such whitespace + includes one or more of the following octets: SP, HTAB, VT (%x0B), FF + (%x0C), or bare CR. However, lenient parsing can result in request + smuggling security vulnerabilities if there are multiple recipients + of the message and each has its own unique interpretation of + robustness (see Section 11.2). + + HTTP does not place a predefined limit on the length of a request- + line, as described in Section 2.3 of [HTTP]. A server that receives + a method longer than any that it implements SHOULD respond with a 501 + (Not Implemented) status code. A server that receives a request- + target longer than any URI it wishes to parse MUST respond with a 414 + (URI Too Long) status code (see Section 15.5.15 of [HTTP]). + + Various ad hoc limitations on request-line length are found in + practice. It is RECOMMENDED that all HTTP senders and recipients + support, at a minimum, request-line lengths of 8000 octets. + +3.1. Method + + The method token indicates the request method to be performed on the + target resource. The request method is case-sensitive. + + method = token + + The request methods defined by this specification can be found in + Section 9 of [HTTP], along with information regarding the HTTP method + registry and considerations for defining new methods. + +3.2. Request Target + + The request-target identifies the target resource upon which to apply + the request. The client derives a request-target from its desired + target URI. There are four distinct formats for the request-target, + depending on both the method being requested and whether the request + is to a proxy. + + request-target = origin-form + / absolute-form + / authority-form + / asterisk-form + + No whitespace is allowed in the request-target. Unfortunately, some + user agents fail to properly encode or exclude whitespace found in + hypertext references, resulting in those disallowed characters being + sent as the request-target in a malformed request-line. + + Recipients of an invalid request-line SHOULD respond with either a + 400 (Bad Request) error or a 301 (Moved Permanently) redirect with + the request-target properly encoded. A recipient SHOULD NOT attempt + to autocorrect and then process the request without a redirect, since + the invalid request-line might be deliberately crafted to bypass + security filters along the request chain. + + A client MUST send a Host header field (Section 7.2 of [HTTP]) in all + HTTP/1.1 request messages. If the target URI includes an authority + component, then a client MUST send a field value for Host that is + identical to that authority component, excluding any userinfo + subcomponent and its "@" delimiter (Section 4.2 of [HTTP]). If the + authority component is missing or undefined for the target URI, then + a client MUST send a Host header field with an empty field value. + + A server MUST respond with a 400 (Bad Request) status code to any + HTTP/1.1 request message that lacks a Host header field and to any + request message that contains more than one Host header field line or + a Host header field with an invalid field value. + +3.2.1. origin-form + + The most common form of request-target is the "origin-form". + + origin-form = absolute-path [ "?" query ] + + When making a request directly to an origin server, other than a + CONNECT or server-wide OPTIONS request (as detailed below), a client + MUST send only the absolute path and query components of the target + URI as the request-target. If the target URI's path component is + empty, the client MUST send "/" as the path within the origin-form of + request-target. A Host header field is also sent, as defined in + Section 7.2 of [HTTP]. + + For example, a client wishing to retrieve a representation of the + resource identified as + + http://www.example.org/where?q=now + + directly from the origin server would open (or reuse) a TCP + connection to port 80 of the host "www.example.org" and send the + lines: + + GET /where?q=now HTTP/1.1 + Host: www.example.org + + followed by the remainder of the request message. + +3.2.2. absolute-form + + When making a request to a proxy, other than a CONNECT or server-wide + OPTIONS request (as detailed below), a client MUST send the target + URI in "absolute-form" as the request-target. + + absolute-form = absolute-URI + + The proxy is requested to either service that request from a valid + cache, if possible, or make the same request on the client's behalf + either to the next inbound proxy server or directly to the origin + server indicated by the request-target. Requirements on such + "forwarding" of messages are defined in Section 7.6 of [HTTP]. + + An example absolute-form of request-line would be: + + GET http://www.example.org/pub/WWW/TheProject.html HTTP/1.1 + + A client MUST send a Host header field in an HTTP/1.1 request even if + the request-target is in the absolute-form, since this allows the + Host information to be forwarded through ancient HTTP/1.0 proxies + that might not have implemented Host. + + When a proxy receives a request with an absolute-form of request- + target, the proxy MUST ignore the received Host header field (if any) + and instead replace it with the host information of the request- + target. A proxy that forwards such a request MUST generate a new + Host field value based on the received request-target rather than + forward the received Host field value. + + When an origin server receives a request with an absolute-form of + request-target, the origin server MUST ignore the received Host + header field (if any) and instead use the host information of the + request-target. Note that if the request-target does not have an + authority component, an empty Host header field will be sent in this + case. + + A server MUST accept the absolute-form in requests even though most + HTTP/1.1 clients will only send the absolute-form to a proxy. + +3.2.3. authority-form + + The "authority-form" of request-target is only used for CONNECT + requests (Section 9.3.6 of [HTTP]). It consists of only the uri-host + and port number of the tunnel destination, separated by a colon + (":"). + + authority-form = uri-host ":" port + + When making a CONNECT request to establish a tunnel through one or + more proxies, a client MUST send only the host and port of the tunnel + destination as the request-target. The client obtains the host and + port from the target URI's authority component, except that it sends + the scheme's default port if the target URI elides the port. For + example, a CONNECT request to "http://www.example.com" looks like the + following: + + CONNECT www.example.com:80 HTTP/1.1 + Host: www.example.com + +3.2.4. asterisk-form + + The "asterisk-form" of request-target is only used for a server-wide + OPTIONS request (Section 9.3.7 of [HTTP]). + + asterisk-form = "*" + + When a client wishes to request OPTIONS for the server as a whole, as + opposed to a specific named resource of that server, the client MUST + send only "*" (%x2A) as the request-target. For example, + + OPTIONS * HTTP/1.1 + + If a proxy receives an OPTIONS request with an absolute-form of + request-target in which the URI has an empty path and no query + component, then the last proxy on the request chain MUST send a + request-target of "*" when it forwards the request to the indicated + origin server. + + For example, the request + + OPTIONS http://www.example.org:8001 HTTP/1.1 + + would be forwarded by the final proxy as + + OPTIONS * HTTP/1.1 + Host: www.example.org:8001 + + after connecting to port 8001 of host "www.example.org". + +3.3. Reconstructing the Target URI + + The target URI is the request-target when the request-target is in + absolute-form. In that case, a server will parse the URI into its + generic components for further evaluation. + + Otherwise, the server reconstructs the target URI from the connection + context and various parts of the request message in order to identify + the target resource (Section 7.1 of [HTTP]): + + * If the server's configuration provides for a fixed URI scheme, or + a scheme is provided by a trusted outbound gateway, that scheme is + used for the target URI. This is common in large-scale + deployments because a gateway server will receive the client's + connection context and replace that with their own connection to + the inbound server. Otherwise, if the request is received over a + secured connection, the target URI's scheme is "https"; if not, + the scheme is "http". + + * If the request-target is in authority-form, the target URI's + authority component is the request-target. Otherwise, the target + URI's authority component is the field value of the Host header + field. If there is no Host header field or if its field value is + empty or invalid, the target URI's authority component is empty. + + * If the request-target is in authority-form or asterisk-form, the + target URI's combined path and query component is empty. + Otherwise, the target URI's combined path and query component is + the request-target. + + * The components of a reconstructed target URI, once determined as + above, can be recombined into absolute-URI form by concatenating + the scheme, "://", authority, and combined path and query + component. + + Example 1: The following message received over a secure connection + + GET /pub/WWW/TheProject.html HTTP/1.1 + Host: www.example.org + + has a target URI of + + https://www.example.org/pub/WWW/TheProject.html + + Example 2: The following message received over an insecure connection + + OPTIONS * HTTP/1.1 + Host: www.example.org:8080 + + has a target URI of + + http://www.example.org:8080 + + If the target URI's authority component is empty and its URI scheme + requires a non-empty authority (as is the case for "http" and + "https"), the server can reject the request or determine whether a + configured default applies that is consistent with the incoming + connection's context. Context might include connection details like + address and port, what security has been applied, and locally defined + information specific to that server's configuration. An empty + authority is replaced with the configured default before further + processing of the request. + + Supplying a default name for authority within the context of a + secured connection is inherently unsafe if there is any chance that + the user agent's intended authority might differ from the default. A + server that can uniquely identify an authority from the request + context MAY use that identity as a default without this risk. + Alternatively, it might be better to redirect the request to a safe + resource that explains how to obtain a new client. + + Note that reconstructing the client's target URI is only half of the + process for identifying a target resource. The other half is + determining whether that target URI identifies a resource for which + the server is willing and able to send a response, as defined in + Section 7.4 of [HTTP]. + +4. Status Line + + The first line of a response message is the status-line, consisting + of the protocol version, a space (SP), the status code, and another + space and ending with an OPTIONAL textual phrase describing the + status code. + + status-line = HTTP-version SP status-code SP [ reason-phrase ] + + Although the status-line grammar rule requires that each of the + component elements be separated by a single SP octet, recipients MAY + instead parse on whitespace-delimited word boundaries and, aside from + the line terminator, treat any form of whitespace as the SP separator + while ignoring preceding or trailing whitespace; such whitespace + includes one or more of the following octets: SP, HTAB, VT (%x0B), FF + (%x0C), or bare CR. However, lenient parsing can result in response + splitting security vulnerabilities if there are multiple recipients + of the message and each has its own unique interpretation of + robustness (see Section 11.1). + + The status-code element is a 3-digit integer code describing the + result of the server's attempt to understand and satisfy the client's + corresponding request. A recipient parses and interprets the + remainder of the response message in light of the semantics defined + for that status code, if the status code is recognized by that + recipient, or in accordance with the class of that status code when + the specific code is unrecognized. + + status-code = 3DIGIT + + HTTP's core status codes are defined in Section 15 of [HTTP], along + with the classes of status codes, considerations for the definition + of new status codes, and the IANA registry for collecting such + definitions. + + The reason-phrase element exists for the sole purpose of providing a + textual description associated with the numeric status code, mostly + out of deference to earlier Internet application protocols that were + more frequently used with interactive text clients. + + reason-phrase = 1*( HTAB / SP / VCHAR / obs-text ) + + A client SHOULD ignore the reason-phrase content because it is not a + reliable channel for information (it might be translated for a given + locale, overwritten by intermediaries, or discarded when the message + is forwarded via other versions of HTTP). A server MUST send the + space that separates the status-code from the reason-phrase even when + the reason-phrase is absent (i.e., the status-line would end with the + space). + +5. Field Syntax + + Each field line consists of a case-insensitive field name followed by + a colon (":"), optional leading whitespace, the field line value, and + optional trailing whitespace. + + field-line = field-name ":" OWS field-value OWS + + Rules for parsing within field values are defined in Section 5.5 of + [HTTP]. This section covers the generic syntax for header field + inclusion within, and extraction from, HTTP/1.1 messages. + +5.1. Field Line Parsing + + Messages are parsed using a generic algorithm, independent of the + individual field names. The contents within a given field line value + are not parsed until a later stage of message interpretation (usually + after the message's entire field section has been processed). + + No whitespace is allowed between the field name and colon. In the + past, differences in the handling of such whitespace have led to + security vulnerabilities in request routing and response handling. A + server MUST reject, with a response status code of 400 (Bad Request), + any received request message that contains whitespace between a + header field name and colon. A proxy MUST remove any such whitespace + from a response message before forwarding the message downstream. + + A field line value might be preceded and/or followed by optional + whitespace (OWS); a single SP preceding the field line value is + preferred for consistent readability by humans. The field line value + does not include that leading or trailing whitespace: OWS occurring + before the first non-whitespace octet of the field line value, or + after the last non-whitespace octet of the field line value, is + excluded by parsers when extracting the field line value from a field + line. + +5.2. Obsolete Line Folding + + Historically, HTTP/1.x field values could be extended over multiple + lines by preceding each extra line with at least one space or + horizontal tab (obs-fold). This specification deprecates such line + folding except within the "message/http" media type (Section 10.1). + + obs-fold = OWS CRLF RWS + ; obsolete line folding + + A sender MUST NOT generate a message that includes line folding + (i.e., that has any field line value that contains a match to the + obs-fold rule) unless the message is intended for packaging within + the "message/http" media type. + + A server that receives an obs-fold in a request message that is not + within a "message/http" container MUST either reject the message by + sending a 400 (Bad Request), preferably with a representation + explaining that obsolete line folding is unacceptable, or replace + each received obs-fold with one or more SP octets prior to + interpreting the field value or forwarding the message downstream. + + A proxy or gateway that receives an obs-fold in a response message + that is not within a "message/http" container MUST either discard the + message and replace it with a 502 (Bad Gateway) response, preferably + with a representation explaining that unacceptable line folding was + received, or replace each received obs-fold with one or more SP + octets prior to interpreting the field value or forwarding the + message downstream. + + A user agent that receives an obs-fold in a response message that is + not within a "message/http" container MUST replace each received + obs-fold with one or more SP octets prior to interpreting the field + value. + +6. Message Body + + The message body (if any) of an HTTP/1.1 message is used to carry + content (Section 6.4 of [HTTP]) for the request or response. The + message body is identical to the content unless a transfer coding has + been applied, as described in Section 6.1. + + message-body = *OCTET + + The rules for determining when a message body is present in an + HTTP/1.1 message differ for requests and responses. + + The presence of a message body in a request is signaled by a + Content-Length or Transfer-Encoding header field. Request message + framing is independent of method semantics. + + The presence of a message body in a response, as detailed in + Section 6.3, depends on both the request method to which it is + responding and the response status code. This corresponds to when + response content is allowed by HTTP semantics (Section 6.4.1 of + [HTTP]). + +6.1. Transfer-Encoding + + The Transfer-Encoding header field lists the transfer coding names + corresponding to the sequence of transfer codings that have been (or + will be) applied to the content in order to form the message body. + Transfer codings are defined in Section 7. + + Transfer-Encoding = #transfer-coding + ; defined in [HTTP], Section 10.1.4 + + Transfer-Encoding is analogous to the Content-Transfer-Encoding field + of MIME, which was designed to enable safe transport of binary data + over a 7-bit transport service ([RFC2045], Section 6). However, safe + transport has a different focus for an 8bit-clean transfer protocol. + In HTTP's case, Transfer-Encoding is primarily intended to accurately + delimit dynamically generated content. It also serves to distinguish + encodings that are only applied in transit from the encodings that + are a characteristic of the selected representation. + + A recipient MUST be able to parse the chunked transfer coding + (Section 7.1) because it plays a crucial role in framing messages + when the content size is not known in advance. A sender MUST NOT + apply the chunked transfer coding more than once to a message body + (i.e., chunking an already chunked message is not allowed). If any + transfer coding other than chunked is applied to a request's content, + the sender MUST apply chunked as the final transfer coding to ensure + that the message is properly framed. If any transfer coding other + than chunked is applied to a response's content, the sender MUST + either apply chunked as the final transfer coding or terminate the + message by closing the connection. + + For example, + + Transfer-Encoding: gzip, chunked + + indicates that the content has been compressed using the gzip coding + and then chunked using the chunked coding while forming the message + body. + + Unlike Content-Encoding (Section 8.4.1 of [HTTP]), Transfer-Encoding + is a property of the message, not of the representation. Any + recipient along the request/response chain MAY decode the received + transfer coding(s) or apply additional transfer coding(s) to the + message body, assuming that corresponding changes are made to the + Transfer-Encoding field value. Additional information about the + encoding parameters can be provided by other header fields not + defined by this specification. + + Transfer-Encoding MAY be sent in a response to a HEAD request or in a + 304 (Not Modified) response (Section 15.4.5 of [HTTP]) to a GET + request, neither of which includes a message body, to indicate that + the origin server would have applied a transfer coding to the message + body if the request had been an unconditional GET. This indication + is not required, however, because any recipient on the response chain + (including the origin server) can remove transfer codings when they + are not needed. + + A server MUST NOT send a Transfer-Encoding header field in any + response with a status code of 1xx (Informational) or 204 (No + Content). A server MUST NOT send a Transfer-Encoding header field in + any 2xx (Successful) response to a CONNECT request (Section 9.3.6 of + [HTTP]). + + A server that receives a request message with a transfer coding it + does not understand SHOULD respond with 501 (Not Implemented). + + Transfer-Encoding was added in HTTP/1.1. It is generally assumed + that implementations advertising only HTTP/1.0 support will not + understand how to process transfer-encoded content, and that an + HTTP/1.0 message received with a Transfer-Encoding is likely to have + been forwarded without proper handling of the chunked transfer coding + in transit. + + A client MUST NOT send a request containing Transfer-Encoding unless + it knows the server will handle HTTP/1.1 requests (or later minor + revisions); such knowledge might be in the form of specific user + configuration or by remembering the version of a prior received + response. A server MUST NOT send a response containing Transfer- + Encoding unless the corresponding request indicates HTTP/1.1 (or + later minor revisions). + + Early implementations of Transfer-Encoding would occasionally send + both a chunked transfer coding for message framing and an estimated + Content-Length header field for use by progress bars. This is why + Transfer-Encoding is defined as overriding Content-Length, as opposed + to them being mutually incompatible. Unfortunately, forwarding such + a message can lead to vulnerabilities regarding request smuggling + (Section 11.2) or response splitting (Section 11.1) attacks if any + downstream recipient fails to parse the message according to this + specification, particularly when a downstream recipient only + implements HTTP/1.0. + + A server MAY reject a request that contains both Content-Length and + Transfer-Encoding or process such a request in accordance with the + Transfer-Encoding alone. Regardless, the server MUST close the + connection after responding to such a request to avoid the potential + attacks. + + A server or client that receives an HTTP/1.0 message containing a + Transfer-Encoding header field MUST treat the message as if the + framing is faulty, even if a Content-Length is present, and close the + connection after processing the message. The message sender might + have retained a portion of the message, in buffer, that could be + misinterpreted by further use of the connection. + +6.2. Content-Length + + When a message does not have a Transfer-Encoding header field, a + Content-Length header field (Section 8.6 of [HTTP]) can provide the + anticipated size, as a decimal number of octets, for potential + content. For messages that do include content, the Content-Length + field value provides the framing information necessary for + determining where the data (and message) ends. For messages that do + not include content, the Content-Length indicates the size of the + selected representation (Section 8.6 of [HTTP]). + + A sender MUST NOT send a Content-Length header field in any message + that contains a Transfer-Encoding header field. + + | *Note:* HTTP's use of Content-Length for message framing + | differs significantly from the same field's use in MIME, where + | it is an optional field used only within the "message/external- + | body" media-type. + +6.3. Message Body Length + + The length of a message body is determined by one of the following + (in order of precedence): + + 1. Any response to a HEAD request and any response with a 1xx + (Informational), 204 (No Content), or 304 (Not Modified) status + code is always terminated by the first empty line after the + header fields, regardless of the header fields present in the + message, and thus cannot contain a message body or trailer + section. + + 2. Any 2xx (Successful) response to a CONNECT request implies that + the connection will become a tunnel immediately after the empty + line that concludes the header fields. A client MUST ignore any + Content-Length or Transfer-Encoding header fields received in + such a message. + + 3. If a message is received with both a Transfer-Encoding and a + Content-Length header field, the Transfer-Encoding overrides the + Content-Length. Such a message might indicate an attempt to + perform request smuggling (Section 11.2) or response splitting + (Section 11.1) and ought to be handled as an error. An + intermediary that chooses to forward the message MUST first + remove the received Content-Length field and process the + Transfer-Encoding (as described below) prior to forwarding the + message downstream. + + 4. If a Transfer-Encoding header field is present and the chunked + transfer coding (Section 7.1) is the final encoding, the message + body length is determined by reading and decoding the chunked + data until the transfer coding indicates the data is complete. + + If a Transfer-Encoding header field is present in a response and + the chunked transfer coding is not the final encoding, the + message body length is determined by reading the connection until + it is closed by the server. + + If a Transfer-Encoding header field is present in a request and + the chunked transfer coding is not the final encoding, the + message body length cannot be determined reliably; the server + MUST respond with the 400 (Bad Request) status code and then + close the connection. + + 5. If a message is received without Transfer-Encoding and with an + invalid Content-Length header field, then the message framing is + invalid and the recipient MUST treat it as an unrecoverable + error, unless the field value can be successfully parsed as a + comma-separated list (Section 5.6.1 of [HTTP]), all values in the + list are valid, and all values in the list are the same (in which + case, the message is processed with that single value used as the + Content-Length field value). If the unrecoverable error is in a + request message, the server MUST respond with a 400 (Bad Request) + status code and then close the connection. If it is in a + response message received by a proxy, the proxy MUST close the + connection to the server, discard the received response, and send + a 502 (Bad Gateway) response to the client. If it is in a + response message received by a user agent, the user agent MUST + close the connection to the server and discard the received + response. + + 6. If a valid Content-Length header field is present without + Transfer-Encoding, its decimal value defines the expected message + body length in octets. If the sender closes the connection or + the recipient times out before the indicated number of octets are + received, the recipient MUST consider the message to be + incomplete and close the connection. + + 7. If this is a request message and none of the above are true, then + the message body length is zero (no message body is present). + + 8. Otherwise, this is a response message without a declared message + body length, so the message body length is determined by the + number of octets received prior to the server closing the + connection. + + Since there is no way to distinguish a successfully completed, close- + delimited response message from a partially received message + interrupted by network failure, a server SHOULD generate encoding or + length-delimited messages whenever possible. The close-delimiting + feature exists primarily for backwards compatibility with HTTP/1.0. + + | *Note:* Request messages are never close-delimited because they + | are always explicitly framed by length or transfer coding, with + | the absence of both implying the request ends immediately after + | the header section. + + A server MAY reject a request that contains a message body but not a + Content-Length by responding with 411 (Length Required). + + Unless a transfer coding other than chunked has been applied, a + client that sends a request containing a message body SHOULD use a + valid Content-Length header field if the message body length is known + in advance, rather than the chunked transfer coding, since some + existing services respond to chunked with a 411 (Length Required) + status code even though they understand the chunked transfer coding. + This is typically because such services are implemented via a gateway + that requires a content length in advance of being called, and the + server is unable or unwilling to buffer the entire request before + processing. + + A user agent that sends a request that contains a message body MUST + send either a valid Content-Length header field or use the chunked + transfer coding. A client MUST NOT use the chunked transfer coding + unless it knows the server will handle HTTP/1.1 (or later) requests; + such knowledge can be in the form of specific user configuration or + by remembering the version of a prior received response. + + If the final response to the last request on a connection has been + completely received and there remains additional data to read, a user + agent MAY discard the remaining data or attempt to determine if that + data belongs as part of the prior message body, which might be the + case if the prior message's Content-Length value is incorrect. A + client MUST NOT process, cache, or forward such extra data as a + separate response, since such behavior would be vulnerable to cache + poisoning. + +7. Transfer Codings + + Transfer coding names are used to indicate an encoding transformation + that has been, can be, or might need to be applied to a message's + content in order to ensure "safe transport" through the network. + This differs from a content coding in that the transfer coding is a + property of the message rather than a property of the representation + that is being transferred. + + All transfer-coding names are case-insensitive and ought to be + registered within the HTTP Transfer Coding registry, as defined in + Section 7.3. They are used in the Transfer-Encoding (Section 6.1) + and TE (Section 10.1.4 of [HTTP]) header fields (the latter also + defining the "transfer-coding" grammar). + +7.1. Chunked Transfer Coding + + The chunked transfer coding wraps content in order to transfer it as + a series of chunks, each with its own size indicator, followed by an + OPTIONAL trailer section containing trailer fields. Chunked enables + content streams of unknown size to be transferred as a sequence of + length-delimited buffers, which enables the sender to retain + connection persistence and the recipient to know when it has received + the entire message. + + chunked-body = *chunk + last-chunk + trailer-section + CRLF + + chunk = chunk-size [ chunk-ext ] CRLF + chunk-data CRLF + chunk-size = 1*HEXDIG + last-chunk = 1*("0") [ chunk-ext ] CRLF + + chunk-data = 1*OCTET ; a sequence of chunk-size octets + + The chunk-size field is a string of hex digits indicating the size of + the chunk-data in octets. The chunked transfer coding is complete + when a chunk with a chunk-size of zero is received, possibly followed + by a trailer section, and finally terminated by an empty line. + + A recipient MUST be able to parse and decode the chunked transfer + coding. + + HTTP/1.1 does not define any means to limit the size of a chunked + response such that an intermediary can be assured of buffering the + entire response. Additionally, very large chunk sizes may cause + overflows or loss of precision if their values are not represented + accurately in a receiving implementation. Therefore, recipients MUST + anticipate potentially large hexadecimal numerals and prevent parsing + errors due to integer conversion overflows or precision loss due to + integer representation. + + The chunked coding does not define any parameters. Their presence + SHOULD be treated as an error. + +7.1.1. Chunk Extensions + + The chunked coding allows each chunk to include zero or more chunk + extensions, immediately following the chunk-size, for the sake of + supplying per-chunk metadata (such as a signature or hash), mid- + message control information, or randomization of message body size. + + chunk-ext = *( BWS ";" BWS chunk-ext-name + [ BWS "=" BWS chunk-ext-val ] ) + + chunk-ext-name = token + chunk-ext-val = token / quoted-string + + The chunked coding is specific to each connection and is likely to be + removed or recoded by each recipient (including intermediaries) + before any higher-level application would have a chance to inspect + the extensions. Hence, the use of chunk extensions is generally + limited to specialized HTTP services such as "long polling" (where + client and server can have shared expectations regarding the use of + chunk extensions) or for padding within an end-to-end secured + connection. + + A recipient MUST ignore unrecognized chunk extensions. A server + ought to limit the total length of chunk extensions received in a + request to an amount reasonable for the services provided, in the + same way that it applies length limitations and timeouts for other + parts of a message, and generate an appropriate 4xx (Client Error) + response if that amount is exceeded. + +7.1.2. Chunked Trailer Section + + A trailer section allows the sender to include additional fields at + the end of a chunked message in order to supply metadata that might + be dynamically generated while the content is sent, such as a message + integrity check, digital signature, or post-processing status. The + proper use and limitations of trailer fields are defined in + Section 6.5 of [HTTP]. + + trailer-section = *( field-line CRLF ) + + A recipient that removes the chunked coding from a message MAY + selectively retain or discard the received trailer fields. A + recipient that retains a received trailer field MUST either store/ + forward the trailer field separately from the received header fields + or merge the received trailer field into the header section. A + recipient MUST NOT merge a received trailer field into the header + section unless its corresponding header field definition explicitly + permits and instructs how the trailer field value can be safely + merged. + +7.1.3. Decoding Chunked + + A process for decoding the chunked transfer coding can be represented + in pseudo-code as: + + length := 0 + read chunk-size, chunk-ext (if any), and CRLF + while (chunk-size > 0) { + read chunk-data and CRLF + append chunk-data to content + length := length + chunk-size + read chunk-size, chunk-ext (if any), and CRLF + } + read trailer field + while (trailer field is not empty) { + if (trailer fields are stored/forwarded separately) { + append trailer field to existing trailer fields + } + else if (trailer field is understood and defined as mergeable) { + merge trailer field with existing header fields + } + else { + discard trailer field + } + read trailer field + } + Content-Length := length + Remove "chunked" from Transfer-Encoding + +7.2. Transfer Codings for Compression + + The following transfer coding names for compression are defined by + the same algorithm as their corresponding content coding: + + compress (and x-compress) + See Section 8.4.1.1 of [HTTP]. + + deflate + See Section 8.4.1.2 of [HTTP]. + + gzip (and x-gzip) + See Section 8.4.1.3 of [HTTP]. + + The compression codings do not define any parameters. The presence + of parameters with any of these compression codings SHOULD be treated + as an error. + +7.3. Transfer Coding Registry + + The "HTTP Transfer Coding Registry" defines the namespace for + transfer coding names. It is maintained at + <https://www.iana.org/assignments/http-parameters>. + + Registrations MUST include the following fields: + + * Name + + * Description + + * Pointer to specification text + + Names of transfer codings MUST NOT overlap with names of content + codings (Section 8.4.1 of [HTTP]) unless the encoding transformation + is identical, as is the case for the compression codings defined in + Section 7.2. + + The TE header field (Section 10.1.4 of [HTTP]) uses a pseudo- + parameter named "q" as the rank value when multiple transfer codings + are acceptable. Future registrations of transfer codings SHOULD NOT + define parameters called "q" (case-insensitively) in order to avoid + ambiguities. + + Values to be added to this namespace require IETF Review (see + Section 4.8 of [RFC8126]) and MUST conform to the purpose of transfer + coding defined in this specification. + + Use of program names for the identification of encoding formats is + not desirable and is discouraged for future encodings. + +7.4. Negotiating Transfer Codings + + The TE field (Section 10.1.4 of [HTTP]) is used in HTTP/1.1 to + indicate what transfer codings, besides chunked, the client is + willing to accept in the response and whether the client is willing + to preserve trailer fields in a chunked transfer coding. + + A client MUST NOT send the chunked transfer coding name in TE; + chunked is always acceptable for HTTP/1.1 recipients. + + Three examples of TE use are below. + + TE: deflate + TE: + TE: trailers, deflate;q=0.5 + + When multiple transfer codings are acceptable, the client MAY rank + the codings by preference using a case-insensitive "q" parameter + (similar to the qvalues used in content negotiation fields; see + Section 12.4.2 of [HTTP]). The rank value is a real number in the + range 0 through 1, where 0.001 is the least preferred and 1 is the + most preferred; a value of 0 means "not acceptable". + + If the TE field value is empty or if no TE field is present, the only + acceptable transfer coding is chunked. A message with no transfer + coding is always acceptable. + + The keyword "trailers" indicates that the sender will not discard + trailer fields, as described in Section 6.5 of [HTTP]. + + Since the TE header field only applies to the immediate connection, a + sender of TE MUST also send a "TE" connection option within the + Connection header field (Section 7.6.1 of [HTTP]) in order to prevent + the TE header field from being forwarded by intermediaries that do + not support its semantics. + +8. Handling Incomplete Messages + + A server that receives an incomplete request message, usually due to + a canceled request or a triggered timeout exception, MAY send an + error response prior to closing the connection. + + A client that receives an incomplete response message, which can + occur when a connection is closed prematurely or when decoding a + supposedly chunked transfer coding fails, MUST record the message as + incomplete. Cache requirements for incomplete responses are defined + in Section 3.3 of [CACHING]. + + If a response terminates in the middle of the header section (before + the empty line is received) and the status code might rely on header + fields to convey the full meaning of the response, then the client + cannot assume that meaning has been conveyed; the client might need + to repeat the request in order to determine what action to take next. + + A message body that uses the chunked transfer coding is incomplete if + the zero-sized chunk that terminates the encoding has not been + received. A message that uses a valid Content-Length is incomplete + if the size of the message body received (in octets) is less than the + value given by Content-Length. A response that has neither chunked + transfer coding nor Content-Length is terminated by closure of the + connection and, if the header section was received intact, is + considered complete unless an error was indicated by the underlying + connection (e.g., an "incomplete close" in TLS would leave the + response incomplete, as described in Section 9.8). + +9. Connection Management + + HTTP messaging is independent of the underlying transport- or + session-layer connection protocol(s). HTTP only presumes a reliable + transport with in-order delivery of requests and the corresponding + in-order delivery of responses. The mapping of HTTP request and + response structures onto the data units of an underlying transport + protocol is outside the scope of this specification. + + As described in Section 7.3 of [HTTP], the specific connection + protocols to be used for an HTTP interaction are determined by client + configuration and the target URI. For example, the "http" URI scheme + (Section 4.2.1 of [HTTP]) indicates a default connection of TCP over + IP, with a default TCP port of 80, but the client might be configured + to use a proxy via some other connection, port, or protocol. + + HTTP implementations are expected to engage in connection management, + which includes maintaining the state of current connections, + establishing a new connection or reusing an existing connection, + processing messages received on a connection, detecting connection + failures, and closing each connection. Most clients maintain + multiple connections in parallel, including more than one connection + per server endpoint. Most servers are designed to maintain thousands + of concurrent connections, while controlling request queues to enable + fair use and detect denial-of-service attacks. + +9.1. Establishment + + It is beyond the scope of this specification to describe how + connections are established via various transport- or session-layer + protocols. Each HTTP connection maps to one underlying transport + connection. + +9.2. Associating a Response to a Request + + HTTP/1.1 does not include a request identifier for associating a + given request message with its corresponding one or more response + messages. Hence, it relies on the order of response arrival to + correspond exactly to the order in which requests are made on the + same connection. More than one response message per request only + occurs when one or more informational responses (1xx; see + Section 15.2 of [HTTP]) precede a final response to the same request. + + A client that has more than one outstanding request on a connection + MUST maintain a list of outstanding requests in the order sent and + MUST associate each received response message on that connection to + the first outstanding request that has not yet received a final (non- + 1xx) response. + + If a client receives data on a connection that doesn't have + outstanding requests, the client MUST NOT consider that data to be a + valid response; the client SHOULD close the connection, since message + delimitation is now ambiguous, unless the data consists only of one + or more CRLF (which can be discarded per Section 2.2). + +9.3. Persistence + + HTTP/1.1 defaults to the use of "persistent connections", allowing + multiple requests and responses to be carried over a single + connection. HTTP implementations SHOULD support persistent + connections. + + A recipient determines whether a connection is persistent or not + based on the protocol version and Connection header field + (Section 7.6.1 of [HTTP]) in the most recently received message, if + any: + + * If the "close" connection option is present (Section 9.6), the + connection will not persist after the current response; else, + + * If the received protocol is HTTP/1.1 (or later), the connection + will persist after the current response; else, + + * If the received protocol is HTTP/1.0, the "keep-alive" connection + option is present, either the recipient is not a proxy or the + message is a response, and the recipient wishes to honor the + HTTP/1.0 "keep-alive" mechanism, the connection will persist after + the current response; otherwise, + + * The connection will close after the current response. + + A client that does not support persistent connections MUST send the + "close" connection option in every request message. + + A server that does not support persistent connections MUST send the + "close" connection option in every response message that does not + have a 1xx (Informational) status code. + + A client MAY send additional requests on a persistent connection + until it sends or receives a "close" connection option or receives an + HTTP/1.0 response without a "keep-alive" connection option. + + In order to remain persistent, all messages on a connection need to + have a self-defined message length (i.e., one not defined by closure + of the connection), as described in Section 6. A server MUST read + the entire request message body or close the connection after sending + its response; otherwise, the remaining data on a persistent + connection would be misinterpreted as the next request. Likewise, a + client MUST read the entire response message body if it intends to + reuse the same connection for a subsequent request. + + A proxy server MUST NOT maintain a persistent connection with an + HTTP/1.0 client (see Appendix C.2.2 for information and discussion of + the problems with the Keep-Alive header field implemented by many + HTTP/1.0 clients). + + See Appendix C.2.2 for more information on backwards compatibility + with HTTP/1.0 clients. + +9.3.1. Retrying Requests + + Connections can be closed at any time, with or without intention. + Implementations ought to anticipate the need to recover from + asynchronous close events. The conditions under which a client can + automatically retry a sequence of outstanding requests are defined in + Section 9.2.2 of [HTTP]. + +9.3.2. Pipelining + + A client that supports persistent connections MAY "pipeline" its + requests (i.e., send multiple requests without waiting for each + response). A server MAY process a sequence of pipelined requests in + parallel if they all have safe methods (Section 9.2.1 of [HTTP]), but + it MUST send the corresponding responses in the same order that the + requests were received. + + A client that pipelines requests SHOULD retry unanswered requests if + the connection closes before it receives all of the corresponding + responses. When retrying pipelined requests after a failed + connection (a connection not explicitly closed by the server in its + last complete response), a client MUST NOT pipeline immediately after + connection establishment, since the first remaining request in the + prior pipeline might have caused an error response that can be lost + again if multiple requests are sent on a prematurely closed + connection (see the TCP reset problem described in Section 9.6). + + Idempotent methods (Section 9.2.2 of [HTTP]) are significant to + pipelining because they can be automatically retried after a + connection failure. A user agent SHOULD NOT pipeline requests after + a non-idempotent method, until the final response status code for + that method has been received, unless the user agent has a means to + detect and recover from partial failure conditions involving the + pipelined sequence. + + An intermediary that receives pipelined requests MAY pipeline those + requests when forwarding them inbound, since it can rely on the + outbound user agent(s) to determine what requests can be safely + pipelined. If the inbound connection fails before receiving a + response, the pipelining intermediary MAY attempt to retry a sequence + of requests that have yet to receive a response if the requests all + have idempotent methods; otherwise, the pipelining intermediary + SHOULD forward any received responses and then close the + corresponding outbound connection(s) so that the outbound user + agent(s) can recover accordingly. + +9.4. Concurrency + + A client ought to limit the number of simultaneous open connections + that it maintains to a given server. + + Previous revisions of HTTP gave a specific number of connections as a + ceiling, but this was found to be impractical for many applications. + As a result, this specification does not mandate a particular maximum + number of connections but, instead, encourages clients to be + conservative when opening multiple connections. + + Multiple connections are typically used to avoid the "head-of-line + blocking" problem, wherein a request that takes significant server- + side processing and/or transfers very large content would block + subsequent requests on the same connection. However, each connection + consumes server resources. + + Furthermore, using multiple connections can cause undesirable side + effects in congested networks. Using larger numbers of connections + can also cause side effects in otherwise uncongested networks, + because their aggregate and initially synchronized sending behavior + can cause congestion that would not have been present if fewer + parallel connections had been used. + + Note that a server might reject traffic that it deems abusive or + characteristic of a denial-of-service attack, such as an excessive + number of open connections from a single client. + +9.5. Failures and Timeouts + + Servers will usually have some timeout value beyond which they will + no longer maintain an inactive connection. Proxy servers might make + this a higher value since it is likely that the client will be making + more connections through the same proxy server. The use of + persistent connections places no requirements on the length (or + existence) of this timeout for either the client or the server. + + A client or server that wishes to time out SHOULD issue a graceful + close on the connection. Implementations SHOULD constantly monitor + open connections for a received closure signal and respond to it as + appropriate, since prompt closure of both sides of a connection + enables allocated system resources to be reclaimed. + + A client, server, or proxy MAY close the transport connection at any + time. For example, a client might have started to send a new request + at the same time that the server has decided to close the "idle" + connection. From the server's point of view, the connection is being + closed while it was idle, but from the client's point of view, a + request is in progress. + + A server SHOULD sustain persistent connections, when possible, and + allow the underlying transport's flow-control mechanisms to resolve + temporary overloads rather than terminate connections with the + expectation that clients will retry. The latter technique can + exacerbate network congestion or server load. + + A client sending a message body SHOULD monitor the network connection + for an error response while it is transmitting the request. If the + client sees a response that indicates the server does not wish to + receive the message body and is closing the connection, the client + SHOULD immediately cease transmitting the body and close its side of + the connection. + +9.6. Tear-down + + The "close" connection option is defined as a signal that the sender + will close this connection after completion of the response. A + sender SHOULD send a Connection header field (Section 7.6.1 of + [HTTP]) containing the "close" connection option when it intends to + close a connection. For example, + + Connection: close + + as a request header field indicates that this is the last request + that the client will send on this connection, while in a response, + the same field indicates that the server is going to close this + connection after the response message is complete. + + Note that the field name "Close" is reserved, since using that name + as a header field might conflict with the "close" connection option. + + A client that sends a "close" connection option MUST NOT send further + requests on that connection (after the one containing the "close") + and MUST close the connection after reading the final response + message corresponding to this request. + + A server that receives a "close" connection option MUST initiate + closure of the connection (see below) after it sends the final + response to the request that contained the "close" connection option. + The server SHOULD send a "close" connection option in its final + response on that connection. The server MUST NOT process any further + requests received on that connection. + + A server that sends a "close" connection option MUST initiate closure + of the connection (see below) after it sends the response containing + the "close" connection option. The server MUST NOT process any + further requests received on that connection. + + A client that receives a "close" connection option MUST cease sending + requests on that connection and close the connection after reading + the response message containing the "close" connection option; if + additional pipelined requests had been sent on the connection, the + client SHOULD NOT assume that they will be processed by the server. + + If a server performs an immediate close of a TCP connection, there is + a significant risk that the client will not be able to read the last + HTTP response. If the server receives additional data from the + client on a fully closed connection, such as another request sent by + the client before receiving the server's response, the server's TCP + stack will send a reset packet to the client; unfortunately, the + reset packet might erase the client's unacknowledged input buffers + before they can be read and interpreted by the client's HTTP parser. + + To avoid the TCP reset problem, servers typically close a connection + in stages. First, the server performs a half-close by closing only + the write side of the read/write connection. The server then + continues to read from the connection until it receives a + corresponding close by the client, or until the server is reasonably + certain that its own TCP stack has received the client's + acknowledgement of the packet(s) containing the server's last + response. Finally, the server fully closes the connection. + + It is unknown whether the reset problem is exclusive to TCP or might + also be found in other transport connection protocols. + + Note that a TCP connection that is half-closed by the client does not + delimit a request message, nor does it imply that the client is no + longer interested in a response. In general, transport signals + cannot be relied upon to signal edge cases, since HTTP/1.1 is + independent of transport. + +9.7. TLS Connection Initiation + + Conceptually, HTTP/TLS is simply sending HTTP messages over a + connection secured via TLS [TLS13]. + + The HTTP client also acts as the TLS client. It initiates a + connection to the server on the appropriate port and sends the TLS + ClientHello to begin the TLS handshake. When the TLS handshake has + finished, the client may then initiate the first HTTP request. All + HTTP data MUST be sent as TLS "application data" but is otherwise + treated like a normal connection for HTTP (including potential reuse + as a persistent connection). + +9.8. TLS Connection Closure + + TLS uses an exchange of closure alerts prior to (non-error) + connection closure to provide secure connection closure; see + Section 6.1 of [TLS13]. When a valid closure alert is received, an + implementation can be assured that no further data will be received + on that connection. + + When an implementation knows that it has sent or received all the + message data that it cares about, typically by detecting HTTP message + boundaries, it might generate an "incomplete close" by sending a + closure alert and then closing the connection without waiting to + receive the corresponding closure alert from its peer. + + An incomplete close does not call into question the security of the + data already received, but it could indicate that subsequent data + might have been truncated. As TLS is not directly aware of HTTP + message framing, it is necessary to examine the HTTP data itself to + determine whether messages are complete. Handling of incomplete + messages is defined in Section 8. + + When encountering an incomplete close, a client SHOULD treat as + completed all requests for which it has received either + + 1. as much data as specified in the Content-Length header field or + + 2. the terminal zero-length chunk (when Transfer-Encoding of chunked + is used). + + A response that has neither chunked transfer coding nor Content- + Length is complete only if a valid closure alert has been received. + Treating an incomplete message as complete could expose + implementations to attack. + + A client detecting an incomplete close SHOULD recover gracefully. + + Clients MUST send a closure alert before closing the connection. + Clients that do not expect to receive any more data MAY choose not to + wait for the server's closure alert and simply close the connection, + thus generating an incomplete close on the server side. + + Servers SHOULD be prepared to receive an incomplete close from the + client, since the client can often locate the end of server data. + + Servers MUST attempt to initiate an exchange of closure alerts with + the client before closing the connection. Servers MAY close the + connection after sending the closure alert, thus generating an + incomplete close on the client side. + +10. Enclosing Messages as Data + +10.1. Media Type message/http + + The "message/http" media type can be used to enclose a single HTTP + request or response message, provided that it obeys the MIME + restrictions for all "message" types regarding line length and + encodings. Because of the line length limitations, field values + within "message/http" are allowed to use line folding (obs-fold), as + described in Section 5.2, to convey the field value over multiple + lines. A recipient of "message/http" data MUST replace any obsolete + line folding with one or more SP characters when the message is + consumed. + + Type name: message + + Subtype name: http + + Required parameters: N/A + + Optional parameters: version, msgtype + + version: The HTTP-version number of the enclosed message (e.g., + "1.1"). If not present, the version can be determined from the + first line of the body. + + msgtype: The message type -- "request" or "response". If not + present, the type can be determined from the first line of the + body. + + Encoding considerations: only "7bit", "8bit", or "binary" are + permitted + + Security considerations: see Section 11 + + Interoperability considerations: N/A + + Published specification: RFC 9112 (see Section 10.1). + + Applications that use this media type: N/A + + Fragment identifier considerations: N/A + + Additional information: Magic number(s): N/A + + Deprecated alias names for this type: N/A + + File extension(s): N/A + + Macintosh file type code(s): N/A + + Person and email address to contact for further information: See Aut + hors' Addresses section. + + Intended usage: COMMON + + Restrictions on usage: N/A + + Author: See Authors' Addresses section. + + Change controller: IESG + +10.2. Media Type application/http + + The "application/http" media type can be used to enclose a pipeline + of one or more HTTP request or response messages (not intermixed). + + Type name: application + + Subtype name: http + + Required parameters: N/A + + Optional parameters: version, msgtype + + version: The HTTP-version number of the enclosed messages (e.g., + "1.1"). If not present, the version can be determined from the + first line of the body. + + msgtype: The message type -- "request" or "response". If not + present, the type can be determined from the first line of the + body. + + Encoding considerations: HTTP messages enclosed by this type are in + "binary" format; use of an appropriate Content-Transfer-Encoding + is required when transmitted via email. + + Security considerations: see Section 11 + + Interoperability considerations: N/A + + Published specification: RFC 9112 (see Section 10.2). + + Applications that use this media type: N/A + + Fragment identifier considerations: N/A + + Additional information: Deprecated alias names for this type: N/A + + Magic number(s): N/A + + File extension(s): N/A + + Macintosh file type code(s): N/A + + Person and email address to contact for further information: See Aut + hors' Addresses section. + + Intended usage: COMMON + + Restrictions on usage: N/A + + Author: See Authors' Addresses section. + + Change controller: IESG + +11. Security Considerations + + This section is meant to inform developers, information providers, + and users about known security considerations relevant to HTTP + message syntax and parsing. Security considerations about HTTP + semantics, content, and routing are addressed in [HTTP]. + +11.1. Response Splitting + + Response splitting (a.k.a. CRLF injection) is a common technique, + used in various attacks on Web usage, that exploits the line-based + nature of HTTP message framing and the ordered association of + requests to responses on persistent connections [Klein]. This + technique can be particularly damaging when the requests pass through + a shared cache. + + Response splitting exploits a vulnerability in servers (usually + within an application server) where an attacker can send encoded data + within some parameter of the request that is later decoded and echoed + within any of the response header fields of the response. If the + decoded data is crafted to look like the response has ended and a + subsequent response has begun, the response has been split, and the + content within the apparent second response is controlled by the + attacker. The attacker can then make any other request on the same + persistent connection and trick the recipients (including + intermediaries) into believing that the second half of the split is + an authoritative answer to the second request. + + For example, a parameter within the request-target might be read by + an application server and reused within a redirect, resulting in the + same parameter being echoed in the Location header field of the + response. If the parameter is decoded by the application and not + properly encoded when placed in the response field, the attacker can + send encoded CRLF octets and other content that will make the + application's single response look like two or more responses. + + A common defense against response splitting is to filter requests for + data that looks like encoded CR and LF (e.g., "%0D" and "%0A"). + However, that assumes the application server is only performing URI + decoding rather than more obscure data transformations like charset + transcoding, XML entity translation, base64 decoding, sprintf + reformatting, etc. A more effective mitigation is to prevent + anything other than the server's core protocol libraries from sending + a CR or LF within the header section, which means restricting the + output of header fields to APIs that filter for bad octets and not + allowing application servers to write directly to the protocol + stream. + +11.2. Request Smuggling + + Request smuggling ([Linhart]) is a technique that exploits + differences in protocol parsing among various recipients to hide + additional requests (which might otherwise be blocked or disabled by + policy) within an apparently harmless request. Like response + splitting, request smuggling can lead to a variety of attacks on HTTP + usage. + + This specification has introduced new requirements on request + parsing, particularly with regard to message framing in Section 6.3, + to reduce the effectiveness of request smuggling. + +11.3. Message Integrity + + HTTP does not define a specific mechanism for ensuring message + integrity, instead relying on the error-detection ability of + underlying transport protocols and the use of length or chunk- + delimited framing to detect completeness. Historically, the lack of + a single integrity mechanism has been justified by the informal + nature of most HTTP communication. However, the prevalence of HTTP + as an information access mechanism has resulted in its increasing use + within environments where verification of message integrity is + crucial. + + The mechanisms provided with the "https" scheme, such as + authenticated encryption, provide protection against modification of + messages. Care is needed, however, to ensure that connection closure + cannot be used to truncate messages (see Section 9.8). User agents + might refuse to accept incomplete messages or treat them specially. + For example, a browser being used to view medical history or drug + interaction information needs to indicate to the user when such + information is detected by the protocol to be incomplete, expired, or + corrupted during transfer. Such mechanisms might be selectively + enabled via user agent extensions or the presence of message + integrity metadata in a response. + + The "http" scheme provides no protection against accidental or + malicious modification of messages. + + Extensions to the protocol might be used to mitigate the risk of + unwanted modification of messages by intermediaries, even when the + "https" scheme is used. Integrity might be assured by using message + authentication codes or digital signatures that are selectively added + to messages via extensible metadata fields. + +11.4. Message Confidentiality + + HTTP relies on underlying transport protocols to provide message + confidentiality when that is desired. HTTP has been specifically + designed to be independent of the transport protocol, such that it + can be used over many forms of encrypted connection, with the + selection of such transports being identified by the choice of URI + scheme or within user agent configuration. + + The "https" scheme can be used to identify resources that require a + confidential connection, as described in Section 4.2.2 of [HTTP]. + +12. IANA Considerations + + The change controller for the following registrations is: "IETF + (iesg@ietf.org) - Internet Engineering Task Force". + +12.1. Field Name Registration + + IANA has added the following field names to the "Hypertext Transfer + Protocol (HTTP) Field Name Registry" at + <https://www.iana.org/assignments/http-fields>, as described in + Section 18.4 of [HTTP]. + + +===================+===========+=========+============+ + | Field Name | Status | Section | Comments | + +===================+===========+=========+============+ + | Close | permanent | 9.6 | (reserved) | + +-------------------+-----------+---------+------------+ + | MIME-Version | permanent | B.1 | | + +-------------------+-----------+---------+------------+ + | Transfer-Encoding | permanent | 6.1 | | + +-------------------+-----------+---------+------------+ + + Table 1 + +12.2. Media Type Registration + + IANA has updated the "Media Types" registry at + <https://www.iana.org/assignments/media-types> with the registration + information in Sections 10.1 and 10.2 for the media types "message/ + http" and "application/http", respectively. + +12.3. Transfer Coding Registration + + IANA has updated the "HTTP Transfer Coding Registry" at + <https://www.iana.org/assignments/http-parameters/> with the + registration procedure of Section 7.3 and the content coding names + summarized in the table below. + + +============+===========================================+=========+ + | Name | Description | Section | + +============+===========================================+=========+ + | chunked | Transfer in a series of chunks | 7.1 | + +------------+-------------------------------------------+---------+ + | compress | UNIX "compress" data format [Welch] | 7.2 | + +------------+-------------------------------------------+---------+ + | deflate | "deflate" compressed data ([RFC1951]) | 7.2 | + | | inside the "zlib" data format ([RFC1950]) | | + +------------+-------------------------------------------+---------+ + | gzip | GZIP file format [RFC1952] | 7.2 | + +------------+-------------------------------------------+---------+ + | trailers | (reserved) | 12.3 | + +------------+-------------------------------------------+---------+ + | x-compress | Deprecated (alias for compress) | 7.2 | + +------------+-------------------------------------------+---------+ + | x-gzip | Deprecated (alias for gzip) | 7.2 | + +------------+-------------------------------------------+---------+ + + Table 2 + + | *Note:* the coding name "trailers" is reserved because its use + | would conflict with the keyword "trailers" in the TE header + | field (Section 10.1.4 of [HTTP]). + +12.4. ALPN Protocol ID Registration + + IANA has updated the "TLS Application-Layer Protocol Negotiation + (ALPN) Protocol IDs" registry at <https://www.iana.org/assignments/ + tls-extensiontype-values/> with the registration below: + + +==========+=============================+===========+ + | Protocol | Identification Sequence | Reference | + +==========+=============================+===========+ + | HTTP/1.1 | 0x68 0x74 0x74 0x70 0x2f | RFC 9112 | + | | 0x31 0x2e 0x31 ("http/1.1") | | + +----------+-----------------------------+-----------+ + + Table 3 + +13. References + +13.1. Normative References + + [CACHING] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, + Ed., "HTTP Caching", STD 98, RFC 9111, + DOI 10.17487/RFC9111, June 2022, + <https://www.rfc-editor.org/info/rfc9111>. + + [HTTP] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, + Ed., "HTTP Semantics", STD 97, RFC 9110, + DOI 10.17487/RFC9110, June 2022, + <https://www.rfc-editor.org/info/rfc9110>. + + [RFC1950] Deutsch, P. and J-L. Gailly, "ZLIB Compressed Data Format + Specification version 3.3", RFC 1950, + DOI 10.17487/RFC1950, May 1996, + <https://www.rfc-editor.org/info/rfc1950>. + + [RFC1951] Deutsch, P., "DEFLATE Compressed Data Format Specification + version 1.3", RFC 1951, DOI 10.17487/RFC1951, May 1996, + <https://www.rfc-editor.org/info/rfc1951>. + + [RFC1952] Deutsch, P., "GZIP file format specification version 4.3", + RFC 1952, DOI 10.17487/RFC1952, May 1996, + <https://www.rfc-editor.org/info/rfc1952>. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + <https://www.rfc-editor.org/info/rfc2119>. + + [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax + Specifications: ABNF", STD 68, RFC 5234, + DOI 10.17487/RFC5234, January 2008, + <https://www.rfc-editor.org/info/rfc5234>. + + [RFC7405] Kyzivat, P., "Case-Sensitive String Support in ABNF", + RFC 7405, DOI 10.17487/RFC7405, December 2014, + <https://www.rfc-editor.org/info/rfc7405>. + + [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC + 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, + May 2017, <https://www.rfc-editor.org/info/rfc8174>. + + [TLS13] Rescorla, E., "The Transport Layer Security (TLS) Protocol + Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, + <https://www.rfc-editor.org/info/rfc8446>. + + [URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform + Resource Identifier (URI): Generic Syntax", STD 66, + RFC 3986, DOI 10.17487/RFC3986, January 2005, + <https://www.rfc-editor.org/info/rfc3986>. + + [USASCII] American National Standards Institute, "Coded Character + Set -- 7-bit American Standard Code for Information + Interchange", ANSI X3.4, 1986. + + [Welch] Welch, T., "A Technique for High-Performance Data + Compression", IEEE Computer 17(6), + DOI 10.1109/MC.1984.1659158, June 1984, + <https://ieeexplore.ieee.org/document/1659158/>. + +13.2. Informative References + + [HTTP/1.0] Berners-Lee, T., Fielding, R., and H. Frystyk, "Hypertext + Transfer Protocol -- HTTP/1.0", RFC 1945, + DOI 10.17487/RFC1945, May 1996, + <https://www.rfc-editor.org/info/rfc1945>. + + [Klein] Klein, A., "Divide and Conquer - HTTP Response Splitting, + Web Cache Poisoning Attacks, and Related Topics", March + 2004, <https://packetstormsecurity.com/papers/general/ + whitepaper_httpresponse.pdf>. + + [Linhart] Linhart, C., Klein, A., Heled, R., and S. Orrin, "HTTP + Request Smuggling", June 2005, + <https://www.cgisecurity.com/lib/HTTP-Request- + Smuggling.pdf>. + + [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail + Extensions (MIME) Part One: Format of Internet Message + Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996, + <https://www.rfc-editor.org/info/rfc2045>. + + [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail + Extensions (MIME) Part Two: Media Types", RFC 2046, + DOI 10.17487/RFC2046, November 1996, + <https://www.rfc-editor.org/info/rfc2046>. + + [RFC2049] Freed, N. and N. Borenstein, "Multipurpose Internet Mail + Extensions (MIME) Part Five: Conformance Criteria and + Examples", RFC 2049, DOI 10.17487/RFC2049, November 1996, + <https://www.rfc-editor.org/info/rfc2049>. + + [RFC2068] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., and T. + Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", + RFC 2068, DOI 10.17487/RFC2068, January 1997, + <https://www.rfc-editor.org/info/rfc2068>. + + [RFC2557] Palme, J., Hopmann, A., and N. Shelness, "MIME + Encapsulation of Aggregate Documents, such as HTML + (MHTML)", RFC 2557, DOI 10.17487/RFC2557, March 1999, + <https://www.rfc-editor.org/info/rfc2557>. + + [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, + DOI 10.17487/RFC5322, October 2008, + <https://www.rfc-editor.org/info/rfc5322>. + + [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer + Protocol (HTTP/1.1): Message Syntax and Routing", + RFC 7230, DOI 10.17487/RFC7230, June 2014, + <https://www.rfc-editor.org/info/rfc7230>. + + [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for + Writing an IANA Considerations Section in RFCs", BCP 26, + RFC 8126, DOI 10.17487/RFC8126, June 2017, + <https://www.rfc-editor.org/info/rfc8126>. + +Appendix A. Collected ABNF + + In the collected ABNF below, list rules are expanded per + Section 5.6.1 of [HTTP]. + + BWS = <BWS, see [HTTP], Section 5.6.3> + + HTTP-message = start-line CRLF *( field-line CRLF ) CRLF [ + message-body ] + HTTP-name = %x48.54.54.50 ; HTTP + HTTP-version = HTTP-name "/" DIGIT "." DIGIT + + OWS = <OWS, see [HTTP], Section 5.6.3> + + RWS = <RWS, see [HTTP], Section 5.6.3> + + Transfer-Encoding = [ transfer-coding *( OWS "," OWS transfer-coding + ) ] + + absolute-URI = <absolute-URI, see [URI], Section 4.3> + absolute-form = absolute-URI + absolute-path = <absolute-path, see [HTTP], Section 4.1> + asterisk-form = "*" + authority = <authority, see [URI], Section 3.2> + authority-form = uri-host ":" port + + chunk = chunk-size [ chunk-ext ] CRLF chunk-data CRLF + chunk-data = 1*OCTET + chunk-ext = *( BWS ";" BWS chunk-ext-name [ BWS "=" BWS chunk-ext-val + ] ) + chunk-ext-name = token + chunk-ext-val = token / quoted-string + chunk-size = 1*HEXDIG + chunked-body = *chunk last-chunk trailer-section CRLF + + field-line = field-name ":" OWS field-value OWS + field-name = <field-name, see [HTTP], Section 5.1> + field-value = <field-value, see [HTTP], Section 5.5> + + last-chunk = 1*"0" [ chunk-ext ] CRLF + + message-body = *OCTET + method = token + + obs-fold = OWS CRLF RWS + obs-text = <obs-text, see [HTTP], Section 5.6.4> + origin-form = absolute-path [ "?" query ] + + port = <port, see [URI], Section 3.2.3> + + query = <query, see [URI], Section 3.4> + quoted-string = <quoted-string, see [HTTP], Section 5.6.4> + + reason-phrase = 1*( HTAB / SP / VCHAR / obs-text ) + request-line = method SP request-target SP HTTP-version + request-target = origin-form / absolute-form / authority-form / + asterisk-form + + start-line = request-line / status-line + status-code = 3DIGIT + status-line = HTTP-version SP status-code SP [ reason-phrase ] + + token = <token, see [HTTP], Section 5.6.2> + trailer-section = *( field-line CRLF ) + transfer-coding = <transfer-coding, see [HTTP], Section 10.1.4> + + uri-host = <host, see [URI], Section 3.2.2> + +Appendix B. Differences between HTTP and MIME + + HTTP/1.1 uses many of the constructs defined for the Internet Message + Format [RFC5322] and Multipurpose Internet Mail Extensions (MIME) + [RFC2045] to allow a message body to be transmitted in an open + variety of representations and with extensible fields. However, some + of these constructs have been reinterpreted to better fit the needs + of interactive communication, leading to some differences in how MIME + constructs are used within HTTP. These differences were carefully + chosen to optimize performance over binary connections, allow greater + freedom in the use of new media types, ease date comparisons, and + accommodate common implementations. + + This appendix describes specific areas where HTTP differs from MIME. + Proxies and gateways to and from strict MIME environments need to be + aware of these differences and provide the appropriate conversions + where necessary. + +B.1. MIME-Version + + HTTP is not a MIME-compliant protocol. However, messages can include + a single MIME-Version header field to indicate what version of the + MIME protocol was used to construct the message. Use of the MIME- + Version header field indicates that the message is in full + conformance with the MIME protocol (as defined in [RFC2045]). + Senders are responsible for ensuring full conformance (where + possible) when exporting HTTP messages to strict MIME environments. + +B.2. Conversion to Canonical Form + + MIME requires that an Internet mail body part be converted to + canonical form prior to being transferred, as described in Section 4 + of [RFC2049], and that content with a type of "text" represents line + breaks as CRLF, forbidding the use of CR or LF outside of line break + sequences [RFC2046]. In contrast, HTTP does not care whether CRLF, + bare CR, or bare LF are used to indicate a line break within content. + + A proxy or gateway from HTTP to a strict MIME environment ought to + translate all line breaks within text media types to the RFC 2049 + canonical form of CRLF. Note, however, this might be complicated by + the presence of a Content-Encoding and by the fact that HTTP allows + the use of some charsets that do not use octets 13 and 10 to + represent CR and LF, respectively. + + Conversion will break any cryptographic checksums applied to the + original content unless the original content is already in canonical + form. Therefore, the canonical form is recommended for any content + that uses such checksums in HTTP. + +B.3. Conversion of Date Formats + + HTTP/1.1 uses a restricted set of date formats (Section 5.6.7 of + [HTTP]) to simplify the process of date comparison. Proxies and + gateways from other protocols ought to ensure that any Date header + field present in a message conforms to one of the HTTP/1.1 formats + and rewrite the date if necessary. + +B.4. Conversion of Content-Encoding + + MIME does not include any concept equivalent to HTTP's Content- + Encoding header field. Since this acts as a modifier on the media + type, proxies and gateways from HTTP to MIME-compliant protocols + ought to either change the value of the Content-Type header field or + decode the representation before forwarding the message. (Some + experimental applications of Content-Type for Internet mail have used + a media-type parameter of ";conversions=<content-coding>" to perform + a function equivalent to Content-Encoding. However, this parameter + is not part of the MIME standards.) + +B.5. Conversion of Content-Transfer-Encoding + + HTTP does not use the Content-Transfer-Encoding field of MIME. + Proxies and gateways from MIME-compliant protocols to HTTP need to + remove any Content-Transfer-Encoding prior to delivering the response + message to an HTTP client. + + Proxies and gateways from HTTP to MIME-compliant protocols are + responsible for ensuring that the message is in the correct format + and encoding for safe transport on that protocol, where "safe + transport" is defined by the limitations of the protocol being used. + Such a proxy or gateway ought to transform and label the data with an + appropriate Content-Transfer-Encoding if doing so will improve the + likelihood of safe transport over the destination protocol. + +B.6. MHTML and Line Length Limitations + + HTTP implementations that share code with MHTML [RFC2557] + implementations need to be aware of MIME line length limitations. + Since HTTP does not have this limitation, HTTP does not fold long + lines. MHTML messages being transported by HTTP follow all + conventions of MHTML, including line length limitations and folding, + canonicalization, etc., since HTTP transfers message-bodies without + modification and, aside from the "multipart/byteranges" type + (Section 14.6 of [HTTP]), does not interpret the content or any MIME + header lines that might be contained therein. + +Appendix C. Changes from Previous RFCs + +C.1. Changes from HTTP/0.9 + + Since HTTP/0.9 did not support header fields in a request, there is + no mechanism for it to support name-based virtual hosts (selection of + resource by inspection of the Host header field). Any server that + implements name-based virtual hosts ought to disable support for + HTTP/0.9. Most requests that appear to be HTTP/0.9 are, in fact, + badly constructed HTTP/1.x requests caused by a client failing to + properly encode the request-target. + +C.2. Changes from HTTP/1.0 + +C.2.1. Multihomed Web Servers + + The requirements that clients and servers support the Host header + field (Section 7.2 of [HTTP]), report an error if it is missing from + an HTTP/1.1 request, and accept absolute URIs (Section 3.2) are among + the most important changes defined by HTTP/1.1. + + Older HTTP/1.0 clients assumed a one-to-one relationship of IP + addresses and servers; there was no established mechanism for + distinguishing the intended server of a request other than the IP + address to which that request was directed. The Host header field + was introduced during the development of HTTP/1.1 and, though it was + quickly implemented by most HTTP/1.0 browsers, additional + requirements were placed on all HTTP/1.1 requests in order to ensure + complete adoption. At the time of this writing, most HTTP-based + services are dependent upon the Host header field for targeting + requests. + +C.2.2. Keep-Alive Connections + + In HTTP/1.0, each connection is established by the client prior to + the request and closed by the server after sending the response. + However, some implementations implement the explicitly negotiated + ("Keep-Alive") version of persistent connections described in + Section 19.7.1 of [RFC2068]. + + Some clients and servers might wish to be compatible with these + previous approaches to persistent connections, by explicitly + negotiating for them with a "Connection: keep-alive" request header + field. However, some experimental implementations of HTTP/1.0 + persistent connections are faulty; for example, if an HTTP/1.0 proxy + server doesn't understand Connection, it will erroneously forward + that header field to the next inbound server, which would result in a + hung connection. + + One attempted solution was the introduction of a Proxy-Connection + header field, targeted specifically at proxies. In practice, this + was also unworkable, because proxies are often deployed in multiple + layers, bringing about the same problem discussed above. + + As a result, clients are encouraged not to send the Proxy-Connection + header field in any requests. + + Clients are also encouraged to consider the use of "Connection: keep- + alive" in requests carefully; while they can enable persistent + connections with HTTP/1.0 servers, clients using them will need to + monitor the connection for "hung" requests (which indicate that the + client ought to stop sending the header field), and this mechanism + ought not be used by clients at all when a proxy is being used. + +C.2.3. Introduction of Transfer-Encoding + + HTTP/1.1 introduces the Transfer-Encoding header field (Section 6.1). + Transfer codings need to be decoded prior to forwarding an HTTP + message over a MIME-compliant protocol. + +C.3. Changes from RFC 7230 + + Most of the sections introducing HTTP's design goals, history, + architecture, conformance criteria, protocol versioning, URIs, + message routing, and header fields have been moved to [HTTP]. This + document has been reduced to just the messaging syntax and connection + management requirements specific to HTTP/1.1. + + Bare CRs have been prohibited outside of content. (Section 2.2) + + The ABNF definition of authority-form has changed from the more + general authority component of a URI (in which port is optional) to + the specific host:port format that is required by CONNECT. + (Section 3.2.3) + + Recipients are required to avoid smuggling/splitting attacks when + processing an ambiguous message framing. (Section 6.1) + + In the ABNF for chunked extensions, (bad) whitespace around ";" and + "=" has been reintroduced. Whitespace was removed in [RFC7230], but + that change was found to break existing implementations. + (Section 7.1.1) + + Trailer field semantics now transcend the specifics of chunked + transfer coding. The decoding algorithm for chunked (Section 7.1.3) + has been updated to encourage storage/forwarding of trailer fields + separately from the header section, to only allow merging into the + header section if the recipient knows the corresponding field + definition permits and defines how to merge, and otherwise to discard + the trailer fields instead of merging. The trailer part is now + called the trailer section to be more consistent with the header + section and more distinct from a body part. (Section 7.1.2) + + Transfer coding parameters called "q" are disallowed in order to + avoid conflicts with the use of ranks in the TE header field. + (Section 7.3) + +Acknowledgements + + See Appendix "Acknowledgements" of [HTTP], which applies to this + document as well. + +Index + + A C D F G H M O R T X + + A + + absolute-form (of request-target) Section 3.2.2 + application/http Media Type *_Section 10.2_* + asterisk-form (of request-target) Section 3.2.4 + authority-form (of request-target) Section 3.2.3 + + C + + chunked (Coding Format) Section 6.1; Section 6.3 + chunked (transfer coding) *_Section 7.1_* + close Section 9.3; *_Section 9.6_* + compress (transfer coding) *_Section 7.2_* + Connection header field Section 9.6 + Content-Length header field Section 6.2 + Content-Transfer-Encoding header field Appendix B.5 + + D + + deflate (transfer coding) *_Section 7.2_* + + F + + Fields + Close *_Section 9.6, Paragraph 4_* + MIME-Version *_Appendix B.1_* + Transfer-Encoding *_Section 6.1_* + + G + + Grammar + ALPHA *_Section 1.2_* + CR *_Section 1.2_* + CRLF *_Section 1.2_* + CTL *_Section 1.2_* + DIGIT *_Section 1.2_* + DQUOTE *_Section 1.2_* + HEXDIG *_Section 1.2_* + HTAB *_Section 1.2_* + HTTP-message *_Section 2.1_* + HTTP-name *_Section 2.3_* + HTTP-version *_Section 2.3_* + LF *_Section 1.2_* + OCTET *_Section 1.2_* + SP *_Section 1.2_* + Transfer-Encoding *_Section 6.1_* + VCHAR *_Section 1.2_* + absolute-form Section 3.2; *_Section 3.2.2_* + asterisk-form Section 3.2; *_Section 3.2.4_* + authority-form Section 3.2; *_Section 3.2.3_* + chunk *_Section 7.1_* + chunk-data *_Section 7.1_* + chunk-ext Section 7.1; *_Section 7.1.1_* + chunk-ext-name *_Section 7.1.1_* + chunk-ext-val *_Section 7.1.1_* + chunk-size *_Section 7.1_* + chunked-body *_Section 7.1_* + field-line *_Section 5_*; Section 7.1.2 + field-name Section 5 + field-value Section 5 + last-chunk *_Section 7.1_* + message-body *_Section 6_* + method *_Section 3.1_* + obs-fold *_Section 5.2_* + origin-form Section 3.2; *_Section 3.2.1_* + reason-phrase *_Section 4_* + request-line *_Section 3_* + request-target *_Section 3.2_* + start-line *_Section 2.1_* + status-code *_Section 4_* + status-line *_Section 4_* + trailer-section Section 7.1; *_Section 7.1.2_* + gzip (transfer coding) *_Section 7.2_* + + H + + Header Fields + MIME-Version *_Appendix B.1_* + Transfer-Encoding *_Section 6.1_* + header line Section 2.1 + header section Section 2.1 + headers Section 2.1 + + M + + Media Type + application/http *_Section 10.2_* + message/http *_Section 10.1_* + message/http Media Type *_Section 10.1_* + method *_Section 3.1_* + MIME-Version header field *_Appendix B.1_* + + O + + origin-form (of request-target) Section 3.2.1 + + R + + request-target *_Section 3.2_* + + T + + Transfer-Encoding header field *_Section 6.1_* + + X + + x-compress (transfer coding) *_Section 7.2_* + x-gzip (transfer coding) *_Section 7.2_* + +Authors' Addresses + + Roy T. Fielding (editor) + Adobe + 345 Park Ave + San Jose, CA 95110 + United States of America + Email: fielding@gbiv.com + URI: https://roy.gbiv.com/ + + + Mark Nottingham (editor) + Fastly + Prahran + Australia + Email: mnot@mnot.net + URI: https://www.mnot.net/ + + + Julian Reschke (editor) + greenbytes GmbH + Hafenweg 16 + 48155 Münster + Germany + Email: julian.reschke@greenbytes.de + URI: https://greenbytes.de/tech/webdav/ |