rfc9931.original   rfc9931.txt 
HTTPBIS B. M. Schwartz Internet Engineering Task Force (IETF) B. Schwartz
Internet-Draft Meta Platforms, Inc. Request for Comments: 9931 Meta Platforms, Inc.
Updates: 9112, 9298 (if approved) 18 September 2025 Updates: 9112, 9298 February 2026
Intended status: Standards Track Category: Standards Track
Expires: 22 March 2026 ISSN: 2070-1721
Security Considerations for Optimistic Protocol Transitions in HTTP/1.1 Security Considerations for Optimistic Protocol Transitions in HTTP/1.1
draft-ietf-httpbis-optimistic-upgrade-06
Abstract Abstract
In HTTP/1.1, the client can request a change to a new protocol on the In HTTP/1.1, the client can request a change to a new protocol on the
existing connection. This document discusses the security existing connection. This document discusses the security
considerations that apply to data sent by the client before this considerations that apply to data sent by the client before this
request is confirmed, and adds new requirements to RFC 9112 and RFC request is confirmed and adds new requirements to RFCs 9112 and 9298
9298 to avoid related security issues. to avoid related security issues.
About This Document
This note is to be removed before publishing as an RFC.
Status information for this document may be found at
https://datatracker.ietf.org/doc/draft-ietf-httpbis-optimistic-
upgrade/.
Source for this draft and an issue tracker can be found at
https://github.com/httpwg/http-extensions.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on 22 March 2026. 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/rfc9931.
Copyright Notice Copyright Notice
Copyright (c) 2025 IETF Trust and the persons identified as the Copyright (c) 2026 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 (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Revised BSD License text as to this document. Code Components extracted from this document must
described in Section 4.e of the Trust Legal Provisions and are include Revised BSD License text as described in Section 4.e of the
provided without warranty as described in the Revised BSD License. Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
Table of Contents Table of Contents
1. Conventions and Definitions . . . . . . . . . . . . . . . . . 2 1. Overview
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Requirements Language
3. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Background
4. Possible Security Issues . . . . . . . . . . . . . . . . . . 5 4. Possible Security Issues
4.1. Request Smuggling . . . . . . . . . . . . . . . . . . . . 6 4.1. Request Smuggling
4.2. Parser Exploits . . . . . . . . . . . . . . . . . . . . . 7 4.2. Parser Exploits
5. Operational Issues . . . . . . . . . . . . . . . . . . . . . 8 5. Operational Issues
6. Impact on HTTP Upgrade with Existing Upgrade Tokens . . . . . 8 6. Impact on HTTP Upgrade with Existing Upgrade Tokens
6.1. "TLS" . . . . . . . . . . . . . . . . . . . . . . . . . . 8 6.1. "TLS"
6.2. "WebSocket"/"websocket" . . . . . . . . . . . . . . . . . 8 6.2. "WebSocket"/"websocket"
6.3. "connect-udp" . . . . . . . . . . . . . . . . . . . . . . 8 6.3. "connect-udp"
6.4. "connect-ip" . . . . . . . . . . . . . . . . . . . . . . 9 6.4. "connect-ip"
7. Guidance for Future Upgrade Tokens . . . . . . . . . . . . . 9 7. Guidance for Future Upgrade Tokens
7.1. Selection of Request Methods . . . . . . . . . . . . . . 9 7.1. Selection of Request Methods
8. Requirements for HTTP CONNECT . . . . . . . . . . . . . . . . 10 8. Requirements for HTTP CONNECT
9. Security Considerations . . . . . . . . . . . . . . . . . . . 11 9. Security Considerations
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 10. IANA Considerations
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 11. References
11.1. Normative References . . . . . . . . . . . . . . . . . . 11 11.1. Normative References
11.2. Informative References . . . . . . . . . . . . . . . . . 11 11.2. Informative References
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 12 Acknowledgments
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13 Author's Address
1. Conventions and Definitions
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.
2. Overview 1. Overview
This document discusses certain security considerations that arise This document discusses certain security considerations that arise
when switching from HTTP/1.1 to a different protocol on the same when switching from HTTP/1.1 to a different protocol on the same
connection. It provides: connection. It provides:
* A review of the relevant standards. * a review of the relevant standards,
* A discussion of the security risks that may apply if a client * a discussion of the security risks that may apply if a client
sends data before the transition is confirmed. sends data before the transition is confirmed,
* Security evaluation of existing upgrade tokens. * a security evaluation of existing upgrade tokens, and
* Guidance for implementations and future standards documents. * guidance for implementations and future standards documents.
Updates to RFC 9112 and RFC 9298, including new normative Updates to [HTTP/1.1] and [CONNECT-UDP], including new normative
requirements, are provided in Section 8 and Section 6.3. requirements, are provided in Sections 8 and 6.3, respectively.
2. Requirements Language
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.
3. Background 3. Background
In HTTP/1.1 [HTTP/1.1] and later, a single connection can be used for In HTTP/1.1 [HTTP/1.1] and later, a single connection can be used for
many requests. In HTTP/2 [HTTP/2] and HTTP/3 [HTTP/3], these many requests. In HTTP/2 [HTTP/2] and HTTP/3 [HTTP/3], these
requests can be multiplexed, as each request is distinguished requests can be multiplexed, as each request is distinguished
explicitly by its stream ID. However, in HTTP/1.1, requests are explicitly by its stream ID. However, in HTTP/1.1, requests are
strictly sequential, and each new request is distinguished implicitly strictly sequential, and each new request is distinguished implicitly
by the closure of the preceding request. by the closure of the preceding request.
skipping to change at page 3, line 50 skipping to change at line 125
The other mechanism is the HTTP CONNECT method (Section 9.3.6 of The other mechanism is the HTTP CONNECT method (Section 9.3.6 of
[HTTP]). This method indicates that the client wishes to establish a [HTTP]). This method indicates that the client wishes to establish a
TCP connection to the specified host and port. If accepted, the TCP connection to the specified host and port. If accepted, the
server replies with a 2xx (Successful) response to indicate that the server replies with a 2xx (Successful) response to indicate that the
request was accepted and a TCP connection was established. After request was accepted and a TCP connection was established. After
this point, the TCP connection is acting as a TCP tunnel, not an this point, the TCP connection is acting as a TCP tunnel, not an
HTTP/1.1 connection. HTTP/1.1 connection.
Both of these mechanisms also permit the server to reject the Both of these mechanisms also permit the server to reject the
request. For example, [HTTP] says: request. For example, Section 7.8 of [HTTP] says:
| A server MAY ignore a received Upgrade header field if it wishes | A server MAY ignore a received Upgrade header field if it wishes
| to continue using the current protocol on that connection. | to continue using the current protocol on that connection.
|
| -- HTTP, Section 7.8
| https://www.rfc-editor.org/rfc/rfc9110.html#section-7.8-2
and and Section 9.3.6 of [HTTP] says:
| A server MUST reject a CONNECT request that targets an empty or | A server MUST reject a CONNECT request that targets an empty or
| invalid port number, typically by responding with a 400 (Bad | invalid port number, typically by responding with a 400 (Bad
| Request) status code. | Request) status code.
|
| -- HTTP, Section 9.3.6
| https://www.rfc-editor.org/rfc/rfc9110.html#section-9.3.6-4
Rejected upgrades are common and can happen for a variety of reasons, Rejected upgrades are common and can happen for a variety of reasons,
such as: such as:
* The server does not support any of the client's indicated upgrade * The server does not support any of the client's indicated upgrade
tokens (i.e., the client's proposed new protocols), so it tokens (i.e., the client's proposed new protocols), so it
continues to use HTTP/1.1. continues to use HTTP/1.1.
* The server knows that an upgrade to the offered protocol will not * The server knows that an upgrade to the offered protocol will not
provide any improvement over HTTP/1.1 for this request to this provide any improvement over HTTP/1.1 for this request to this
skipping to change at page 5, line 17 skipping to change at line 182
| A client cannot begin using an upgraded protocol on the connection | A client cannot begin using an upgraded protocol on the connection
| until it has completely sent the request message (i.e., the client | until it has completely sent the request message (i.e., the client
| can't change the protocol it is sending in the middle of a | can't change the protocol it is sending in the middle of a
| message). | message).
| |
| -- HTTP, Section 7.8 | -- HTTP, Section 7.8
| https://www.rfc-editor.org/rfc/rfc9110.html#section-7.8-15 | https://www.rfc-editor.org/rfc/rfc9110.html#section-7.8-15
In other words, completion of the request message is a *necessary* In other words, completion of the request message is a *necessary*
condition for the client to begin using the new protocol. However, condition for the client to begin using the new protocol. However,
it is important to clarify that this is not a *sufficient* condition, it is important to clarify that this is not a *sufficient* condition
because the server might reject the request. because the server might reject the request.
In some cases, the client might predict that the server is likely to In some cases, the client might predict that the server is likely to
accept a requested protocol transition. For example, if a request accept a requested protocol transition. For example, if a request
using an upgrade token recently succeeded, the client might expect using an upgrade token recently succeeded, the client might expect
that subsequent requests with the same upgrade token will also that subsequent requests with the same upgrade token will also
succeed. If this expectation is correct, the client can often reduce succeed. If this expectation is correct, the client can often reduce
delay by immediately sending the first bytes of the new protocol delay by immediately sending the first bytes of the new protocol
"optimistically", without waiting for the server's response. This "optimistically", without waiting for the server's response. This
document explores the security implications of this "optimistic" document explores the security implications of this "optimistic"
behavior. behavior.
4. Possible Security Issues 4. Possible Security Issues
When there are only two distinct parties involved in an HTTP/1.1 When there are only two distinct parties involved in an HTTP/1.1
connection (i.e., the client and the server), protocol transitions connection (i.e., the client and the server), protocol transitions
introduce no new security issues: each party must already be prepared introduce no new security issues: Each party must already be prepared
for the other to send arbitrary data on the connection at any time. for the other to send arbitrary data on the connection at any time.
However, HTTP connections often involve more than two parties, if the However, HTTP connections often involve more than two parties if the
requests or responses include third-party data. For example, a requests or responses include third-party data. For example, a
browser (party 1) might send an HTTP request to an origin (party 2) browser (party 1) might send an HTTP request to an origin (party 2)
with path, headers, or content controlled by a website from a with the path, headers, or content controlled by a website from a
different origin (party 3). Post-transition protocols such as different origin (party 3). Post-transition protocols such as
WebSocket [WEBSOCKET] similarly are often used to convey data chosen WebSocket [WEBSOCKET] similarly are often used to convey data chosen
by a third party. by a third party.
If the third-party data source is untrusted, then the data it If the third-party data source is untrusted, then the data it
provides is potentially "attacker-controlled". The combination of provides is potentially "attacker-controlled". The combination of
attacker-controlled data and optimistic protocol transitions results attacker-controlled data and optimistic protocol transitions results
in two significant security issues. in two significant security issues.
4.1. Request Smuggling 4.1. Request Smuggling
In a Request Smuggling attack ([HTTP/1.1], Section 11.2) the In a Request Smuggling attack ([HTTP/1.1], Section 11.2), the
attacker-controlled data is chosen in such a way that it is attacker-controlled data is chosen in such a way that it is
interpreted by the server as an additional HTTP request. These interpreted by the server as an additional HTTP request. These
attacks allow the attacker to speak on behalf of the client while attacks allow the attacker to speak on behalf of the client while
bypassing the client's own rules about what requests it will issue. bypassing the client's own rules about what requests it will issue.
Request Smuggling can occur if the client and server have distinct Request Smuggling can occur if the client and server have distinct
interpretations of the data that flows between them. interpretations of the data that flows between them.
If the server accepts a protocol transition request, it interprets If the server accepts a protocol transition request, it interprets
the subsequent bytes in accordance with the new protocol. If it the subsequent bytes in accordance with the new protocol. If it
rejects the request, it interprets those bytes as HTTP/1.1. However, rejects the request, it interprets those bytes as HTTP/1.1. However,
skipping to change at page 7, line 36 skipping to change at line 275
HTTP/1.1 504 Gateway Timeout HTTP/1.1 504 Gateway Timeout
Content-Length: 0 Content-Length: 0
# The proxy interprets the smuggled POST request as coming from the # The proxy interprets the smuggled POST request as coming from the
# client. If connection-based authentication is in use (e.g., using # client. If connection-based authentication is in use (e.g., using
# TLS client certificate authentication), the proxy treats this # TLS client certificate authentication), the proxy treats this
# malicious request as authenticated. # malicious request as authenticated.
HTTP/1.1 200 OK HTTP/1.1 200 OK
Content-Length: 0 Content-Length: 0
Figure 1: Example request smuggling attack using HTTP CONNECT Figure 1: Example Request Smuggling Attack Using HTTP CONNECT
4.2. Parser Exploits 4.2. Parser Exploits
A related category of attacks use protocol disagreement to exploit A related category of attacks use protocol disagreement to exploit
vulnerabilities in the server's request parsing logic. These attacks vulnerabilities in the server's request parsing logic. These attacks
apply when the HTTP client is trusted by the server, but the post- apply when the HTTP client is trusted by the server, but the post-
transition data source is not. If the server software was developed transition data source is not. If the server software was developed
under the assumption that some or all of the HTTP request data is not under the assumption that some or all of the HTTP request data is not
attacker-controlled, optimistic transmission can cause this attacker-controlled, optimistic transmission can cause this
assumption to be violated, exposing vulnerabilities in the server's assumption to be violated, exposing vulnerabilities in the server's
skipping to change at page 8, line 26 skipping to change at line 309
This section describes the impact of this document's considerations This section describes the impact of this document's considerations
on some registered upgrade tokens [IANA-UPGR] that are believed to be on some registered upgrade tokens [IANA-UPGR] that are believed to be
in use at the time of writing. in use at the time of writing.
6.1. "TLS" 6.1. "TLS"
The "TLS" family of upgrade tokens was defined in [RFC2817], which The "TLS" family of upgrade tokens was defined in [RFC2817], which
correctly highlights the possibility of the server rejecting the correctly highlights the possibility of the server rejecting the
upgrade. If a client ignores this possibility and sends TLS data upgrade. If a client ignores this possibility and sends TLS data
optimistically, the result cannot be valid HTTP/1.1: the first octet optimistically, the result cannot be valid HTTP/1.1: The first octet
of a TLS connection must be 22 (ContentType.handshake), but this is of a TLS connection must be 22 (ContentType.handshake), but this is
not an allowed character in an HTTP/1.1 method (see [TLS], not an allowed character in an HTTP/1.1 method (see [TLS],
Section 5.1 and [HTTP/1.1], Section 3). A compliant HTTP/1.1 server Section 5.1 and [HTTP/1.1], Section 3). A compliant HTTP/1.1 server
will treat this as a parsing error and close the connection without will treat this as a parsing error and close the connection without
processing further requests. processing further requests.
6.2. "WebSocket"/"websocket" 6.2. "WebSocket"/"websocket"
Section 4.1 of [WEBSOCKET] says: Section 4.1 of [WEBSOCKET] says:
skipping to change at page 9, line 15 skipping to change at line 347
However, in HTTP/1.1, this "proxying request" is an HTTP Upgrade However, in HTTP/1.1, this "proxying request" is an HTTP Upgrade
request. This upgrade is likely to be rejected in certain request. This upgrade is likely to be rejected in certain
circumstances, such as when the UDP destination address (which is circumstances, such as when the UDP destination address (which is
attacker-controlled) is invalid. Additionally, the contents of the attacker-controlled) is invalid. Additionally, the contents of the
"connect-udp" protocol stream can include untrusted material (i.e., "connect-udp" protocol stream can include untrusted material (i.e.,
the UDP packets, which might come from other applications on the the UDP packets, which might come from other applications on the
client device). This creates the possibility of Request Smuggling client device). This creates the possibility of Request Smuggling
attacks. To avoid these concerns, this document replaces that text attacks. To avoid these concerns, this document replaces that text
to exclude HTTP/1.1 from any optimistic sending, as follows: to exclude HTTP/1.1 from any optimistic sending, as follows:
A client MAY optimistically start sending UDP packets in HTTP | A client MAY optimistically start sending UDP packets in HTTP
Datagrams before receiving the response to its UDP proxying | Datagrams before receiving the response to its UDP proxying
request, but only if the HTTP version in use is HTTP/2 or later. | request but only if the HTTP version in use is HTTP/2 or later.
Clients MUST NOT send UDP packets optimistically in HTTP/1.x due | Clients MUST NOT send UDP packets optimistically in HTTP/1.x due
to the risk of request smuggling attacks. | to the risk of Request Smuggling attacks.
6.4. "connect-ip" 6.4. "connect-ip"
The "connect-ip" upgrade token is defined in [CONNECT-IP]. The "connect-ip" upgrade token is defined in [CONNECT-IP].
Section 11 of [CONNECT-IP] forbids clients from sending packets Section 11 of [CONNECT-IP] forbids clients from sending packets
optimistically in HTTP/1.1, avoiding this issue. optimistically in HTTP/1.1, avoiding this issue.
7. Guidance for Future Upgrade Tokens 7. Guidance for Future Upgrade Tokens
There are now several good examples of designs that reduce or There are now several good examples of designs that reduce or
eliminate the security concerns discussed in this document and may be eliminate the security concerns discussed in this document and may be
applicable in future specifications: applicable in future specifications:
* Forbid optimistic use of HTTP Upgrade (Section 4.1 of [WEBSOCKET], * Forbid optimistic use of HTTP Upgrade (Section 4.1 of [WEBSOCKET]
Section 11 of [CONNECT-IP]). and Section 11 of [CONNECT-IP]).
* Embed a fixed preamble that deliberately terminates HTTP/1.1 * Embed a fixed preamble that deliberately terminates HTTP/1.1
processing (Section 3.4 of [HTTP/2]). processing (Section 3.4 of [HTTP/2]).
* Apply high-entropy masking of client-to-server data (Section 5.1 * Apply high-entropy masking of client-to-server data (Section 5.1
of [WEBSOCKET]). of [WEBSOCKET]).
Future specifications for upgrade tokens should account for the Future specifications for upgrade tokens should account for the
security issues discussed here and provide clear guidance on how security issues discussed here and provide clear guidance on how
implementations can avoid them. implementations can avoid them.
7.1. Selection of Request Methods 7.1. Selection of Request Methods
Some upgrade tokens, such as "TLS", are defined for use with any Some upgrade tokens, such as "TLS", are defined for use with any
ordinary HTTP method. The upgraded protocol continues to provide ordinary HTTP method. The upgraded protocol continues to provide
HTTP semantics, and will convey the response to this HTTP request. HTTP semantics and will convey the response to this HTTP request.
The other upgrade tokens mentioned in Section 6 do not preserve HTTP The other upgrade tokens mentioned in Section 6 do not preserve HTTP
semantics, so the method is not relevant. All of these upgrade semantics, so the method is not relevant. All of these upgrade
tokens are specified only for GET requests with no content. tokens are specified only for GET requests with no content.
Future specifications for upgrade tokens should restrict their use to Future specifications for upgrade tokens should restrict their use to
GET requests with no content if the HTTP method is otherwise GET requests with no content if the HTTP method is otherwise
irrelevant and the request does not need to carry any message irrelevant and the request does not need to carry any message
content. This improves consistency with other upgrade tokens and content. This improves consistency with other upgrade tokens and
simplifies server implementation. simplifies server implementation.
8. Requirements for HTTP CONNECT 8. Requirements for HTTP CONNECT
This document updates RFC 9112 to include the remaining text of this This document updates [HTTP/1.1] to include the remaining text of
section. The requirements in this section apply only to HTTP/1.1. this section. The requirements in this section apply only to
HTTP/1.1.
Proxy clients that send CONNECT requests on behalf of untrusted TCP Proxy clients that send CONNECT requests on behalf of untrusted TCP
clients MUST do one or both of the following: clients MUST do one or both of the following:
1. Wait for a 2xx (Successful) response before forwarding any TCP 1. Wait for a 2xx (Successful) response before forwarding any TCP
payload data. payload data.
2. Send a "Connection: close" request header. 2. Send a "Connection: close" request header.
Proxy clients that don't implement at least one of these two Proxy clients that don't implement at least one of these two
behaviors are vulnerable to a trivial request smuggling attack behaviors are vulnerable to a trivial Request Smuggling attack
([HTTP/1.1], Section 11.2). ([HTTP/1.1], Section 11.2).
At the time of writing, some proxy clients are believed to be At the time of writing, some proxy clients are believed to be
vulnerable as described. As a mitigation, proxy servers MUST close vulnerable as described. As a mitigation, proxy servers MUST close
the underlying connection when rejecting a CONNECT request, without the underlying connection when rejecting a CONNECT request without
processing any further requests on that connection. This requirement processing any further requests on that connection. This requirement
applies whether or not the request includes a "close" connection applies whether or not the request includes a "close" connection
option. option.
Note that this mitigation will frequently impair the performance of Note that this mitigation will frequently impair the performance of
correctly implemented clients, especially when returning a 407 (Proxy correctly implemented clients, especially when returning a 407 (Proxy
Authentication Required) response. This performance loss can be Authentication Required) response. This performance loss can be
avoided by using HTTP/2 or HTTP/3, which are not vulnerable to this avoided by using HTTP/2 or HTTP/3, which are not vulnerable to this
attack. attack.
skipping to change at page 11, line 21 skipping to change at line 448
This document has no IANA actions. This document has no IANA actions.
11. References 11. References
11.1. Normative References 11.1. Normative References
[CONNECT-UDP] [CONNECT-UDP]
Schinazi, D., "Proxying UDP in HTTP", RFC 9298, Schinazi, D., "Proxying UDP in HTTP", RFC 9298,
DOI 10.17487/RFC9298, August 2022, DOI 10.17487/RFC9298, August 2022,
<https://www.rfc-editor.org/rfc/rfc9298>. <https://www.rfc-editor.org/info/rfc9298>.
[HTTP] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, [HTTP] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "HTTP Semantics", STD 97, RFC 9110, Ed., "HTTP Semantics", STD 97, RFC 9110,
DOI 10.17487/RFC9110, June 2022, DOI 10.17487/RFC9110, June 2022,
<https://www.rfc-editor.org/rfc/rfc9110>. <https://www.rfc-editor.org/info/rfc9110>.
[HTTP/1.1] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, [HTTP/1.1] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "HTTP/1.1", STD 99, RFC 9112, DOI 10.17487/RFC9112, Ed., "HTTP/1.1", STD 99, RFC 9112, DOI 10.17487/RFC9112,
June 2022, <https://www.rfc-editor.org/rfc/rfc9112>. June 2022, <https://www.rfc-editor.org/info/rfc9112>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
11.2. Informative References 11.2. Informative References
[CONNECT-IP] [CONNECT-IP]
Pauly, T., Ed., Schinazi, D., Chernyakhovsky, A., Pauly, T., Ed., Schinazi, D., Chernyakhovsky, A.,
Kühlewind, M., and M. Westerlund, "Proxying IP in HTTP", Kühlewind, M., and M. Westerlund, "Proxying IP in HTTP",
RFC 9484, DOI 10.17487/RFC9484, October 2023, RFC 9484, DOI 10.17487/RFC9484, October 2023,
<https://www.rfc-editor.org/rfc/rfc9484>. <https://www.rfc-editor.org/info/rfc9484>.
[HTTP/2] Thomson, M., Ed. and C. Benfield, Ed., "HTTP/2", RFC 9113, [HTTP/2] Thomson, M., Ed. and C. Benfield, Ed., "HTTP/2", RFC 9113,
DOI 10.17487/RFC9113, June 2022, DOI 10.17487/RFC9113, June 2022,
<https://www.rfc-editor.org/rfc/rfc9113>. <https://www.rfc-editor.org/info/rfc9113>.
[HTTP/3] Bishop, M., Ed., "HTTP/3", RFC 9114, DOI 10.17487/RFC9114, [HTTP/3] Bishop, M., Ed., "HTTP/3", RFC 9114, DOI 10.17487/RFC9114,
June 2022, <https://www.rfc-editor.org/rfc/rfc9114>. June 2022, <https://www.rfc-editor.org/info/rfc9114>.
[IANA-UPGR] [IANA-UPGR]
IANA, "Hypertext Transfer Protocol (HTTP) Upgrade Token IANA, "Hypertext Transfer Protocol (HTTP) Upgrade Token
Registry", n.d., Registry",
<https://www.iana.org/assignments/http-upgrade-tokens/>. <https://www.iana.org/assignments/http-upgrade-tokens/>.
[RFC2817] Khare, R. and S. Lawrence, "Upgrading to TLS Within [RFC2817] Khare, R. and S. Lawrence, "Upgrading to TLS Within
HTTP/1.1", RFC 2817, DOI 10.17487/RFC2817, May 2000, HTTP/1.1", RFC 2817, DOI 10.17487/RFC2817, May 2000,
<https://www.rfc-editor.org/rfc/rfc2817>. <https://www.rfc-editor.org/info/rfc2817>.
[TLS] Rescorla, E., "The Transport Layer Security (TLS) Protocol [TLS] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/rfc/rfc8446>. <https://www.rfc-editor.org/info/rfc8446>.
[WEBSOCKET] [WEBSOCKET]
Fette, I. and A. Melnikov, "The WebSocket Protocol", Fette, I. and A. Melnikov, "The WebSocket Protocol",
RFC 6455, DOI 10.17487/RFC6455, December 2011, RFC 6455, DOI 10.17487/RFC6455, December 2011,
<https://www.rfc-editor.org/rfc/rfc6455>. <https://www.rfc-editor.org/info/rfc6455>.
Acknowledgments Acknowledgments
This document benefited from valuable reviews and suggestions by: This document benefited from valuable reviews and suggestions by:
* Mike Bishop * Mike Bishop
* Mohamed Boucadair * Mohamed Boucadair
* Gorry Fairhurst * Gorry Fairhurst
 End of changes. 44 change blocks. 
116 lines changed or deleted 97 lines changed or added

This html diff was produced by rfcdiff 1.48.