rfc9112v1.txt   rfc9112.txt 
Internet Engineering Task Force (IETF) R. Fielding, Ed. Internet Engineering Task Force (IETF) R. Fielding, Ed.
Request for Comments: 9112 Adobe Request for Comments: 9112 Adobe
STD: 97 M. Nottingham, Ed. STD: 97 M. Nottingham, Ed.
Obsoletes: 7230 Fastly Obsoletes: 7230 Fastly
Category: Standards Track J. Reschke, Ed. Category: Standards Track J. Reschke, Ed.
ISSN: 2070-1721 greenbytes ISSN: 2070-1721 greenbytes
October 2021 January 2022
HTTP/1.1 HTTP/1.1
Abstract Abstract
The Hypertext Transfer Protocol (HTTP) is a stateless application- The Hypertext Transfer Protocol (HTTP) is a stateless application-
level protocol for distributed, collaborative, hypertext information level protocol for distributed, collaborative, hypertext information
systems. This document specifies the HTTP/1.1 message syntax, systems. This document specifies the HTTP/1.1 message syntax,
message parsing, connection management, and related security message parsing, connection management, and related security
concerns. concerns.
skipping to change at line 38 skipping to change at line 38
received public review and has been approved for publication by the received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841. Internet Standards is available in Section 2 of RFC 7841.
Information about the current status of this document, any errata, Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9112. https://www.rfc-editor.org/info/rfc9112.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2022 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Revised BSD License text as described in Section 4.e of the include Revised BSD License text as described in Section 4.e of the
Trust Legal Provisions and are provided without warranty as described Trust Legal Provisions and are provided without warranty as described
skipping to change at line 732 skipping to change at line 732
before the first non-whitespace octet of the field line value, or before the first non-whitespace octet of the field line value, or
after the last non-whitespace octet of the field line value, is after the last non-whitespace octet of the field line value, is
excluded by parsers when extracting the field line value from a field excluded by parsers when extracting the field line value from a field
line. line.
5.2. Obsolete Line Folding 5.2. Obsolete Line Folding
Historically, HTTP/1.x field values could be extended over multiple Historically, HTTP/1.x field values could be extended over multiple
lines by preceding each extra line with at least one space or lines by preceding each extra line with at least one space or
horizontal tab (obs-fold). This specification deprecates such line horizontal tab (obs-fold). This specification deprecates such line
folding except within the message/http media type (Section 10.1). folding except within the "message/http" media type (Section 10.1).
obs-fold = OWS CRLF RWS obs-fold = OWS CRLF RWS
; obsolete line folding ; obsolete line folding
A sender MUST NOT generate a message that includes 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 (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 obs-fold rule) unless the message is intended for packaging within
the message/http media type. the message/http media type.
A server that receives an obs-fold in a request message that is not A server that receives an obs-fold in a request message that is not
skipping to change at line 1343 skipping to change at line 1343
HTTP/1.1 defaults to the use of _persistent connections_, allowing HTTP/1.1 defaults to the use of _persistent connections_, allowing
multiple requests and responses to be carried over a single multiple requests and responses to be carried over a single
connection. HTTP implementations SHOULD support persistent connection. HTTP implementations SHOULD support persistent
connections. connections.
A recipient determines whether a connection is persistent or not A recipient determines whether a connection is persistent or not
based on the protocol version and Connection header field based on the protocol version and Connection header field
(Section 7.6.1 of [HTTP]) in the most recently received message, if (Section 7.6.1 of [HTTP]) in the most recently received message, if
any: any:
* If the close connection option is present (Section 9.6), the * If the "close" connection option is present (Section 9.6), the
connection will not persist after the current response; else, connection will not persist after the current response; else,
* If the received protocol is HTTP/1.1 (or later), the connection * If the received protocol is HTTP/1.1 (or later), the connection
will persist after the current response; else, will persist after the current response; else,
* If the received protocol is HTTP/1.0, the "keep-alive" connection * If the received protocol is HTTP/1.0, the "keep-alive" connection
option is present, either the recipient is not a proxy or the option is present, either the recipient is not a proxy or the
message is a response, and the recipient wishes to honor the message is a response, and the recipient wishes to honor the
HTTP/1.0 "keep-alive" mechanism, the connection will persist after HTTP/1.0 "keep-alive" mechanism, the connection will persist after
the current response; otherwise, the current response; otherwise,
* The connection will close after the current response. * The connection will close after the current response.
A client that does not support persistent connections MUST send the A client that does not support persistent connections MUST send the
close connection option in every request message. "close" connection option in every request message.
A server that does not support persistent connections MUST send the A server that does not support persistent connections MUST send the
close connection option in every response message that does not have "close" connection option in every response message that does not
a 1xx (Informational) status code. have a 1xx (Informational) status code.
A client MAY send additional requests on a persistent connection A client MAY send additional requests on a persistent connection
until it sends or receives a close connection option or receives an until it sends or receives a "close" connection option or receives an
HTTP/1.0 response without a "keep-alive" connection option. HTTP/1.0 response without a "keep-alive" connection option.
In order to remain persistent, all messages on a connection need to 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 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 of the connection), as described in Section 6. A server MUST read
the entire request message body or close the connection after sending the entire request message body or close the connection after sending
its response; otherwise, the remaining data on a persistent its response; otherwise, the remaining data on a persistent
connection would be misinterpreted as the next request. Likewise, a connection would be misinterpreted as the next request. Likewise, a
client MUST read the entire response message body if it intends to client MUST read the entire response message body if it intends to
reuse the same connection for a subsequent request. reuse the same connection for a subsequent request.
skipping to change at line 1499 skipping to change at line 1499
client sees a response that indicates the server does not wish to client sees a response that indicates the server does not wish to
receive the message body and is closing the connection, the client receive the message body and is closing the connection, the client
SHOULD immediately cease transmitting the body and close its side of SHOULD immediately cease transmitting the body and close its side of
the connection. the connection.
9.6. Tear-down 9.6. Tear-down
The "close" connection option is defined as a signal that the sender The "close" connection option is defined as a signal that the sender
will close this connection after completion of the response. A will close this connection after completion of the response. A
sender SHOULD send a Connection header field (Section 7.6.1 of sender SHOULD send a Connection header field (Section 7.6.1 of
[HTTP]) containing the close connection option when it intends to [HTTP]) containing the "close" connection option when it intends to
close a connection. For example, close a connection. For example,
Connection: close Connection: close
as a request header field indicates that this is the last request as a request header field indicates that this is the last request
that the client will send on this connection, while in a response, that the client will send on this connection, while in a response,
the same field indicates that the server is going to close this the same field indicates that the server is going to close this
connection after the response message is complete. connection after the response message is complete.
Note that the field name "Close" is reserved, since using that name Note that the field name "Close" is reserved, since using that name
as a header field might conflict with the close connection option. as a header field might conflict with the "close" connection option.
A client that sends a close connection option MUST NOT send further A client that sends a "close" connection option MUST NOT send further
requests on that connection (after the one containing the close) and requests on that connection (after the one containing the close) and
MUST close the connection after reading the final response message MUST close the connection after reading the final response message
corresponding to this request. corresponding to this request.
A server that receives a close connection option MUST initiate A server that receives a "close" connection option MUST initiate
closure of the connection (see below) after it sends the final closure of the connection (see below) after it sends the final
response to the request that contained the close connection option. response to the request that contained the "close" connection option.
The server SHOULD send a close connection option in its final The server SHOULD send a "close" connection option in its final
response on that connection. The server MUST NOT process any further response on that connection. The server MUST NOT process any further
requests received on that connection. requests received on that connection.
A server that sends a close connection option MUST initiate closure A server that sends a "close" connection option MUST initiate closure
of the connection (see below) after it sends the response containing of the connection (see below) after it sends the response containing
the close connection option. The server MUST NOT process any further the "close" connection option. The server MUST NOT process any
requests received on that connection. further requests received on that connection.
A client that receives a close connection option MUST cease sending A client that receives a "close" connection option MUST cease sending
requests on that connection and close the connection after reading requests on that connection and close the connection after reading
the response message containing the close connection option; if the response message containing the "close" connection option; if
additional pipelined requests had been sent on the connection, the additional pipelined requests had been sent on the connection, the
client SHOULD NOT assume that they will be processed by the server. 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 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 a significant risk that the client will not be able to read the last
HTTP response. If the server receives additional data from the HTTP response. If the server receives additional data from the
client on a fully closed connection, such as another request sent by client on a fully closed connection, such as another request sent by
the client before receiving the server's response, the server's TCP the client before receiving the server's response, the server's TCP
stack will send a reset packet to the client; unfortunately, the stack will send a reset packet to the client; unfortunately, the
reset packet might erase the client's unacknowledged input buffers reset packet might erase the client's unacknowledged input buffers
skipping to change at line 1685 skipping to change at line 1685
Intended usage: COMMON Intended usage: COMMON
Restrictions on usage: N/A Restrictions on usage: N/A
Author: See Authors' Addresses section. Author: See Authors' Addresses section.
Change controller: IESG Change controller: IESG
10.2. Media Type application/http 10.2. Media Type application/http
The application/http media type can be used to enclose a pipeline of The "application/http" media type can be used to enclose a pipeline
one or more HTTP request or response messages (not intermixed). of one or more HTTP request or response messages (not intermixed).
Type name: application Type name: application
Subtype name: http Subtype name: http
Required parameters: N/A Required parameters: N/A
Optional parameters: version, msgtype Optional parameters: version, msgtype
version: The HTTP-version number of the enclosed messages (e.g., version: The HTTP-version number of the enclosed messages (e.g.,
skipping to change at line 1845 skipping to change at line 1845
can be used over many forms of encrypted connection, with the can be used over many forms of encrypted connection, with the
selection of such transports being identified by the choice of URI selection of such transports being identified by the choice of URI
scheme or within user agent configuration. scheme or within user agent configuration.
The "https" scheme can be used to identify resources that require a The "https" scheme can be used to identify resources that require a
confidential connection, as described in Section 4.2.2 of [HTTP]. confidential connection, as described in Section 4.2.2 of [HTTP].
12. IANA Considerations 12. IANA Considerations
The change controller for the following registrations is: "IETF The change controller for the following registrations is: "IETF
(iesg@ietf.org) -- Internet Engineering Task Force". (iesg@ietf.org) - Internet Engineering Task Force".
12.1. Field Name Registration 12.1. Field Name Registration
IANA has added the following field names to the "Hypertext Transfer IANA has added the following field names to the "Hypertext Transfer
Protocol (HTTP) Field Name Registry" at Protocol (HTTP) Field Name Registry" at
<https://www.iana.org/assignments/http-fields>, as described in <https://www.iana.org/assignments/http-fields>, as described in
Section 18.4 of [HTTP]. Section 18.4 of [HTTP].
+===================+==========+==============+============+ +===================+===========+======+============+
| Field Name | Status | Ref. | Comments | | Field Name | Status | Ref. | Comments |
+===================+==========+==============+============+ +===================+===========+======+============+
| Close | standard | Section 9.6 | (reserved) | | Close | permanent | 9.6 | (reserved) |
+-------------------+----------+--------------+------------+ +-------------------+-----------+------+------------+
| MIME-Version | standard | Appendix B.1 | | | MIME-Version | permanent | B.1 | |
+-------------------+----------+--------------+------------+ +-------------------+-----------+------+------------+
| Transfer-Encoding | standard | Section 6.1 | | | Transfer-Encoding | permanent | 6.1 | |
+-------------------+----------+--------------+------------+ +-------------------+-----------+------+------------+
Table 1 Table 1
12.2. Media Type Registration 12.2. Media Type Registration
IANA has updated the "Media Types" registry at IANA has updated the "Media Types" registry at
<https://www.iana.org/assignments/media-types> with the registration <https://www.iana.org/assignments/media-types> with the registration
information in Sections 10.1 and 10.2 for the media types "message/ information in Sections 10.1 and 10.2 for the media types "message/
http" and "application/http", respectively. http" and "application/http", respectively.
12.3. Transfer Coding Registration 12.3. Transfer Coding Registration
IANA has updated the "HTTP Transfer Coding Registry" at IANA has updated the "HTTP Transfer Coding Registry" at
<https://www.iana.org/assignments/http-parameters/> with the content <https://www.iana.org/assignments/http-parameters/> with the
coding names summarized in the table below, per the registration registration procedure of Section 7.3 and the content coding names
procedure in Section 7.3. summarized in the table below.
+============+=========================================+===========+ +============+=========================================+===========+
| Name | Description | Reference | | Name | Description | Reference |
+============+=========================================+===========+ +============+=========================================+===========+
| chunked | Transfer in a series of chunks | Section | | chunked | Transfer in a series of chunks | Section |
| | | 7.1 | | | | 7.1 |
+------------+-----------------------------------------+-----------+ +------------+-----------------------------------------+-----------+
| compress | UNIX "compress" data format [Welch] | Section | | compress | UNIX "compress" data format [Welch] | Section |
| | | 7.2 | | | | 7.2 |
+------------+-----------------------------------------+-----------+ +------------+-----------------------------------------+-----------+
skipping to change at line 1932 skipping to change at line 1932
+----------+-----------------------------+-----------+ +----------+-----------------------------+-----------+
Table 3 Table 3
13. References 13. References
13.1. Normative References 13.1. Normative References
[CACHING] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, [CACHING] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "HTTP Caching", RFC 9111, DOI 10.17487/RFC9111, Ed., "HTTP Caching", RFC 9111, DOI 10.17487/RFC9111,
December 2021, <https://www.rfc-editor.org/info/rfc9111>. January 2022, <https://www.rfc-editor.org/info/rfc9111>.
[HTTP] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, [HTTP] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "HTTP Semantics", RFC 9110, DOI 10.17487/RFC9110, Ed., "HTTP Semantics", RFC 9110, DOI 10.17487/RFC9110,
December 2021, <https://www.rfc-editor.org/info/rfc9110>. January 2022, <https://www.rfc-editor.org/info/rfc9110>.
[RFC1950] Deutsch, P. and J-L. Gailly, "ZLIB Compressed Data Format [RFC1950] Deutsch, P. and J-L. Gailly, "ZLIB Compressed Data Format
Specification version 3.3", RFC 1950, Specification version 3.3", RFC 1950,
DOI 10.17487/RFC1950, May 1996, DOI 10.17487/RFC1950, May 1996,
<https://www.rfc-editor.org/info/rfc1950>. <https://www.rfc-editor.org/info/rfc1950>.
[RFC1951] Deutsch, P., "DEFLATE Compressed Data Format Specification [RFC1951] Deutsch, P., "DEFLATE Compressed Data Format Specification
version 1.3", RFC 1951, DOI 10.17487/RFC1951, May 1996, version 1.3", RFC 1951, DOI 10.17487/RFC1951, May 1996,
<https://www.rfc-editor.org/info/rfc1951>. <https://www.rfc-editor.org/info/rfc1951>.
 End of changes. 23 change blocks. 
37 lines changed or deleted 37 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/