rfc9931.original.xml   rfc9931.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE rfc [ <!DOCTYPE rfc [
<!ENTITY nbsp "&#160;"> <!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;"> <!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;"> <!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;"> <!ENTITY wj "&#8288;">
]> ]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.29 (Ruby 3.4. <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
4) --> -ietf-httpbis-optimistic-upgrade-06" number="9931" category="std" consensus="tru
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft e" submissionType="IETF" updates="9112, 9298" obsoletes="" tocInclude="true" sor
-ietf-httpbis-optimistic-upgrade-06" category="std" consensus="true" submissionT tRefs="true" symRefs="true" version="3" xml:lang="en">
ype="IETF" updates="9112, 9298" tocInclude="true" sortRefs="true" symRefs="true"
version="3">
<!-- xml2rfc v2v3 conversion 3.30.2 -->
<front> <front>
<title abbrev="Optimistic HTTP Upgrade Security">Security Considerations for Optimistic Protocol Transitions in HTTP/1.1</title> <title abbrev="Optimistic HTTP Upgrade Security">Security Considerations for Optimistic Protocol Transitions in HTTP/1.1</title>
<seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-optimistic-upgra <seriesInfo name="RFC" value="9931"/>
de-06"/> <author fullname="Benjamin M. Schwartz" initials="B" surname="Schwartz">
<author fullname="Benjamin M. Schwartz">
<organization>Meta Platforms, Inc.</organization> <organization>Meta Platforms, Inc.</organization>
<address> <address>
<email>ietf@bemasc.net</email> <email>ietf@bemasc.net</email>
</address> </address>
</author> </author>
<date year="2025" month="September" day="18"/> <date year="2026" month="February"/>
<area>Web and Internet Transport</area>
<workgroup>HTTPBIS</workgroup>
<abstract>
<?line 40?>
<t>In HTTP/1.1, the client can request a change to a new protocol on the existin <area>WIT</area>
g connection. This document discusses the security considerations that apply to <workgroup>httpbis</workgroup>
data sent by the client before this request is confirmed, and adds new requirem
ents to RFC 9112 and RFC 9298 to avoid related security issues.</t> <!-- [rfced] Please insert any keywords (beyond those that appear in
the title) for use on https://www.rfc-editor.org/search. -->
<keyword>example</keyword>
<abstract>
<t>In HTTP/1.1, the client can request a change to a new protocol on the existin
g connection. This document discusses the security considerations that apply to
data sent by the client before this request is confirmed and adds new requireme
nts to RFCs 9112 and 9298 to avoid related security issues.</t>
</abstract> </abstract>
<note removeInRFC="true">
<name>About This Document</name>
<t>
Status information for this document may be found at <eref target="https
://datatracker.ietf.org/doc/draft-ietf-httpbis-optimistic-upgrade/"/>.
</t>
<t>Source for this draft and an issue tracker can be found at
<eref target="https://github.com/httpwg/http-extensions"/>.</t>
</note>
</front> </front>
<middle> <middle>
<?line 45?>
<section anchor="conventions-and-definitions">
<name>Conventions and Definitions</name>
<t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14
>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECO
MMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be i
nterpreted as
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and
only when, they
appear in all capitals, as shown here.</t>
<?line -18?>
</section>
<section anchor="overview"> <section anchor="overview">
<name>Overview</name> <name>Overview</name>
<t>This document discusses certain security considerations that arise when switching from HTTP/1.1 to a different protocol on the same connection. It pro vides:</t> <t>This document discusses certain security considerations that arise when switching from HTTP/1.1 to a different protocol on the same connection. It pro vides:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>A review of the relevant standards.</t> <t>a review of the relevant standards,</t>
</li> </li>
<li> <li>
<t>A discussion of the security risks that may apply if a client sends data before the transition is confirmed.</t> <t>a discussion of the security risks that may apply if a client sends data before the transition is confirmed,</t>
</li> </li>
<li> <li>
<t>Security evaluation of existing upgrade tokens.</t> <t>a security evaluation of existing upgrade tokens, and</t>
</li> </li>
<li> <li>
<t>Guidance for implementations and future standards documents.</t> <t>guidance for implementations and future standards documents.</t>
</li> </li>
</ul> </ul>
<t>Updates to RFC 9112 and RFC 9298, including new normative requirements, <t>Updates to <xref target="RFC9112"/> and <xref target="RFC9298"/>, inclu
are provided in <xref target="connect"/> and <xref target="connect-udp"/>.</t> ding new normative requirements, are provided in Sections <xref target="connect"
format="counter"/> and <xref target="connect-udp" format="counter"/>, respectiv
ely.</t>
</section>
<section anchor="conventions-and-definitions">
<name>Requirements Language</name>
<t>
The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
"<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
"<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are
to be interpreted as described in BCP&nbsp;14 <xref target="RFC2119"/>
<xref target="RFC8174"/> when, and only when, they appear in all capitals,
as shown here.
</t>
</section> </section>
<section anchor="background"> <section anchor="background">
<name>Background</name> <name>Background</name>
<t>In HTTP/1.1 <xref target="RFC9112"/> and later, a single connection can be used for many requests. In HTTP/2 <xref target="RFC9113"/> and HTTP/3 <xref target="RFC9114"/>, these requests can be multiplexed, as each request is disti nguished explicitly by its stream ID. However, in HTTP/1.1, requests are strict ly sequential, and each new request is distinguished implicitly by the closure o f the preceding request.</t> <t>In HTTP/1.1 <xref target="RFC9112"/> and later, a single connection can be used for many requests. In HTTP/2 <xref target="RFC9113"/> and HTTP/3 <xref target="RFC9114"/>, these requests can be multiplexed, as each request is disti nguished explicitly by its stream ID. However, in HTTP/1.1, requests are strict ly sequential, and each new request is distinguished implicitly by the closure o f the preceding request.</t>
<t>HTTP/1.1 is also the only version of HTTP that allows the client to cha <t>HTTP/1.1 is also the only version of HTTP that allows the client to cha
nge the protocol used for the remainder of the connection. There are two mechan nge the protocol used for the remainder of the connection. There are two mechan
isms to request such a protocol transition. One mechanism is the Upgrade reques isms to request such a protocol transition.
t header field (<xref section="7.8" sectionFormat="comma" target="HTTP"/>), whic
h indicates that the client would like to use this connection for a protocol oth <!-- [rfced] To reflect the text in Section 7.8 of RFC 9110, may we
er than HTTP/1.1. The server replies with a 101 (Switching Protocols) status co update "Upgrade request header field" to "Upgrade header field of a
de if it accepts the protocol change (<xref section="15.2.2" sectionFormat="comm request"?
a" target="HTTP"/>).</t>
<t>The other mechanism is the HTTP CONNECT method (<xref section="9.3.6" s Current:
ectionFormat="of" target="HTTP"/>). This method indicates that the client wishe There are two mechanisms to request such a protocol transition. One
s to establish a TCP connection to the specified host and port. If accepted, th mechanism is the Upgrade request header field ([HTTP], Section 7.8),
e server replies with a 2xx (Successful) response to indicate that the request w which indicates that the client would like to use this connection for
as accepted and a TCP connection was established. After this point, the TCP con a protocol other than HTTP/1.1. ...
nection is acting as a TCP tunnel, not an HTTP/1.1 connection.</t>
<t>Both of these mechanisms also permit the server to reject the request. Perhaps:
For example, <xref target="HTTP"/> says:</t> There are two mechanisms to request such a protocol transition. One
<blockquote quotedFrom="HTTP, Section 7.8" cite="https://www.rfc-editor.or mechanism is the Upgrade header field of a request ([HTTP], Section 7.8),
g/rfc/rfc9110.html#section-7.8-2"> which indicates that the client would like to use this connection for
a protocol other than HTTP/1.1. ...
-->
One mechanism is the Upgrade request header field (<xref section="7.8" sectionFo
rmat="comma" target="RFC9110"/>), which indicates that the client would like to
use this connection for a protocol other than HTTP/1.1. The server replies with
a 101 (Switching Protocols) status code if it accepts the protocol change (<xre
f section="15.2.2" sectionFormat="comma" target="RFC9110"/>).</t>
<t>The other mechanism is the HTTP CONNECT method (<xref section="9.3.6" s
ectionFormat="of" target="RFC9110"/>). This method indicates that the client wi
shes to establish a TCP connection to the specified host and port. If accepted,
the server replies with a 2xx (Successful) response to indicate that the reques
t was accepted and a TCP connection was established. After this point, the TCP
connection is acting as a TCP tunnel, not an HTTP/1.1 connection.</t>
<t>Both of these mechanisms also permit the server to reject the request.
For example, <xref target="RFC9110" section="7.8"/> says:</t>
<blockquote>
<t>A server <bcp14>MAY</bcp14> ignore a received Upgrade header field if it wishes to continue using the current protocol on that connection.</t> <t>A server <bcp14>MAY</bcp14> ignore a received Upgrade header field if it wishes to continue using the current protocol on that connection.</t>
</blockquote> </blockquote>
<t>and</t> <t>and <xref target="RFC9110" section="9.3.6"/> says:</t>
<blockquote quotedFrom="HTTP, Section 9.3.6" cite="https://www.rfc-editor. <blockquote>
org/rfc/rfc9110.html#section-9.3.6-4">
<t>A server <bcp14>MUST</bcp14> reject a CONNECT request that targets an empty or invalid port number, typically by responding with a 400 (Bad Request) status code.</t> <t>A server <bcp14>MUST</bcp14> reject a CONNECT request that targets an empty or invalid port number, typically by responding with a 400 (Bad Request) status code.</t>
</blockquote> </blockquote>
<t>Rejected upgrades are common and can happen for a variety of reasons, s uch as:</t> <t>Rejected upgrades are common and can happen for a variety of reasons, s uch as:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>The server does not support any of the client's indicated upgrade t okens (i.e., the client's proposed new protocols), so it continues to use HTTP/1 .1.</t> <t>The server does not support any of the client's indicated upgrade t okens (i.e., the client's proposed new protocols), so it continues to use HTTP/1 .1.</t>
</li> </li>
<li> <li>
<t>The server knows that an upgrade to the offered protocol will not p rovide any improvement over HTTP/1.1 for this request to this resource, so it ch ooses to respond in HTTP/1.1.</t> <t>The server knows that an upgrade to the offered protocol will not p rovide any improvement over HTTP/1.1 for this request to this resource, so it ch ooses to respond in HTTP/1.1.</t>
</li> </li>
<li> <li>
<t>The server requires the client to authenticate before upgrading the protocol, so it replies with the status code 401 (Authentication Required) and provides a challenge in an Authorization response header field (<xref section="1 1.6.2" sectionFormat="comma" target="HTTP"/>).</t> <t>The server requires the client to authenticate before upgrading the protocol, so it replies with the status code 401 (Authentication Required) and provides a challenge in an Authorization response header field (<xref section="1 1.6.2" sectionFormat="comma" target="RFC9110"/>).</t>
</li> </li>
<li> <li>
<t>The resource has moved, so the server replies with a 3xx (Redirecti on) status code (<xref section="3.4" sectionFormat="comma" target="HTTP"/>).</t> <t>The resource has moved, so the server replies with a 3xx (Redirecti on) status code (<xref section="3.4" sectionFormat="comma" target="RFC9110"/>).< /t>
</li> </li>
</ul> </ul>
<t>Similarly, servers frequently reject HTTP CONNECT requests, such as whe n:</t> <t>Similarly, servers frequently reject HTTP CONNECT requests, such as whe n:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>The server does not support HTTP CONNECT.</t> <t>The server does not support HTTP CONNECT.</t>
</li> </li>
<li> <li>
<t>The specified destination is not allowed under server policy.</t> <t>The specified destination is not allowed under server policy.</t>
</li> </li>
<li> <li>
<t>The destination cannot be resolved, is unreachable, or does not acc ept the connection.</t> <t>The destination cannot be resolved, is unreachable, or does not acc ept the connection.</t>
</li> </li>
<li> <li>
<t>The proxy requires the client to authenticate before proceeding.</t > <t>The proxy requires the client to authenticate before proceeding.</t >
</li> </li>
</ul> </ul>
<t>After rejecting a request, the server will continue to interpret bytes received on that connection in accordance with HTTP/1.1.</t> <t>After rejecting a request, the server will continue to interpret bytes received on that connection in accordance with HTTP/1.1.</t>
<t><xref target="HTTP"/> also states:</t> <t><xref target="RFC9110"/> also states:</t>
<blockquote quotedFrom="HTTP, Section 7.8" cite="https://www.rfc-editor.or g/rfc/rfc9110.html#section-7.8-15"> <blockquote quotedFrom="HTTP, Section 7.8" cite="https://www.rfc-editor.or g/rfc/rfc9110.html#section-7.8-15">
<t>A client cannot begin using an upgraded protocol on the connection un til it has completely sent the request message (i.e., the client can't change th e protocol it is sending in the middle of a message).</t> <t>A client cannot begin using an upgraded protocol on the connection un til it has completely sent the request message (i.e., the client can't change th e protocol it is sending in the middle of a message).</t>
</blockquote> </blockquote>
<t>In other words, completion of the request message is a <strong>necessar y</strong> condition for the client to begin using the new protocol. However, i t is important to clarify that this is not a <strong>sufficient</strong> conditi on, because the server might reject the request.</t> <t>In other words, completion of the request message is a <strong>necessar y</strong> condition for the client to begin using the new protocol. However, i t is important to clarify that this is not a <strong>sufficient</strong> conditi on because the server might reject the request.</t>
<t>In some cases, the client might predict that the server is likely to ac cept a requested protocol transition. For example, if a request using an upgrad e token recently succeeded, the client might expect that subsequent requests wit h the same upgrade token will also succeed. If this expectation is correct, the client can often reduce delay by immediately sending the first bytes of the new protocol "optimistically", without waiting for the server's response. This doc ument explores the security implications of this "optimistic" behavior.</t> <t>In some cases, the client might predict that the server is likely to ac cept a requested protocol transition. For example, if a request using an upgrad e token recently succeeded, the client might expect that subsequent requests wit h the same upgrade token will also succeed. If this expectation is correct, the client can often reduce delay by immediately sending the first bytes of the new protocol "optimistically", without waiting for the server's response. This doc ument explores the security implications of this "optimistic" behavior.</t>
</section> </section>
<section anchor="possible-security-issues"> <section anchor="possible-security-issues">
<name>Possible Security Issues</name> <name>Possible Security Issues</name>
<t>When there are only two distinct parties involved in an HTTP/1.1 connec
tion (i.e., the client and the server), protocol transitions introduce no new se <!--[rfced] It is unclear what "similarly" is referring to in this sentence.
curity issues: each party must already be prepared for the other to send arbitra Please review and let us know how this text may be clarified or if we
ry data on the connection at any time. However, HTTP connections often involve may remove "similarly".
more than two parties, if the requests or responses include third-party data. F
or example, a browser (party 1) might send an HTTP request to an origin (party 2 Original:
) with path, headers, or content controlled by a website from a different origin Post-transition protocols such as
(party 3). Post-transition protocols such as WebSocket <xref target="WEBSOCKET WebSocket [WEBSOCKET] similarly are often used to convey data chosen
"/> similarly are often used to convey data chosen by a third party.</t> by a third party.
Perhaps:
Post-transition protocols, such as
WebSocket [WEBSOCKET], are often used to convey data chosen
by a third party.
-->
<t>When there are only two distinct parties involved in an HTTP/1.1 connec
tion (i.e., the client and the server), protocol transitions introduce no new se
curity issues: Each party must already be prepared for the other to send arbitra
ry data on the connection at any time. However, HTTP connections often involve
more than two parties if the requests or responses include third-party data. Fo
r example, a browser (party 1) might send an HTTP request to an origin (party 2)
with the path, headers, or content controlled by a website from a different ori
gin (party 3). Post-transition protocols such as WebSocket <xref target="RFC645
5"/> similarly are often used to convey data chosen by a third party.</t>
<t>If the third-party data source is untrusted, then the data it provides is potentially "attacker-controlled". The combination of attacker-controlled da ta and optimistic protocol transitions results in two significant security issue s.</t> <t>If the third-party data source is untrusted, then the data it provides is potentially "attacker-controlled". The combination of attacker-controlled da ta and optimistic protocol transitions results in two significant security issue s.</t>
<section anchor="request-smuggling"> <section anchor="request-smuggling">
<name>Request Smuggling</name> <name>Request Smuggling</name>
<t>In a Request Smuggling attack (<xref section="11.2" sectionFormat="co mma" target="RFC9112"/>) the attacker-controlled data is chosen in such a way th at it is interpreted by the server as an additional HTTP request. These attacks allow the attacker to speak on behalf of the client while bypassing the client' s own rules about what requests it will issue. Request Smuggling can occur if t he client and server have distinct interpretations of the data that flows betwee n them.</t> <t>In a Request Smuggling attack (<xref section="11.2" sectionFormat="co mma" target="RFC9112"/>), the attacker-controlled data is chosen in such a way t hat it is interpreted by the server as an additional HTTP request. These attack s allow the attacker to speak on behalf of the client while bypassing the client 's own rules about what requests it will issue. Request Smuggling can occur if the client and server have distinct interpretations of the data that flows betwe en them.</t>
<t>If the server accepts a protocol transition request, it interprets th e subsequent bytes in accordance with the new protocol. If it rejects the reque st, it interprets those bytes as HTTP/1.1. However, the client cannot know whic h interpretation the server will take until it receives the server's response st atus code. If it uses the new protocol optimistically, this creates a risk that the server will interpret attacker-controlled data in the new protocol as an ad ditional HTTP request issued by the client.</t> <t>If the server accepts a protocol transition request, it interprets th e subsequent bytes in accordance with the new protocol. If it rejects the reque st, it interprets those bytes as HTTP/1.1. However, the client cannot know whic h interpretation the server will take until it receives the server's response st atus code. If it uses the new protocol optimistically, this creates a risk that the server will interpret attacker-controlled data in the new protocol as an ad ditional HTTP request issued by the client.</t>
<t>As a trivial example, consider an HTTP CONNECT client providing conne ctivity to an untrusted application. If the client is authenticated to the prox y server using a connection-level authentication method such as TLS Client Certi ficates (<xref section="4.4.2" sectionFormat="comma" target="TLS"/>), the attack er could send an HTTP/1.1 POST request (<xref section="9.3.3" sectionFormat="com ma" target="HTTP"/>) for the proxy server at the beginning of its TCP connection . If the client delivers this data optimistically, and the CONNECT request fail s, the server would misinterpret the application's data as a subsequent authenti cated request issued by the client.</t> <t>As a trivial example, consider an HTTP CONNECT client providing conne ctivity to an untrusted application. If the client is authenticated to the prox y server using a connection-level authentication method such as TLS Client Certi ficates (<xref section="4.4.2" sectionFormat="comma" target="RFC8446"/>), the at tacker could send an HTTP/1.1 POST request (<xref section="9.3.3" sectionFormat= "comma" target="RFC9110"/>) for the proxy server at the beginning of its TCP con nection. If the client delivers this data optimistically, and the CONNECT reque st fails, the server would misinterpret the application's data as a subsequent a uthenticated request issued by the client.</t>
<figure> <figure>
<name>Example request smuggling attack using HTTP CONNECT</name> <name>Example Request Smuggling Attack Using HTTP CONNECT</name>
<artwork><![CDATA[ <artwork><![CDATA[
## REQUESTS ## ## REQUESTS ##
# The malicious application requests a TCP connection to a nonexistent # The malicious application requests a TCP connection to a nonexistent
# destination, which will fail. # destination, which will fail.
CONNECT no-such-destination.example:443 HTTP/1.1 CONNECT no-such-destination.example:443 HTTP/1.1
Host: no-such-destination.example:443 Host: no-such-destination.example:443
# Before connection fails, the malicious application sends data on the # Before connection fails, the malicious application sends data on the
# proxied TCP connection that forms a valid POST request to the proxy. # proxied TCP connection that forms a valid POST request to the proxy.
skipping to change at line 162 skipping to change at line 197
# rejecting the CONNECT request, but the client has already forwarded # rejecting the CONNECT request, but the client has already forwarded
# the malicious TCP payload data to the proxy. # the malicious TCP payload data to the proxy.
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]]></artwork>
]]></artwork>
</figure> </figure>
</section> </section>
<section anchor="parser-exploits"> <section anchor="parser-exploits">
<name>Parser Exploits</name> <name>Parser Exploits</name>
<t>A related category of attacks use protocol disagreement to exploit vu lnerabilities in the server's request parsing logic. These attacks apply when t he HTTP client is trusted by the server, but the post-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 attacker-controlled, optimistic transmission ca n cause this assumption to be violated, exposing vulnerabilities in the server's HTTP request parser.</t> <t>A related category of attacks use protocol disagreement to exploit vu lnerabilities in the server's request parsing logic. These attacks apply when t he HTTP client is trusted by the server, but the post-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 attacker-controlled, optimistic transmission ca n cause this assumption to be violated, exposing vulnerabilities in the server's HTTP request parser.</t>
</section> </section>
</section> </section>
<section anchor="operational-issues"> <section anchor="operational-issues">
<name>Operational Issues</name> <name>Operational Issues</name>
<t>If the server rejects the transition request, the connection can contin ue to be used for HTTP/1.1. There is no general requirement to close the connec tion in response to a rejected transition, and keeping the connection open has p erformance advantages if additional HTTP requests to this server are likely. Th us, it is normally inappropriate to close the connection in response to a reject ed transition.</t> <t>If the server rejects the transition request, the connection can contin ue to be used for HTTP/1.1. There is no general requirement to close the connec tion in response to a rejected transition, and keeping the connection open has p erformance advantages if additional HTTP requests to this server are likely. Th us, it is normally inappropriate to close the connection in response to a reject ed transition.</t>
</section> </section>
<section anchor="existing"> <section anchor="existing">
<name>Impact on HTTP Upgrade with Existing Upgrade Tokens</name> <name>Impact on HTTP Upgrade with Existing Upgrade Tokens</name>
<t>This section describes the impact of this document's considerations on some registered upgrade tokens <xref target="IANA-UPGR"/> that are believed to b e in use at the time of writing.</t> <t>This section describes the impact of this document's considerations on some registered upgrade tokens <xref target="IANA-UPGR"/> that are believed to b e in use at the time of writing.</t>
<section anchor="tls"> <section anchor="tls">
<name>"TLS"</name> <name>"TLS"</name>
<t>The "TLS" family of upgrade tokens was defined in <xref target="RFC28 17"/>, which correctly highlights the possibility of the server rejecting the up grade. If a client ignores this possibility and sends TLS data optimistically, t he result cannot be valid HTTP/1.1: the first octet of a TLS connection must be 22 (ContentType.handshake), but this is not an allowed character in an HTTP/1.1 method (see <xref section="5.1" sectionFormat="comma" target="TLS"/> and <xref s ection="3" sectionFormat="comma" target="RFC9112"/>). A compliant HTTP/1.1 serv er will treat this as a parsing error and close the connection without processin g further requests.</t> <t>The "TLS" family of upgrade tokens was defined in <xref target="RFC28 17"/>, which correctly highlights the possibility of the server rejecting the up grade. If a client ignores this possibility and sends TLS data optimistically, t he result cannot be valid HTTP/1.1: The first octet of a TLS connection must be 22 (ContentType.handshake), but this is not an allowed character in an HTTP/1.1 method (see <xref section="5.1" sectionFormat="comma" target="RFC8446"/> and <xr ef section="3" sectionFormat="comma" target="RFC9112"/>). A compliant HTTP/1.1 server will treat this as a parsing error and close the connection without proce ssing further requests.</t>
</section> </section>
<section anchor="websocketwebsocket"> <section anchor="websocketwebsocket">
<name>"WebSocket"/"websocket"</name> <name>"WebSocket"/"websocket"</name>
<t><xref section="4.1" sectionFormat="of" target="WEBSOCKET"/> says:</t> <t><xref section="4.1" sectionFormat="of" target="RFC6455"/> says:</t>
<blockquote> <blockquote>
<t>Once the client's opening handshake has been sent, the client <bcp1 4>MUST</bcp14> wait for a response from the server before sending any further da ta.</t> <t>Once the client's opening handshake has been sent, the client <bcp1 4>MUST</bcp14> wait for a response from the server before sending any further da ta.</t>
</blockquote> </blockquote>
<t>Thus, optimistic use of HTTP Upgrade is already forbidden in the WebS ocket protocol. Additionally, the WebSocket protocol requires high-entropy mask ing of client-to-server frames (<xref section="5.1" sectionFormat="of" target="W EBSOCKET"/>).</t> <t>Thus, optimistic use of HTTP Upgrade is already forbidden in the WebS ocket protocol. Additionally, the WebSocket protocol requires high-entropy mask ing of client-to-server frames (<xref section="5.1" sectionFormat="of" target="R FC6455"/>).</t>
</section> </section>
<section anchor="connect-udp"> <section anchor="connect-udp">
<name>"connect-udp"</name> <name>"connect-udp"</name>
<t><xref section="5" sectionFormat="of" target="CONNECT-UDP"/> says:</t> <t><xref section="5" sectionFormat="of" target="RFC9298"/> says:</t>
<blockquote> <blockquote>
<t>A client <bcp14>MAY</bcp14> optimistically start sending UDP packet s in HTTP Datagrams before receiving the response to its UDP proxying request.</ t> <t>A client <bcp14>MAY</bcp14> optimistically start sending UDP packet s in HTTP Datagrams before receiving the response to its UDP proxying request.</ t>
</blockquote> </blockquote>
<t>However, in HTTP/1.1, this "proxying request" is an HTTP Upgrade requ est. This upgrade is likely to be rejected in certain circumstances, such as wh en the UDP destination address (which is attacker-controlled) is invalid. Addit ionally, the contents of the "connect-udp" protocol stream can include untrusted material (i.e., the UDP packets, which might come from other applications on th e client device). This creates the possibility of Request Smuggling attacks. T o avoid these concerns, this document replaces that text to exclude HTTP/1.1 fro m any optimistic sending, as follows:</t> <t>However, in HTTP/1.1, this "proxying request" is an HTTP Upgrade requ est. This upgrade is likely to be rejected in certain circumstances, such as wh en the UDP destination address (which is attacker-controlled) is invalid. Addit ionally, the contents of the "connect-udp" protocol stream can include untrusted material (i.e., the UDP packets, which might come from other applications on th e client device). This creates the possibility of Request Smuggling attacks. T o avoid these concerns, this document replaces that text to exclude HTTP/1.1 fro m any optimistic sending, as follows:</t>
<ul empty="true"> <blockquote>
<li> <t>A client <bcp14>MAY</bcp14> optimistically start sending UDP pack
<t>A client <bcp14>MAY</bcp14> optimistically start sending UDP pack ets in HTTP Datagrams before receiving the response to its UDP proxying request
ets in HTTP Datagrams before receiving the response to its UDP proxying request, but only if the HTTP version in use is HTTP/2 or later. Clients <bcp14>MUST NOT<
but only if the HTTP version in use is HTTP/2 or later. Clients <bcp14>MUST NOT /bcp14> send UDP packets optimistically in HTTP/1.x due to the risk of Request S
</bcp14> send UDP packets optimistically in HTTP/1.x due to the risk of request muggling attacks.</t>
smuggling attacks.</t> </blockquote>
</li>
</ul>
</section> </section>
<section anchor="connect-ip"> <section anchor="connect-ip">
<name>"connect-ip"</name> <name>"connect-ip"</name>
<t>The "connect-ip" upgrade token is defined in <xref target="CONNECT-IP "/>. <xref section="11" sectionFormat="of" target="CONNECT-IP"/> forbids client s from sending packets optimistically in HTTP/1.1, avoiding this issue.</t> <t>The "connect-ip" upgrade token is defined in <xref target="RFC9484"/> . <xref section="11" sectionFormat="of" target="RFC9484"/> forbids clients from sending packets optimistically in HTTP/1.1, avoiding this issue.</t>
</section> </section>
</section> </section>
<section anchor="guidance-for-future-upgrade-tokens"> <section anchor="guidance-for-future-upgrade-tokens">
<name>Guidance for Future Upgrade Tokens</name> <name>Guidance for Future Upgrade Tokens</name>
<t>There are now several good examples of designs that reduce or eliminate the security concerns discussed in this document and may be applicable in futur e specifications:</t> <t>There are now several good examples of designs that reduce or eliminate the security concerns discussed in this document and may be applicable in futur e specifications:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>Forbid optimistic use of HTTP Upgrade (<xref section="4.1" sectionF ormat="of" target="WEBSOCKET"/>, <xref section="11" sectionFormat="of" target="C ONNECT-IP"/>).</t> <t>Forbid optimistic use of HTTP Upgrade (<xref section="4.1" sectionF ormat="of" target="RFC6455"/> and <xref section="11" sectionFormat="of" target=" RFC9484"/>).</t>
</li> </li>
<li> <li>
<t>Embed a fixed preamble that deliberately terminates HTTP/1.1 proces sing (<xref section="3.4" sectionFormat="of" target="RFC9113"/>).</t> <t>Embed a fixed preamble that deliberately terminates HTTP/1.1 proces sing (<xref section="3.4" sectionFormat="of" target="RFC9113"/>).</t>
</li> </li>
<li> <li>
<t>Apply high-entropy masking of client-to-server data (<xref section= "5.1" sectionFormat="of" target="WEBSOCKET"/>).</t> <t>Apply high-entropy masking of client-to-server data (<xref section= "5.1" sectionFormat="of" target="RFC6455"/>).</t>
</li> </li>
</ul> </ul>
<t>Future specifications for upgrade tokens should account for the securit y issues discussed here and provide clear guidance on how implementations can av oid them.</t> <t>Future specifications for upgrade tokens should account for the securit y issues discussed here and provide clear guidance on how implementations can av oid them.</t>
<section anchor="selection-of-request-methods"> <section anchor="selection-of-request-methods">
<name>Selection of Request Methods</name> <name>Selection of Request Methods</name>
<t>Some upgrade tokens, such as "TLS", are defined for use with any ordi nary HTTP method. The upgraded protocol continues to provide HTTP semantics, an d will convey the response to this HTTP request.</t> <t>Some upgrade tokens, such as "TLS", are defined for use with any ordi nary HTTP method. The upgraded protocol continues to provide HTTP semantics and will convey the response to this HTTP request.</t>
<t>The other upgrade tokens mentioned in <xref target="existing"/> do no t preserve HTTP semantics, so the method is not relevant. All of these upgrade tokens are specified only for GET requests with no content.</t> <t>The other upgrade tokens mentioned in <xref target="existing"/> do no t preserve HTTP semantics, so the method is not relevant. All of these upgrade tokens are specified only for GET requests with no content.</t>
<t>Future specifications for upgrade tokens should restrict their use to GET requests with no content if the HTTP method is otherwise irrelevant and the request does not need to carry any message content. This improves consistency with other upgrade tokens and simplifies server implementation.</t> <t>Future specifications for upgrade tokens should restrict their use to GET requests with no content if the HTTP method is otherwise irrelevant and the request does not need to carry any message content. This improves consistency with other upgrade tokens and simplifies server implementation.</t>
</section> </section>
</section> </section>
<section anchor="connect"> <section anchor="connect">
<name>Requirements for HTTP CONNECT</name> <name>Requirements for HTTP CONNECT</name>
<t>This document updates RFC 9112 to include the remaining text of this se ction. The requirements in this section apply only to HTTP/1.1.</t> <t>This document updates <xref target="RFC9112"/> to include the remaining text of this section. The requirements in this section apply only to HTTP/1.1. </t>
<t>Proxy clients that send CONNECT requests on behalf of untrusted TCP cli ents <bcp14>MUST</bcp14> do one or both of the following:</t> <t>Proxy clients that send CONNECT requests on behalf of untrusted TCP cli ents <bcp14>MUST</bcp14> do one or both of the following:</t>
<ol spacing="normal" type="1"><li> <ol spacing="normal" type="1">
<li>
<t>Wait for a 2xx (Successful) response before forwarding any TCP payl oad data.</t> <t>Wait for a 2xx (Successful) response before forwarding any TCP payl oad data.</t>
</li> </li>
<li> <li>
<t>Send a "Connection: close" request header.</t> <t>Send a "Connection: close" request header.</t>
</li> </li>
</ol> </ol>
<t>Proxy clients that don't implement at least one of these two behaviors <t>Proxy clients that don't implement at least one of these two behaviors
are vulnerable to a trivial request smuggling attack (<xref section="11.2" secti are vulnerable to a trivial Request Smuggling attack (<xref section="11.2" secti
onFormat="comma" target="RFC9112"/>).</t> onFormat="comma" target="RFC9112"/>).</t>
<t>At the time of writing, some proxy clients are believed to be vulnerabl <t>At the time of writing, some proxy clients are believed to be vulnerabl
e as described. As a mitigation, proxy servers <bcp14>MUST</bcp14> close the un e as described. As a mitigation, proxy servers <bcp14>MUST</bcp14> close the un
derlying connection when rejecting a CONNECT request, without processing any fur derlying connection when rejecting a CONNECT request without processing any furt
ther requests on that connection. This requirement applies whether or not the r her requests on that connection. This requirement applies whether or not the re
equest includes a "close" connection option.</t> quest includes a "close" connection option.</t>
<t>Note that this mitigation will frequently impair the performance of cor rectly implemented clients, especially when returning a 407 (Proxy Authenticatio n Required) response. This performance loss can be avoided by using HTTP/2 or H TTP/3, which are not vulnerable to this attack.</t> <t>Note that this mitigation will frequently impair the performance of cor rectly implemented clients, especially when returning a 407 (Proxy Authenticatio n Required) response. This performance loss can be avoided by using HTTP/2 or H TTP/3, which are not vulnerable to this attack.</t>
<t>As a performance optimization, proxy servers <bcp14>MAY</bcp14> disable this mitigation if the client is known to wait for a 2xx (Successful) response before forwarding untrusted TCP payload data (i.e., complying with item 1 above) . Proxy servers can identify compliant clients using the request's User-Agent h eader field and the user agent vendor's documentation regarding its compliance.< /t> <t>As a performance optimization, proxy servers <bcp14>MAY</bcp14> disable this mitigation if the client is known to wait for a 2xx (Successful) response before forwarding untrusted TCP payload data (i.e., complying with item 1 above) . Proxy servers can identify compliant clients using the request's User-Agent h eader field and the user agent vendor's documentation regarding its compliance.< /t>
</section> </section>
<section anchor="security-considerations"> <section anchor="security-considerations">
<name>Security Considerations</name> <name>Security Considerations</name>
<t>This document describes security considerations related to optimistic u se of protocol transitions in HTTP/1.1.</t> <t>This document describes security considerations related to optimistic u se of protocol transitions in HTTP/1.1.</t>
</section> </section>
<section anchor="iana-considerations"> <section anchor="iana-considerations">
<name>IANA Considerations</name> <name>IANA Considerations</name>
<t>This document has no IANA actions.</t> <t>This document has no IANA actions.</t>
</section> </section>
</middle> </middle>
<back> <back>
<displayreference target="RFC9112" to="HTTP/1.1"/> <displayreference target="RFC9112" to="HTTP/1.1"/>
<displayreference target="RFC9113" to="HTTP/2"/> <displayreference target="RFC9113" to="HTTP/2"/>
<displayreference target="RFC9114" to="HTTP/3"/> <displayreference target="RFC9114" to="HTTP/3"/>
<displayreference target="RFC6455" to="WEBSOCKET"/>
<displayreference target="RFC9110" to="HTTP"/>
<displayreference target="RFC8446" to="TLS"/>
<displayreference target="RFC9484" to="CONNECT-IP"/>
<displayreference target="RFC9298" to="CONNECT-UDP"/>
<references anchor="sec-combined-references"> <references anchor="sec-combined-references">
<name>References</name> <name>References</name>
<references anchor="sec-normative-references"> <references anchor="sec-normative-references">
<name>Normative References</name> <name>Normative References</name>
<reference anchor="RFC9112"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
<front> 112.xml"/>
<title>HTTP/1.1</title> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
<author fullname="R. Fielding" initials="R." role="editor" surname=" 119.xml"/>
Fielding"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
<author fullname="M. Nottingham" initials="M." role="editor" surname 174.xml"/>
="Nottingham"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
<author fullname="J. Reschke" initials="J." role="editor" surname="R 110.xml"/>
eschke"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
<date month="June" year="2022"/> 298.xml"/>
<abstract>
<t>The Hypertext Transfer Protocol (HTTP) is a stateless applicati
on-level protocol for distributed, collaborative, hypertext information systems.
This document specifies the HTTP/1.1 message syntax, message parsing, connectio
n management, and related security concerns.</t>
<t>This document obsoletes portions of RFC 7230.</t>
</abstract>
</front>
<seriesInfo name="STD" value="99"/>
<seriesInfo name="RFC" value="9112"/>
<seriesInfo name="DOI" value="10.17487/RFC9112"/>
</reference>
<reference anchor="RFC2119">
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</tit
le>
<author fullname="S. Bradner" initials="S." surname="Bradner"/>
<date month="March" year="1997"/>
<abstract>
<t>In many standards track documents several words are used to sig
nify the requirements in the specification. These words are often capitalized. T
his document defines these words as they should be interpreted in IETF documents
. This document specifies an Internet Best Current Practices for the Internet Co
mmunity, and requests discussion and suggestions for improvements.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="2119"/>
<seriesInfo name="DOI" value="10.17487/RFC2119"/>
</reference>
<reference anchor="RFC8174">
<front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</ti
tle>
<author fullname="B. Leiba" initials="B." surname="Leiba"/>
<date month="May" year="2017"/>
<abstract>
<t>RFC 2119 specifies common key words that may be used in protoco
l specifications. This document aims to reduce the ambiguity by clarifying that
only UPPERCASE usage of the key words have the defined special meanings.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="8174"/>
<seriesInfo name="DOI" value="10.17487/RFC8174"/>
</reference>
<reference anchor="HTTP">
<front>
<title>HTTP Semantics</title>
<author fullname="R. Fielding" initials="R." role="editor" surname="
Fielding"/>
<author fullname="M. Nottingham" initials="M." role="editor" surname
="Nottingham"/>
<author fullname="J. Reschke" initials="J." role="editor" surname="R
eschke"/>
<date month="June" year="2022"/>
<abstract>
<t>The Hypertext Transfer Protocol (HTTP) is a stateless applicati
on-level protocol for distributed, collaborative, hypertext information systems.
This document describes the overall architecture of HTTP, establishes common te
rminology, and defines aspects of the protocol that are shared by all versions.
In this definition are core protocol elements, extensibility mechanisms, and the
"http" and "https" Uniform Resource Identifier (URI) schemes.</t>
<t>This document updates RFC 3864 and obsoletes RFCs 2818, 7231, 7
232, 7233, 7235, 7538, 7615, 7694, and portions of 7230.</t>
</abstract>
</front>
<seriesInfo name="STD" value="97"/>
<seriesInfo name="RFC" value="9110"/>
<seriesInfo name="DOI" value="10.17487/RFC9110"/>
</reference>
<reference anchor="CONNECT-UDP">
<front>
<title>Proxying UDP in HTTP</title>
<author fullname="D. Schinazi" initials="D." surname="Schinazi"/>
<date month="August" year="2022"/>
<abstract>
<t>This document describes how to proxy UDP in HTTP, similar to ho
w the HTTP CONNECT method allows proxying TCP in HTTP. More specifically, this d
ocument defines a protocol that allows an HTTP client to create a tunnel for UDP
communications through an HTTP server that acts as a proxy.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9298"/>
<seriesInfo name="DOI" value="10.17487/RFC9298"/>
</reference>
</references> </references>
<references anchor="sec-informative-references"> <references anchor="sec-informative-references">
<name>Informative References</name> <name>Informative References</name>
<reference anchor="RFC9113"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
<front> 113.xml"/>
<title>HTTP/2</title> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
<author fullname="M. Thomson" initials="M." role="editor" surname="T 114.xml"/>
homson"/>
<author fullname="C. Benfield" initials="C." role="editor" surname="
Benfield"/>
<date month="June" year="2022"/>
<abstract>
<t>This specification describes an optimized expression of the sem
antics of the Hypertext Transfer Protocol (HTTP), referred to as HTTP version 2
(HTTP/2). HTTP/2 enables a more efficient use of network resources and a reduced
latency by introducing field compression and allowing multiple concurrent excha
nges on the same connection.</t>
<t>This document obsoletes RFCs 7540 and 8740.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9113"/>
<seriesInfo name="DOI" value="10.17487/RFC9113"/>
</reference>
<reference anchor="RFC9114">
<front>
<title>HTTP/3</title>
<author fullname="M. Bishop" initials="M." role="editor" surname="Bi
shop"/>
<date month="June" year="2022"/>
<abstract>
<t>The QUIC transport protocol has several features that are desir
able in a transport for HTTP, such as stream multiplexing, per-stream flow contr
ol, and low-latency connection establishment. This document describes a mapping
of HTTP semantics over QUIC. This document also identifies HTTP/2 features that
are subsumed by QUIC and describes how HTTP/2 extensions can be ported to HTTP/3
.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9114"/>
<seriesInfo name="DOI" value="10.17487/RFC9114"/>
</reference>
<reference anchor="IANA-UPGR" target="https://www.iana.org/assignments/h ttp-upgrade-tokens/"> <reference anchor="IANA-UPGR" target="https://www.iana.org/assignments/h ttp-upgrade-tokens/">
<front> <front>
<title>Hypertext Transfer Protocol (HTTP) Upgrade Token Registry</ti tle> <title>Hypertext Transfer Protocol (HTTP) Upgrade Token Registry</ti tle>
<author> <author>
<organization>IANA</organization> <organization>IANA</organization>
</author> </author>
<date>n.d.</date>
</front> </front>
</reference> </reference>
<reference anchor="WEBSOCKET"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
<front> 455.xml"/>
<title>The WebSocket Protocol</title> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
<author fullname="I. Fette" initials="I." surname="Fette"/> 446.xml"/>
<author fullname="A. Melnikov" initials="A." surname="Melnikov"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
<date month="December" year="2011"/> 817.xml"/>
<abstract> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
<t>The WebSocket Protocol enables two-way communication between a 484.xml"/>
client running untrusted code in a controlled environment to a remote host that
has opted-in to communications from that code. The security model used for this
is the origin-based security model commonly used by web browsers. The protocol c
onsists of an opening handshake followed by basic message framing, layered over
TCP. The goal of this technology is to provide a mechanism for browser-based app
lications that need two-way communication with servers that does not rely on ope
ning multiple HTTP connections (e.g., using XMLHttpRequest or s and long polling
). [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6455"/>
<seriesInfo name="DOI" value="10.17487/RFC6455"/>
</reference>
<reference anchor="TLS">
<front>
<title>The Transport Layer Security (TLS) Protocol Version 1.3</titl
e>
<author fullname="E. Rescorla" initials="E." surname="Rescorla"/>
<date month="August" year="2018"/>
<abstract>
<t>This document specifies version 1.3 of the Transport Layer Secu
rity (TLS) protocol. TLS allows client/server applications to communicate over t
he Internet in a way that is designed to prevent eavesdropping, tampering, and m
essage forgery.</t>
<t>This document updates RFCs 5705 and 6066, and obsoletes RFCs 50
77, 5246, and 6961. This document also specifies new requirements for TLS 1.2 im
plementations.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8446"/>
<seriesInfo name="DOI" value="10.17487/RFC8446"/>
</reference>
<reference anchor="RFC2817">
<front>
<title>Upgrading to TLS Within HTTP/1.1</title>
<author fullname="R. Khare" initials="R." surname="Khare"/>
<author fullname="S. Lawrence" initials="S." surname="Lawrence"/>
<date month="May" year="2000"/>
<abstract>
<t>This memo explains how to use the Upgrade mechanism in HTTP/1.1
to initiate Transport Layer Security (TLS) over an existing TCP connection. [ST
ANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="2817"/>
<seriesInfo name="DOI" value="10.17487/RFC2817"/>
</reference>
<reference anchor="CONNECT-IP">
<front>
<title>Proxying IP in HTTP</title>
<author fullname="T. Pauly" initials="T." role="editor" surname="Pau
ly"/>
<author fullname="D. Schinazi" initials="D." surname="Schinazi"/>
<author fullname="A. Chernyakhovsky" initials="A." surname="Chernyak
hovsky"/>
<author fullname="M. Kühlewind" initials="M." surname="Kühlewind"/>
<author fullname="M. Westerlund" initials="M." surname="Westerlund"/
>
<date month="October" year="2023"/>
<abstract>
<t>This document describes how to proxy IP packets in HTTP. This p
rotocol is similar to UDP proxying in HTTP but allows transmitting arbitrary IP
packets. More specifically, this document defines a protocol that allows an HTTP
client to create an IP tunnel through an HTTP server that acts as an IP proxy.
This document updates RFC 9298.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9484"/>
<seriesInfo name="DOI" value="10.17487/RFC9484"/>
</reference>
</references> </references>
</references> </references>
<?line 256?>
<section numbered="false" anchor="acknowledgments"> <section numbered="false" anchor="acknowledgments">
<name>Acknowledgments</name> <name>Acknowledgments</name>
<t>This document benefited from valuable reviews and suggestions by:</t> <t>This document benefited from valuable reviews and suggestions by:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>Mike Bishop</t> <t><contact fullname="Mike Bishop"/></t>
</li> </li>
<li> <li>
<t>Mohamed Boucadair</t> <t><contact fullname="Mohamed Boucadair"/></t>
</li> </li>
<li> <li>
<t>Gorry Fairhurst</t> <t><contact fullname="Gorry Fairhurst"/></t>
</li> </li>
<li> <li>
<t>Mark Nottingham</t> <t><contact fullname="Mark Nottingham"/></t>
</li> </li>
<li> <li>
<t>Kazuho Oku</t> <t><contact fullname="Kazuho Oku"/></t>
</li> </li>
<li> <li>
<t>Lucas Pardue</t> <t><contact fullname="Lucas Pardue"/></t>
</li> </li>
<li> <li>
<t>David Schinazi</t> <t><contact fullname="David Schinazi"/></t>
</li> </li>
<li> <li>
<t>Glenn Strauss</t> <t><contact fullname="Glenn Strauss"/></t>
</li> </li>
<li> <li>
<t>Michael Sweet</t> <t><contact fullname="Michael Sweet"/></t>
</li> </li>
<li> <li>
<t>Willy Tarreau</t> <t><contact fullname="Willy Tarreau"/></t>
</li> </li>
<li> <li>
<t>Martin Thomson</t> <t><contact fullname="Martin Thomson"/></t>
</li> </li>
</ul> </ul>
</section> </section>
</back> </back>
<!-- ##markdown-source:
H4sIAAAAAAAAA81cW3PbRpZ+56/ooR9spUjautixVbmsLMuxKralseRKpbb2
oQk0SYxAgIMGRDMq5bfMb9lftt85p7vRACl7dqZqax+SiCS6+/S5fueCjMfj
QZ3VuTlWwyuTNFVWb9RpWdgsNZWuM/ylZmWlLlZ1tsxsnSXqsirrMilzdV1p
PCfPZIV6d319+XR/sj8c6Om0MrfYMVpFv6rPq3mlU6P8ScNBomszL6vNsbJ1
OhikZVLoJYhJKz2rx5mpZ+NFXa+mmR2XYbNxI/uMn70Y2GaKLy2IqDcrLDw/
u347KJrl1FTHgxS7Hw8SEGgK29hjVVeNGYCyw4GujAaFv5mp0kWqzovaVIWp
5VKrsqqHg3VZ3cyrslnhOSL/9fnVcHBjNvg+PR7cmqLB5krNs3rRTPEMEbqe
P6X/jM2XGkcSa4aDZkV04PRX+/sHI/Xq4NXLwUA39aIEiWqMLZSaNXkuN39t
ir/pJfj5YaKuksVaV/Uf/EhZzXWR/cFCOVYfTK3VZa5rSGdpR7hAMuHHzFJn
+bEi1v3HFB9sMsG9BoMCz2HtLdP86e0pEXPMK9LMrnINEXgJDrJitv304a6n
D8LPR7t+PsR35ycfT8afL3/5JA84bXsHaVU12CQcn5mqVawntHYvaMt1eWMK
9cnMIfxqI5voam7qY0W8tsdPn67X60mmCz0Bk55qqMO8WJqitiIMry41bWSf
8g6B/8rx9pgJHQwG4/FY6SmO0gnYdt4q9kjVC6OSPMPOKtGFqszfG2NrpVWy
0MXcqLrE34VZq5W/SlnwIvOFFLeYK+hiYRIS4USp60VmFVS+IVqJc0ljrbG8
wnpjTLrGWC80Dlyt8g2dBsXSeBSrp5uYuqmBAEEPHeCpxJ/Ya5ZVS5OOWOl1
mlomlx7JKsMso20hUVZWfoo/QGf5drdlluJx6J1JWxphgDhi4pi3zNI0N4PB
I3IkMBMhnLZ6Y2ZZIR5jMLgGubAmReZk1fDD56vr4Uj+qz5e8N+fzv76+fzT
2Rv6++rdyfv34Y+Be+Lq3cXn92/av9qVpxcfPpx9fCOL8a3qfDUYfjj5fShs
GF5cXp9ffDx5PyQ3VneEoiuW6tTgJ3iIVWXo4toOUmOTKpviA9a8Pr3873/s
H6m7u7+AWwf7+6/u792Hl/vfH+HDemEKOa0sIDr5CIFtBpCl0RXtovMcarXK
ap3DoLVVdlGuC7UwlQFrv/tP4sx/Hasfpslq/+gn9wVduPOl51nnS+bZ9jdb
i4WJO77acUzgZuf7Hqe79J783vns+R59+cPPeVYYNd5/+fNPA1Khi1tT3WZm
Tfqy21oS+BEN9n3dYqrMGma7suusThZkjLOqXAbrFuNNsxlcER3QN2EL79w1
33N+6BZH2WPIR53AMIhUVc54BczE3GpsZWsIXkPLJ/yUIx2b+CcD6aDyxlG8
1Btn59mMPIwYNmwdxsJmH2wc/4RI3LFyOi4EdZCSN8wSOjU4JOcblfhGWvFL
k6W6SAzH/Wy5ytkv6NaKZ03d4OBwqyAU8gCfJdg96EVG0PQkb1I6m1xPCEsd
JzRiw3PcZRO7u3O8hzHRfuHzuElX9/cT0pXXOuGATT8/moYP9x0vjpUu+rmd
yJdVOFBZ0JTHMmYnD9NvLGggbix1sfH+1JIGuG0PwqaHblOJfuFruAA2d2vC
cr/5ssnrDEz+wl7ZKqOTReyzUxFUk9kFqDBfVnmWIIRuyONn2AaByuilOn8D
et6Va3NLl8niqBVO1Cy1KktouaVv4Zt1Ln6Jz/XBYOfZpAvt2RJtSkuq4NQY
3jExLFm3B6QS2I7t4NdKfpB9IAj1NsDgUOw0z8u1jUMZFMlHVz7CWWWQiVga
QE8Bk/eU9MIsLFo8+bpUS0PbZXbJOuovaxvcXrfbtxaFDS7gkcIyuggd4dGJ
32FhNBEwy0yeqidw/nSpH0X8z0Zkh6xS309e3t/vjeCKMpwIorNE7IVuH117
XTbYJ89uOP7gthKYIuWky0cUl1hM3NCt6OXukHQFXoNQiA8nwf3RVfef7asn
V8EXevBl98iw64aOwu3gezJIJUnMqrZdCTip4Kp0XnvD/eeTgwmMa28iMV4I
2+Ify/z04uPHs9Nr/Ao0xmzzu7yaHE5eeN2gzRxcck9+hXGkrCxbSEVPc3zE
ba9PL2Pe1aKHdmWSDBJL1aIkHAczIOhPlj1zlyarrB9k4sGXL2BigyetBYTf
w+9IHgrLQvM0tiR6XVnDzv32gsT6BNITgX54cqVOZjXLFzxYlQAjQlZvGRlZ
wn6dTuBf6wa/wsaLki7YusHIRAaD1xCSsx1rYhNhkwVSX2Z1zAa2nL9heXwt
EPkWOmm+aAoaIyWKAYdo9YYi5E+IfW49kIACRqf4pRV5DQSANJhUx5REA1up
gm5csCGvTPdkyTfVjpANnsd3vDv+e1NCGPzv9C1C/4/DruLCNIcK/s38OIzz
imqWjOHV6rLi7AIf6R+y6smiXuaPrCwfY/n4YIhgA4F2L0swzbFLB5X3uiDK
wfkMhVfkbytEawq9BSJ2JhqpJKOFzDcr6FQuLliUjR2u08ejZ8/Uk9ca4VZ2
7xjzP8MDNrt/hwu8wfiI+PCJrwy5OowhASgpl0scRFpPEXBB+Nc7s1vANEO3
n+Fu2sKQRs4zC8KKvFlaYj/SadusmEMUmr33Z0/w2AYLTHswRz3JJmYy6j4M
7VmVFFXiBM7CVcMCsjronfX+OHjZLmE3hQQwzebWniuBj9Fl2mrqOgPop2s4
rMPXQKDFJ0ZCqqQ9g9FKwIuSOt6XP9uyqRITqF2UpTUuxLGWxJigR7JDXv2w
SykyIQT2YQ5tyn284flr+FM73pHdRRRKjijgnLR7krp9kpPTPfG9Dk1LQp3n
huILJUaFOuF03VU/Wi+7M+hGoWh/8sKFIrmwZxPUDqEEvE2Z9Icd/CE5+E9Q
/Eq27EbH7RMPJ0cS+a6yZZbrKt+M3M4W6YZArnzjvUEnBnqYFlSe05Vv6n28
R5BriGvgJrRW++DAQYAgFpkEAya37aoEtNv49fEqGCmtmgrzcmYZdmqKihAj
AhR0rozokrjWR2FuY0j4y+Z/o29YkBjGlOCphEDhHcc4z7NOiGaTClGC47DL
3OEzCTGEeLMdJljbkqSsJANiJWiNZuDETRif4iKpgvGRra0LCbvm2EpCVOsG
0q2sMjq6AcU5WRHpJrwkYmhtGKgXXfSwBNjQhLz6TowOf1zvhMsZ43nKHomi
TA6XQg15Te033fs/CpT7z4eSlgk65BrQyN86yoz7dyaAo777DjyjL6rNd98R
C9MsIOKuSsVioF9i197Jl5g98LuwKO2SDlhvNtt48EY/OwXH+baZzZAK4ZSY
gBHOS7Rg9aCOy2y+qHehJb6+LamqoOGqO4KURdBZxC8PEdotQQglBlICdPYW
bCFWsk4W08FmXFPwzO2rqURJthP2VpYArkk9FO7QiITUeBJtM3VZZZtztqGA
6ifdA9hSxZLkBAHezGzZNzgumCR54K0SbAmXQJSmTUJuK9eSFy+X4Jz25hPi
1SyrrPcCTsE61dph22MgjDUcMfllQ4g9Y5fjVUwk8diGULRVzqVMvaz61VzJ
oV0xpXR3jY4dQoUW+jaDDVFF47K0NoOLbcs451xqHQx+o1JWHTJbzqgpvZWU
HRJZ6aqmQAYYyV7bBdId+H+HI6Fo3F4TGGiHStHWdVUy54uSGdkrCB9LUYEo
2ahlQxlWjqiRbiiaQLnxQ5TEuwS2ZInhUtMMZ1UbKXZtu0stkA+MM7Elczhs
H7NOQxwXEPO5ZAZGELMcj9gcItO0FNC8YK0rWHECXqVjuQ0R1bcpraYVsB8u
8UQe2t9zRiI3EubH0I0UuMrIRbkVB3tiMCtdL0YO3ViOrxTQWOlLYjqwUUqK
rtXaTCEOI7XMuH7Z3fiQEmhoUz2OaoUB5AbE8ZuZXpXJDULl3d3Pv529vro4
/fXsmqoYL46eP6dUzsMa0TrmLZdiJDO7NU5ewJ+4tJDIfBMtIKcnrO4zUzlg
xtCirhrrM28RPD+StQVXxWlwLQUsUDPUda1BeDVuGTR09Q9ElalHMxTrtp+U
7bk633Ysd6o8tKLJa+53kgJRowlAK+Eq71Y35NEjn4epq2Uzn+fwIOz19fb3
jiyClK482YGxBGKZEQ9ST05SmE61cClnrbWLXy6+RS0MV8FzEUVz6qlTiWM6
72iqsNH6s60gyA41bLYro2/IUMmD5bNuMkb1Lrix6WZF3Tmft/vUi9ocVZMT
8p+ytyWagzFy+o9IwXwFMdu840iQgP3ekCM35m4Ip2pa5xg4EXtip2XMsBmX
IaemXhvRwGWrup5nrii2s2rYItMsOs0FgzZMSijaATp3gJXzmaRYBCRs7K62
z4AauK0h2KgaGLxkN4oSqqG0NRQlY+ZsQeta35gWrDowbdXOqNgpP/grNL7H
2e2UdkLvyJU7ES74GtwZ2QJCohYB3j9sG8X2eV9VedG1tNtVpQyESKmr7BZe
p3X8vuEUXLxP6RyLxWnF7d9b8hMSAIK3426PwwYeCAUpEe6N0qPUFxQkoXLs
cDguCn/jHPLO46UkUVdD9U7/+v2VOpVjTg0C4sxVVuGKfsZv5P1fHh29aP3R
0eSIHdKo6wMSLlnHsY6BxuXFVVvt2qoWU73okJybhwGdGzlxM4wv6HLljJse
3bLnFrcABDNOuaWZywCip14e4fTLcTOd5babT/K1sLZVNL52K63H7gyuuUbW
3ZXYN1Trzz//5IBx9tfPZ1fXV+rRIwKAFL+WmtouJcwoOjPq6uwobmsgsoJ7
fNgc20QJvW89sO3QbScDz4OiHJNOjKOnJ07Jj4+ODtv5kHcAEsffepw7cpLF
x12Llr+77xV1OMX5YBvSCapm9C/KnprmX7h2SMXSjrLFNjJxzLxt8sJUVLbw
ytLVDNpvzV3NVne6+/ARTxuge532WSKPOCYMTgWzjd+bYl4vjtX+weHR8xeD
wQ+8xbRMNz049yBXfhIwcXZ1efHx6swrB+cAPZ6EpgEnIRG3femFi4EIbRts
0JZSdpgCstmm01mhuoQH8I5LJsUuXaqJnpXeMHd2cC+4hefPjtQvMAzCKNcA
8Yj7Wwx75k1AiO/HUY7/pid0KZ6E9r4okLMy9hORd5xqgq4978hAiSu8T8xk
jryI3SoRAj/pg2brJ3vL92JuU2u2Fk3C+pZHEa0dHxGx5+DZM3Xx6y6OkKO4
O55lc+q88jTVj8Mz0bi2ndmHlRIa4uBE9Rfo1KWuKGM5o2wVnhUhLoz3+Nm8
FjRbZksIoYBTel4ZKVRTw002CTaW5ZlLQfvoQKgE+mey8nKeJdsok4cf1j4D
kMQuREMfNDs4tlXZVS/V6aUYQDxt0HB+3iKbWVNWQ723lOJmuQplUvb4cNzL
Vet5uHZDfQs4UgcgOxjCw3IuGm1Dk1GcbDCpbpCR4ayvI1Hgj87lUaTbrGQJ
jYjjJbPwWyzvELZimXOB4WLl5mSAZ3xpocuWGHDuwre9tJxpj4qv8fhEty9d
OUmouSHS83gARApwpaukdeuzcYtVO/IIEAXaJLjfGLMKiUa7QUndJvJkuDgP
ORLk1inN6eg5MW72ECa0odniwQluIHU4vlBjfR2RZ1ooliAqrqitVGXcBv43
7sTCOl+uNJKXsuhO03LCcOYHejpTk1bdPfKjPvduhMqVYZWfYBPRZm5vV5Ly
ZazHtj9OVbqiZcXzmNzN6jXX7u7CyOf9veuEVQTiYLy3Al15no6diUN4VMah
w9cV19kkeR7C4w5liID/RDhbZjn7o96RYrKzrPDDQj/THN7L/e9p7kbwjqsg
Yvkimy9yqstY7ypsxoazaeexItX3SuSOnPBsQPBE3MR2YCHeSVJPirQUNnZC
UEnhqJ4QNVkExnhLOY7KliVUopZiPUeiVoG4tIa1BwfqiQsY15uVmSxAhF0g
XdvzjjGqYhehEZQsNM26mqpfIvRTGdYYsBSHtrD9+WQ/DGJt1SsOZV7jROr5
GRVHwp6dTJLCo/dxlEe7eGCqitwqdYh32YuvyXJvSKoJs6bi6mGYzRL9CeWs
4dMhFcrkb+rjtKnMPrG0rXXF4woX5Bu6hQp4DzovcJZdyZRqBNSm6STW3Pan
urFrbgcb97jE88K1unyhmqqa/j5cZvQdGTZg8jJR3CAT8gNU3vKzDkybZmkq
RSE6si3wRZWFk+DwvFpuP9Y27ch8xoai2GoDTGNvXF4m1x7XyArkXrNKLyWN
jLSmz+09J6pomm8IpxUP98Xyek7r/+IgzPjzG5mwOnj1sjtm4kVw8nsf3gMe
V3XgNTaA1tFFwysM6g14DkYurReMlDi8G+hM+GAZb0ForzP31ops90ye1P37
64Ysu557j6twVB1tpdw2gbg764IGzvEjsUlWwY3ToGZien1lvgvRHvd6Eflw
PYjMFYLsLtyyJwiZHdVO5XGl6lBV68o2KJQbXCTA4CvsbS1kSUOZVGSJehOR
sLxTl/J6QvGIrUp6CFHiZEPnwFcGbrPEhGkyX1/aEQceqtDS3Oe1n4SvGbHi
fuB4YUfd2MmzBDoJM2r0sgOjZLlsO9TBpXsaX2nt2ikoT4TOSh6K/P+h2hJJ
uN2URZjXD3O6qJ5ZPxgL18cDthNXYrLKT61LpSgms3ef1mC+qLQJMzRcCeQJ
od25ju15lGzlMUT0Ta8TmfXhg/cw5+Jgjl4e3d9D8K0j2hdP1j4HByTe1joR
WRGsl8c3LwmvwEol0uBITfVuAn6dkey3Mn7dxXl8Q9cLpEquJZ8D85mXZeoL
lWyQMHdgFqeSrm9KTawcRBUyrNh9+YQ1O4zbpztekShSHlafhpoYFVfwmJ8T
l2EUZ488z/KWGfWtOPbkq2F69HVh8MjP2ZJe0NAAUF+4LQ5/Q7Tx3alGOCVU
yy6UJhwLdgXBLCN4EVFyODli7+CnvfmcE05V/+nAyGjw22Hx7S7+sQr00K9d
cImSeghNUUc96k5DKpKhqEo7cQUS6R2UuVcz0LSAEvWH/8lVB7+3FDO7MrnP
rFqf+YGBI5Tyquw3/aMwxJheJv298fHlrEtp2CVWsAfqArNmCCB1bb3tmZrO
iJ6/Gi+0Boke9MxKbuhHhKhd2Xd8rNyd9lc8xtzj/FLebvJuI6Ra9zAPN9Zn
WOhbZLipMz/OLKDcvzFCYTUUFWyfgzLHH0a82BcT4345a4fIhINF6YPxv6BO
oJzfFSAaMhEL2PO1QzoRob0Zc25N799kVXgnxtffQ7HEz48VxnWTdVVtWAf8
7I+/iovdbkrSJahU6U42QtFOUXFCxuMXMyqQ+FGajoqzs/0UvwznyxahOBqg
6X3/jST3mmf72guPnvnRAf+SAnt3QgI+07bxewrdN/G8q/UZu1TEZNSjjOfS
Lrna6MOOFKcouPZHC7vd2RZtcQ05Ds/QXmg1BYZpOxnugAhuACe+P1G/tbnN
w3PwDmi4erHPb/pF4gntd8WdIzU8DanesSSAw95LFrtvnJY0/BYESpUFeDVK
nAvTmhJ17f2IjVhS1BHg6otv7z1YS/1Ki55ahDsLGiMpmqw6ZO+oikTEcEnD
vWRIDoEy5CU2m7s2Ttwoc2Jr02WuWuab7iunAvzj+cmtkv+O3DrOR2NF6k/Y
O7OMq3iMBwwnHLwcukImHtu9sxC63NAJu1Otc2b5sWzfo6C3QAIfXB+rHa2l
QlbmWolRiY/icKgABSWh6ocIY6QMe0YGZY5P8JeF8Ono2ffqiejcgxPM/Umw
+HRcLLzwxRFUKtdtVV6Qsrw15pMbwXJ1T0GlXMKa6BvSnXsypvpjt44gZ6Ca
vWCgLhuzfruZBgK44Lz+18y86106HSGX03F1aBPeXshqs1T7NAFyywnaZYd2
ThNTYvxsE9WVvCm1I55OsR4jfcHa8cmcW1fxnLgPPQ01PjT/fgvXU1Kd3Htz
32Odu9tQOuRPTQSUP/C/S9h6UTWUWR96QdX3W8DrbUT8wOBd7P0f8Zvr3yCD
6lSI1PykltE4/742vSlJu5wkJHNk+HMOP4O7Y3nrxKQ/Dmc6h2luxbypKYDc
iHjOdfgV0yn3oehFWBd04T6pxkCETzeM/z/Qa22vMwCNFX0qF3qJLV6XTaJT
GC+9hFpS9H+LD4umsjU9pasbBTdAngvP45tf9R/NolQXNw0+vMdaS90sZIr4
+AYOPqX/fwLQ4x8ZbZibolBX4CIgMJOQLLTJ1dXaGNr+t4wM/xqgw+hGjsNJ
sORyacti8D+biRhAKEMAAA==
<!-- [rfced] Please review the "Inclusive Language" portion of the online
Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
and let us know if any changes are needed. Updates of this nature typically
result in more precise language, which is helpful for readers.
For example, please consider whether "impair" should be updated:
Note that this mitigation will frequently impair the performance of
correctly implemented clients, especially when returning a 407 (Proxy
Authentication Required) response.
--> -->
</rfc> </rfc>
 End of changes. 57 change blocks. 
483 lines changed or deleted 192 lines changed or added

This html diff was produced by rfcdiff 1.48.