rfc9931v1.txt		rfc9931.txt
	Internet Engineering Task Force (IETF) B. Schwartz		Internet Engineering Task Force (IETF) B. Schwartz
	Request for Comments: 9931 Meta Platforms, Inc.		Request for Comments: 9931 Meta Platforms, Inc.
	Updates: 9112, 9298 February 2026		Updates: 9112, 9298 March 2026
	Category: Standards Track		Category: Standards Track
	ISSN: 2070-1721		ISSN: 2070-1721
	Security Considerations for Optimistic Protocol Transitions in HTTP/1.1		Security Considerations for Optimistic Protocol Transitions in HTTP/1.1
	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
	skipping to change at line 110 ¶		skipping to change at line 110 ¶
	In HTTP/1.1 [HTTP/1.1] and later, a single connection can be used for		In HTTP/1.1 [HTTP/1.1] and later, a single connection can be used for
	many requests. In HTTP/2 [HTTP/2] and HTTP/3 [HTTP/3], these		many requests. In HTTP/2 [HTTP/2] and HTTP/3 [HTTP/3], these
	requests can be multiplexed, as each request is distinguished		requests can be multiplexed, as each request is distinguished
	explicitly by its stream ID. However, in HTTP/1.1, requests are		explicitly by its stream ID. However, in HTTP/1.1, requests are
	strictly sequential, and each new request is distinguished implicitly		strictly sequential, and each new request is distinguished implicitly
	by the closure of the preceding request.		by the closure of the preceding request.
	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 ([HTTP], Section 7.8),		mechanism is the Upgrade header field ([HTTP], Section 7.8). When
	which indicates that the client would like to use this connection for		included in a request, this field indicates that the client would
	a protocol other than HTTP/1.1. The server replies with a 101		like to use this connection for a protocol other than HTTP/1.1. The
	(Switching Protocols) status code if it accepts the protocol change		server replies with a 101 (Switching Protocols) status code if it
	([HTTP], Section 15.2.2).		accepts the protocol change ([HTTP], Section 15.2.2).
	The other mechanism is the HTTP CONNECT method (Section 9.3.6 of		The other mechanism is the HTTP CONNECT method (Section 9.3.6 of
	[HTTP]). This method indicates that the client wishes to establish a		[HTTP]). This method indicates that the client wishes to establish a
	TCP connection to the specified host and port. If accepted, the		TCP connection to the specified host and port. If accepted, the
	server replies with a 2xx (Successful) response to indicate that the		server replies with a 2xx (Successful) response to indicate that the
	request was accepted and a TCP connection was established. After		request was accepted and a TCP connection was established. After
	this point, the TCP connection is acting as a TCP tunnel, not an		this point, the TCP connection is acting as a TCP tunnel, not an
	HTTP/1.1 connection.		HTTP/1.1 connection.
	Both of these mechanisms also permit the server to reject the		Both of these mechanisms also permit the server to reject the
	skipping to change at line 170 ¶		skipping to change at line 170 ¶
	* The specified destination is not allowed under server policy.		* The specified destination is not allowed under server policy.
	* The destination cannot be resolved, is unreachable, or does not		* The destination cannot be resolved, is unreachable, or does not
	accept the connection.		accept the connection.
	* The proxy requires the client to authenticate before proceeding.		* 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
	bytes received on that connection in accordance with HTTP/1.1.		bytes received on that connection in accordance with HTTP/1.1.
	[HTTP] also states:		Section 7.8 of [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).
	|
	| -- HTTP, Section 7.8
	| https://www.rfc-editor.org/rfc/rfc9110.html#section-7.8-15
	In other words, completion of the request message is a *necessary*		In other words, completion of the request message is a *necessary*
	condition for the client to begin using the new protocol. However,		condition for the client to begin using the new protocol. However,
	it is important to clarify that this is not a *sufficient* condition		it is important to clarify that this is not a *sufficient* condition
	because the server might reject the request.		because the server might reject the request.
	In some cases, the client might predict that the server is likely to		In some cases, the client might predict that the server is likely to
	accept a requested protocol transition. For example, if a request		accept a requested protocol transition. For example, if a request
	using an upgrade token recently succeeded, the client might expect		using an upgrade token recently succeeded, the client might expect
	that subsequent requests with the same upgrade token will also		that subsequent requests with the same upgrade token will also
	skipping to change at line 205 ¶		skipping to change at line 202 ¶
	4. Possible Security Issues		4. Possible Security Issues
	When there are only two distinct parties involved in an HTTP/1.1		When there are only two distinct parties involved in an HTTP/1.1
	connection (i.e., the client and the server), protocol transitions		connection (i.e., the client and the server), protocol transitions
	introduce no new security issues: Each party must already be prepared		introduce no new security issues: Each party must already be prepared
	for the other to send arbitrary data on the connection at any time.		for the other to send arbitrary data on the connection at any time.
	However, HTTP connections often involve more than two parties if the		However, HTTP connections often involve more than two parties if the
	requests or responses include third-party data. For example, a		requests or responses include third-party data. For example, a
	browser (party 1) might send an HTTP request to an origin (party 2)		browser (party 1) might send an HTTP request to an origin (party 2)
	with the path, headers, or content controlled by a website from a		with the path, headers, or content controlled by a website from a
	different origin (party 3). Post-transition protocols such as		different origin (party 3). Post-transition protocols, such as
	WebSocket [WEBSOCKET] similarly are often used to convey data chosen		WebSocket [WEBSOCKET], are also frequently used to convey data chosen
	by a third party.		by a third party.
	If the third-party data source is untrusted, then the data it		If the third-party data source is untrusted, then the data it
	provides is potentially "attacker-controlled". The combination of		provides is potentially "attacker-controlled". The combination of
	attacker-controlled data and optimistic protocol transitions results		attacker-controlled data and optimistic protocol transitions results
	in two significant security issues.		in two significant security issues.
	4.1. Request Smuggling		4.1. Request Smuggling
	In a Request Smuggling attack ([HTTP/1.1], Section 11.2), the		In a Request Smuggling attack ([HTTP/1.1], Section 11.2), the
	skipping to change at line 419 ¶		skipping to change at line 416 ¶
	behaviors are vulnerable to a trivial Request Smuggling attack		behaviors are vulnerable to a trivial Request Smuggling attack
	([HTTP/1.1], Section 11.2).		([HTTP/1.1], Section 11.2).
	At the time of writing, some proxy clients are believed to be		At the time of writing, some proxy clients are believed to be
	vulnerable as described. As a mitigation, proxy servers MUST close		vulnerable as described. As a mitigation, proxy servers MUST close
	the underlying connection when rejecting a CONNECT request without		the underlying connection when rejecting a CONNECT request without
	processing any further requests on that connection. This requirement		processing any further requests on that connection. This requirement
	applies whether or not the request includes a "close" connection		applies whether or not the request includes a "close" connection
	option.		option.
	Note that this mitigation will frequently impair the performance of		Note that this mitigation will frequently cause slower connection
	correctly implemented clients, especially when returning a 407 (Proxy		establishment for correctly implemented clients, especially when
	Authentication Required) response. This performance loss can be		returning a 407 (Proxy Authentication Required) response. This
	avoided by using HTTP/2 or HTTP/3, which are not vulnerable to this		performance loss can be avoided by using HTTP/2 or HTTP/3, which are
	attack.		not vulnerable to this attack.
	As a performance optimization, proxy servers MAY disable this		As a performance optimization, proxy servers MAY disable this
	mitigation if the client is known to wait for a 2xx (Successful)		mitigation if the client is known to wait for a 2xx (Successful)
	response before forwarding untrusted TCP payload data (i.e.,		response before forwarding untrusted TCP payload data (i.e.,
	complying with item 1 above). Proxy servers can identify compliant		complying with item 1 above). Proxy servers can identify compliant
	clients using the request's User-Agent header field and the user		clients using the request's User-Agent header field and the user
	agent vendor's documentation regarding its compliance.		agent vendor's documentation regarding its compliance.
	9. Security Considerations		9. Security Considerations
End of changes. 6 change blocks.
	17 lines changed or deleted		14 lines changed or added
This html diff was produced by rfcdiff 1.48.