draft-ietf-httpbis-optimistic-upgrade-04.txt		draft-ietf-httpbis-optimistic-upgrade-latest.txt
	HTTPBIS Working Group		HTTPBIS Working Group
	Internet-Draft Meta Platforms, Inc.		Internet-Draft Meta Platforms, Inc.
	Updates: 9112, 9298 (if approved) June 11, 2025		Updates: 9112, 9298 (if approved) August 21, 2025
	Intended status: Standards Track		Intended status: Standards Track
	Expires: December 13, 2025		Expires: February 22, 2026
	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-04		draft-ietf-httpbis-optimistic-upgrade-latest
	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 updates RFC 9298 to avoid related security		request is confirmed, and updates RFC 9112 and RFC 9298 to avoid
	issues.		related security issues.
	About This Document		About This Document
	This note is to be removed before publishing as an RFC.		This note is to be removed before publishing as an RFC.
	Status information for this document may be found at		Status information for this document may be found at
	<https://datatracker.ietf.org/doc/draft-ietf-httpbis-optimistic-		<https://datatracker.ietf.org/doc/draft-ietf-httpbis-optimistic-
	upgrade/>.		upgrade/>.
	Source for this draft and an issue tracker can be found at		Source for this draft and an issue tracker can be found at
	skipping to change at page 1, line 46 ¶		skipping to change at page 1, line 46 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.		Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on December 13, 2025.		This Internet-Draft will expire on February 22, 2026.
	Copyright Notice		Copyright Notice
	Copyright (c) 2025 IETF Trust and the persons identified as the		Copyright (c) 2025 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(https://trustee.ietf.org/license-info) in effect on the date of		(https://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 2, line 36 ¶		skipping to change at page 2, line 36 ¶
	3.2. Parser Exploits . . . . . . . . . . . . . . . . . . . . . 6		3.2. Parser Exploits . . . . . . . . . . . . . . . . . . . . . 6
	4. Operational Issues . . . . . . . . . . . . . . . . . . . . . 6		4. Operational Issues . . . . . . . . . . . . . . . . . . . . . 6
	5. Impact on HTTP Upgrade with Existing Upgrade Tokens . . . . . 6		5. Impact on HTTP Upgrade with Existing Upgrade Tokens . . . . . 6
	5.1. "TLS" . . . . . . . . . . . . . . . . . . . . . . . . . . 6		5.1. "TLS" . . . . . . . . . . . . . . . . . . . . . . . . . . 6
	5.2. "WebSocket"/"websocket" . . . . . . . . . . . . . . . . . 6		5.2. "WebSocket"/"websocket" . . . . . . . . . . . . . . . . . 6
	5.3. "connect-udp" . . . . . . . . . . . . . . . . . . . . . . 7		5.3. "connect-udp" . . . . . . . . . . . . . . . . . . . . . . 7
	5.4. "connect-ip" . . . . . . . . . . . . . . . . . . . . . . 7		5.4. "connect-ip" . . . . . . . . . . . . . . . . . . . . . . 7
	6. Guidance for Future Upgrade Tokens . . . . . . . . . . . . . 7		6. Guidance for Future Upgrade Tokens . . . . . . . . . . . . . 7
	6.1. Selection of Request Methods . . . . . . . . . . . . . . 8		6.1. Selection of Request Methods . . . . . . . . . . . . . . 8
	7. Guidance for HTTP CONNECT . . . . . . . . . . . . . . . . . . 8		7. Guidance for HTTP CONNECT . . . . . . . . . . . . . . . . . . 8
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9		8. Security Considerations . . . . . . . . . . . . . . . . . . . 9
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
	9.1. Normative References . . . . . . . . . . . . . . . . . . 9		10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
	9.2. Informative References . . . . . . . . . . . . . . . . . 9		10.1. Normative References . . . . . . . . . . . . . . . . . . 9
			10.2. Informative References . . . . . . . . . . . . . . . . . 10
	Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 10		Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 10
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10
	1. Conventions and Definitions		1. Conventions and Definitions
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in		"OPTIONAL" in this document are to be interpreted as described in
	BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all		BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
	capitals, as shown here.		capitals, as shown here.
	skipping to change at page 3, line 17 ¶		skipping to change at page 3, line 17 ¶
	In HTTP/1.1 and later, a single connection can be used for many		In HTTP/1.1 and later, a single connection can be used for many
	requests. In HTTP/2 and HTTP/3, these requests can be multiplexed,		requests. In HTTP/2 and HTTP/3, these requests can be multiplexed,
	as each request is distinguished explicitly by its stream ID.		as each request is distinguished explicitly by its stream ID.
	However, in HTTP/1.1, requests are strictly sequential, and each new		However, in HTTP/1.1, requests are strictly sequential, and each new
	request is distinguished implicitly by the closure of the preceding		request is distinguished implicitly by the closure of the preceding
	request.		request.
	HTTP/1.1 is also the only version of HTTP that allows the client to		HTTP/1.1 is also the only version of HTTP that allows the client to
	change the protocol used for the remainder of the connection. There		change the protocol used for the remainder of the connection. There
	are two mechanisms to request such a protocol transition. One		are two mechanisms to request such a protocol transition. One
	mechanism is the "Upgrade" request header field ([RFC9110],		mechanism is the Upgrade request header field ([HTTP], Section 7.8),
	Section 7.8), which indicates that the client would like to use this		which indicates that the client would like to use this connection for
	connection for a protocol other than HTTP/1.1. The server replies		a protocol other than HTTP/1.1. The server replies with a 101
	with a "101 (Switching Protocols)" status code if it accepts the		(Switching Protocols) status code if it accepts the protocol change.
	protocol change.
	The other mechanism is the HTTP "CONNECT" method. This method		The other mechanism is the HTTP CONNECT method. This method
	indicates that the client wishes to establish a TCP connection to the		indicates that the client wishes to establish a TCP connection to the
	specified host and port. The server replies with a 2xx (Successful)		specified host and port. The server replies with a 2xx (Successful)
	response to indicate that the request was accepted and a TCP		response to indicate that the request was accepted and a TCP
	connection was established. After this point, the TCP connection is		connection was established. After this point, the TCP connection is
	acting as a TCP tunnel, not an HTTP/1.1 connection.		acting as a TCP tunnel, not an 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, [RFC9110] says:		request. For example, [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.
	and		and
	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.
	Rejections are common, and can happen for a variety of reasons. An		Rejections are common, and can happen for a variety of reasons. A
	"upgrade" request might be rejected if:		request using Upgrade might be rejected if:
	o The server does not support any of the client's indicated Upgrade		o 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.
	o The server knows that an upgrade to the offered protocol will not		o 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
	resource, so it chooses to respond in HTTP/1.1.		resource, so it chooses to respond in HTTP/1.1.
	o The server requires the client to authenticate before upgrading		o The server requires the client to authenticate before upgrading
	the protocol, so it replies with the status code "401		the protocol, so it replies with the status code 401
	(Authentication Required)" and provides a challenge in an		(Authentication Required) and provides a challenge in an
	"Authorization" response header ([RFC9110], Section 11.6.2).		Authorization response header field ([HTTP], Section 11.6.2).
	o The resource has moved, so the server replies with a 3XX redirect		o The resource has moved, so the server replies with a 3xx
	status code ([RFC9110], Section 3.4).		(Redirection) status code ([HTTP], Section 3.4).
	Similarly, a CONNECT request might be rejected if:		Similarly, a CONNECT request might be rejected if:
	o The server does not support HTTP CONNECT.		o The server does not support HTTP CONNECT.
	o The specified destination is not allowed under server policy.		o The specified destination is not allowed under server policy.
	o The destination cannot be resolved, is unreachable, or does not		o The destination cannot be resolved, is unreachable, or does not
	accept the connection.		accept the connection.
	o The proxy requires the client to authenticate before proceeding.		o The proxy requires the client to authenticate before proceeding.
	After rejecting a request, the server will continue to interpret		After rejecting a request, the server will continue to interpret
	subsequent bytes on that connection in accordance with HTTP/1.1.		subsequent bytes on that connection in accordance with HTTP/1.1.
	[RFC9110] also states:		[HTTP] also states:
	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).
	However, because of the possibility of rejection, the converse is not		However, because of the possibility of rejection, the converse is not
	true: a client cannot necessarily begin using a new protocol merely		true: a client cannot necessarily begin using a new protocol merely
	because it has finished sending the corresponding request message.		because it has finished sending the corresponding request message.
	skipping to change at page 5, line 14 ¶		skipping to change at page 5, line 14 ¶
	3. Possible Security Issues		3. 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 body controlled by a website from a different		with path, headers, or content controlled by a website from a
	origin (party 3). Post-transition protocols such as WebSocket		different origin (party 3). Post-transition protocols such as
	similarly are often used to convey data chosen by a third party.		WebSocket similarly are often used to convey data chosen by a third
			party.
	If the third-party data source is untrusted, we call the data it		If the third-party data source is untrusted, we call the data it
	provides "attacker-controlled". The combination of attacker-		provides "attacker-controlled". The combination of attacker-
	controlled data and optimistic protocol transitions results in two		controlled data and optimistic protocol transitions results in two
	significant security issues.		significant security issues.
	3.1. Request Smuggling		3.1. Request Smuggling
	In a Request Smuggling attack ([RFC9112], Section 11.2) the attacker-		In a Request Smuggling attack ([RFC9112], Section 11.2) the attacker-
	controlled data is chosen in such a way that it is interpreted by the		controlled data is chosen in such a way that it is interpreted by the
	server as an additional HTTP request. These attacks allow the		server as an additional HTTP request. These attacks allow the
	attacker to speak on behalf of the client while bypassing the		attacker to speak on behalf of the client while bypassing the
	client's own rules about what requests it will issue. Request		client's own rules about what requests it will issue. Request
	Smuggling can occur if the client and server have distinct		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,
	the client doesn't know which interpretation the server will take		the client cannot know which interpretation the server will take
	until it receives the server's response status code. If it uses the		until it receives the server's response status code. If it uses the
	new protocol optimistically, this creates a risk that the server will		new protocol optimistically, this creates a risk that the server will
	interpret attacker-controlled data in the new protocol as an		interpret attacker-controlled data in the new protocol as an
	additional HTTP request issued by the client.		additional HTTP request issued by the client.
	As a trivial example, consider an HTTP CONNECT client providing		As a trivial example, consider an HTTP CONNECT client providing
	connectivity to an untrusted application. If the client is		connectivity to an untrusted application. If the client is
	authenticated to the proxy server using a connection-level		authenticated to the proxy server using a connection-level
	authentication method such as TLS Client Certificates, the attacker		authentication method such as TLS Client Certificates, the attacker
	could send an HTTP/1.1 POST request for the proxy server at the		could send an HTTP/1.1 POST request for the proxy server at the
	skipping to change at page 6, line 29 ¶		skipping to change at page 6, line 29 ¶
	continue to be used for HTTP/1.1. There is no requirement to close		continue to be used for HTTP/1.1. There is no requirement to close
	the connection in response to a rejected transition, and keeping the		the connection in response to a rejected transition, and keeping the
	connection open has performance advantages if additional HTTP		connection open has performance advantages if additional HTTP
	requests to this server are likely. Thus, it is normally		requests to this server are likely. Thus, it is normally
	inappropriate to close the connection in response to a rejected		inappropriate to close the connection in response to a rejected
	transition.		transition.
	5. Impact on HTTP Upgrade with Existing Upgrade Tokens		5. Impact on HTTP Upgrade with Existing Upgrade Tokens
	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 that are believed to be in use at		on some registered upgrade tokens that are believed to be in use at
	the time of writing.		the time of writing.
	5.1. "TLS"		5.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. A compliant HTTP/1.1		not an allowed character in an HTTP/1.1 method. A compliant HTTP/1.1
	server will treat this as a parsing error and close the connection		server will treat this as a parsing error and close the connection
	without processing further requests.		without processing further requests.
	5.2. "WebSocket"/"websocket"		5.2. "WebSocket"/"websocket"
	Section 4.1 of [RFC6455] says:		Section 4.1 of [WEBSOCKET] says:
	Once the client's opening handshake has been sent, the client MUST		Once the client's opening handshake has been sent, the client MUST
	wait for a response from the server before sending any further		wait for a response from the server before sending any further
	data.		data.
	Thus, optimistic use of HTTP Upgrade is already forbidden in the		Thus, optimistic use of HTTP Upgrade is already forbidden in the
	WebSocket protocol. Additionally, the WebSocket protocol requires		WebSocket protocol. Additionally, the WebSocket protocol requires
	high-entropy masking of client-to-server frames (Section 5.1 of		high-entropy masking of client-to-server frames (Section 5.1 of
	[RFC6455]).		[WEBSOCKET]).
	5.3. "connect-udp"		5.3. "connect-udp"
	Section 5 of [RFC9298] says:		Section 5 of [CONNECT-UDP] says:
	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.		request.
	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.,
	skipping to change at page 7, line 36 ¶		skipping to change at page 7, line 36 ¶
	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.
	5.4. "connect-ip"		5.4. "connect-ip"
	The "connect-ip" Upgrade Token is defined in [RFC9484]. Section 11		The "connect-ip" upgrade token is defined in [CONNECT-IP].
	of [RFC9484] forbids clients from sending packets optimistically in		Section 11 of [CONNECT-IP] forbids clients from sending packets
	HTTP/1.1, avoiding this issue.		optimistically in HTTP/1.1, avoiding this issue.
	6. Guidance for Future Upgrade Tokens		6. 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:
	o Forbid optimistic use of HTTP Upgrade (WebSocket, Section 4.1 of		o Forbid optimistic use of HTTP Upgrade (Section 4.1 of [WEBSOCKET],
	[RFC6455]).		Section 11 of [CONNECT-IP]).
	o Embed a fixed preamble that terminates HTTP/1.1 processing		o Embed a fixed preamble that deliberately terminates HTTP/1.1
	(HTTP/2, Section 3.4 of [RFC9113]).		processing (Section 3.4 of [RFC9113]).
	o Apply high-entropy masking of client-to-server data (WebSocket,		o Apply high-entropy masking of client-to-server data (Section 5.1
	Section 5.1 of [RFC6455]).		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.
	6.1. Selection of Request Methods		6.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 5 do not preserve HTTP		The other upgrade tokens mentioned in Section 5 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 requests with the "GET" method and an		tokens are specified only for GET requests with no content.
	empty body.
	Future specifications for Upgrade Tokens should restrict their use to		Future specifications for upgrade tokens should restrict their use to
	"GET" requests with an empty body if the HTTP method is otherwise		GET requests with no content if the HTTP method is otherwise
	irrelevant and a request body is not required. This improves		irrelevant and the request does not need to carry any message
	consistency with other Upgrade Tokens and simplifies server		content. This improves consistency with other upgrade tokens and
	implementation.		simplifies server implementation.
	7. Guidance for HTTP CONNECT		7. Guidance for HTTP CONNECT
	In HTTP/1.1, proxy clients that send CONNECT requests on behalf of		This document updates RFC 9112 to include the remaining text of this
	untrusted TCP clients MUST do one or both of the following:		section. The requirements in this section apply only to HTTP/1.1.
			Proxy clients that send CONNECT requests on behalf of untrusted TCP
			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
	(Section 3.1).		([RFC9112], 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. When communicating with potentially		vulnerable as described. As a mitigation, proxy servers MUST close
	vulnerable clients, proxy servers MUST close the underlying		the underlying connection when rejecting a CONNECT request, without
	connection when rejecting an HTTP/1.1 CONNECT request, without		processing any further requests on that connection, unless the client
	processing any further data on that connection, whether or not the		is known to wait for a 2xx (Successful) response before forwarding
	request headers include "Connection: close". Note that this		TCP payload data. This requirement applies whether or not the
	mitigation will frequently impair the performance of correctly		request includes a "close" connection option.
	implemented clients, especially when returning a "407 (Proxy
	Authentication Required)" response. This performance loss can be		Note that this mitigation will frequently impair the performance of
			correctly implemented clients, especially when returning a 407 (Proxy
			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.
	8. IANA Considerations		8. Security Considerations
			This document describes security considerations related to optimistic
			use of protocol transitions in HTTP/1.1.
			9. IANA Considerations
	This document has no IANA actions.		This document has no IANA actions.
	9. References		10. References
	9.1. Normative References		10.1. Normative References
			[CONNECT-UDP]
			Schinazi, D., "Proxying UDP in HTTP", RFC 9298,
			DOI 10.17487/RFC9298, August 2022,
			<https://www.rfc-editor.org/info/rfc9298>.
			[HTTP] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
			Ed., "HTTP Semantics", STD 97, RFC 9110,
			DOI 10.17487/RFC9110, June 2022,
			<https://www.rfc-editor.org/info/rfc9110>.
	[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/info/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/info/rfc8174>.		May 2017, <https://www.rfc-editor.org/info/rfc8174>.
	[RFC9110] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,		[RFC9112] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
	Ed., "HTTP Semantics", STD 97, RFC 9110,		Ed., "HTTP/1.1", STD 99, RFC 9112, DOI 10.17487/RFC9112,
	DOI 10.17487/RFC9110, June 2022,		June 2022, <https://www.rfc-editor.org/info/rfc9112>.
	<https://www.rfc-editor.org/info/rfc9110>.
	[RFC9298] Schinazi, D., "Proxying UDP in HTTP", RFC 9298,		10.2. Informative References
	DOI 10.17487/RFC9298, August 2022,
	<https://www.rfc-editor.org/info/rfc9298>.
	[RFC9484] Pauly, T., Ed., Schinazi, D., Chernyakhovsky, A.,		[CONNECT-IP]
			Pauly, T., Ed., Schinazi, D., Chernyakhovsky, A.,
	Kuehlewind, M., and M. Westerlund, "Proxying IP in HTTP",		Kuehlewind, 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/info/rfc9484>.		<https://www.rfc-editor.org/info/rfc9484>.
	9.2. Informative References
	[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/info/rfc2817>.		<https://www.rfc-editor.org/info/rfc2817>.
	[RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol",
	RFC 6455, DOI 10.17487/RFC6455, December 2011,
	<https://www.rfc-editor.org/info/rfc6455>.
	[RFC9112] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
	Ed., "HTTP/1.1", STD 99, RFC 9112, DOI 10.17487/RFC9112,
	June 2022, <https://www.rfc-editor.org/info/rfc9112>.
	[RFC9113] Thomson, M., Ed. and C. Benfield, Ed., "HTTP/2", RFC 9113,		[RFC9113] 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/info/rfc9113>.		<https://www.rfc-editor.org/info/rfc9113>.
			[WEBSOCKET]
			Fette, I. and A. Melnikov, "The WebSocket Protocol",
			RFC 6455, DOI 10.17487/RFC6455, December 2011,
			<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:
	o Mike Bishop		o Mike Bishop
	o Mark Nottingham		o Mark Nottingham
	o Kazuho Oku		o Kazuho Oku
End of changes. 41 change blocks.
	89 lines changed or deleted		102 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/