draft-ietf-httpbis-connect-tcp-13.txt		draft-ietf-httpbis-connect-tcp-latest.txt
	httpbis Working Group B. Schwartz		httpbis Working Group B. Schwartz
	Internet-Draft Meta Platforms, Inc.		Internet-Draft Meta Platforms, Inc.
	Intended status: Standards Track August 17, 2026		Intended status: Standards Track September 30, 2026
	Expires: February 18, 2027		Expires: April 3, 2027
	Template-Driven HTTP CONNECT Proxying for TCP		Template-Driven HTTP CONNECT Proxying for TCP
	draft-ietf-httpbis-connect-tcp-13		draft-ietf-httpbis-connect-tcp-latest
	Abstract		Abstract
	TCP proxying using HTTP CONNECT has long been part of the core HTTP		TCP proxying using HTTP CONNECT has long been part of the core HTTP
	specification. However, this proxying functionality has several		specification. However, this proxying functionality has several
	important deficiencies in modern HTTP environments. This		important deficiencies in modern HTTP environments. This
	specification defines an alternative HTTP proxy service configuration		specification defines an alternative HTTP proxy service configuration
	for TCP connections. This configuration is described by a URI		for TCP connections. This configuration is described by a URI
	Template, similar to the CONNECT-UDP and CONNECT-IP protocols.		Template, similar to the CONNECT-UDP and CONNECT-IP protocols.
	skipping to change at page 1, line 35 ¶		skipping to change at page 1, line 35 ¶
	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 February 18, 2027.		This Internet-Draft will expire on April 3, 2027.
	Copyright Notice		Copyright Notice
	Copyright (c) 2026 IETF Trust and the persons identified as the		Copyright (c) 2026 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(https://trustee.ietf.org/license-info) in effect on the date of		(https://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	1.1. History . . . . . . . . . . . . . . . . . . . . . . . . . 2		1.1. History . . . . . . . . . . . . . . . . . . . . . . . . . 3
	1.2. Problems . . . . . . . . . . . . . . . . . . . . . . . . 3		1.2. Problems . . . . . . . . . . . . . . . . . . . . . . . . 3
	1.3. Overview . . . . . . . . . . . . . . . . . . . . . . . . 3		1.3. Overview . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Conventions and Definitions . . . . . . . . . . . . . . . . . 3		2. Conventions and Definitions . . . . . . . . . . . . . . . . . 4
	3. Specification . . . . . . . . . . . . . . . . . . . . . . . . 4		3. Specification . . . . . . . . . . . . . . . . . . . . . . . . 4
	3.1. In HTTP/1.1 . . . . . . . . . . . . . . . . . . . . . . . 5		3.1. In HTTP/1.1 . . . . . . . . . . . . . . . . . . . . . . . 5
	3.2. In HTTP/2 and HTTP/3 . . . . . . . . . . . . . . . . . . 6		3.2. In HTTP/2 and HTTP/3 . . . . . . . . . . . . . . . . . . 6
	3.3. Use of Other Relevant Headers . . . . . . . . . . . . . . 7		3.3. Use of Other Relevant Headers . . . . . . . . . . . . . . 7
	3.3.1. Origin-scoped Headers . . . . . . . . . . . . . . . . 7		3.3.1. Origin-scoped Headers . . . . . . . . . . . . . . . . 7
	3.3.2. Authentication Headers . . . . . . . . . . . . . . . 7		3.3.2. Authentication Headers . . . . . . . . . . . . . . . 8
			3.3.3. Caching Headers . . . . . . . . . . . . . . . . . . . 8
	3.4. Closing Connections . . . . . . . . . . . . . . . . . . . 8		3.4. Closing Connections . . . . . . . . . . . . . . . . . . . 8
	3.4.1. Handling Invalid Data . . . . . . . . . . . . . . . . 10		3.4.1. Handling Invalid Data . . . . . . . . . . . . . . . . 10
	4. Additional Connection Setup Behaviors . . . . . . . . . . . . 10		4. Additional Connection Setup Behaviors . . . . . . . . . . . . 11
	4.1. Latency optimizations . . . . . . . . . . . . . . . . . . 10		4.1. Latency optimizations . . . . . . . . . . . . . . . . . . 11
	4.2. Conveying metadata . . . . . . . . . . . . . . . . . . . 11		4.2. Conveying metadata . . . . . . . . . . . . . . . . . . . 12
	5. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 12		5. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 12
	5.1. Servers . . . . . . . . . . . . . . . . . . . . . . . . . 12		5.1. Servers . . . . . . . . . . . . . . . . . . . . . . . . . 12
	5.2. Clients . . . . . . . . . . . . . . . . . . . . . . . . . 12		5.2. Clients . . . . . . . . . . . . . . . . . . . . . . . . . 13
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 13		6. Security Considerations . . . . . . . . . . . . . . . . . . . 14
	6.1. Resource Exhaustion attacks . . . . . . . . . . . . . . . 13		6.1. Resource Exhaustion attacks . . . . . . . . . . . . . . . 14
	7. Operational Considerations . . . . . . . . . . . . . . . . . 14		7. Operational Considerations . . . . . . . . . . . . . . . . . 15
	7.1. Avoiding HTTP/1.1 . . . . . . . . . . . . . . . . . . . . 15		7.1. Avoiding HTTP/1.1 . . . . . . . . . . . . . . . . . . . . 15
	7.2. Gateway Compatibility . . . . . . . . . . . . . . . . . . 15		7.2. Gateway Compatibility . . . . . . . . . . . . . . . . . . 16
	7.3. Timeouts . . . . . . . . . . . . . . . . . . . . . . . . 16		7.3. Timeouts . . . . . . . . . . . . . . . . . . . . . . . . 17
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
	8.1. New Upgrade Token . . . . . . . . . . . . . . . . . . . . 16		8.1. New Upgrade Token . . . . . . . . . . . . . . . . . . . . 17
	8.1.1. Interop testing . . . . . . . . . . . . . . . . . . . 17		8.1.1. Interop testing . . . . . . . . . . . . . . . . . . . 17
	8.2. New MASQUE Default Template . . . . . . . . . . . . . . . 17		8.2. New MASQUE Default Template . . . . . . . . . . . . . . . 17
	8.3. New Capsule Type . . . . . . . . . . . . . . . . . . . . 17		8.3. New Capsule Type . . . . . . . . . . . . . . . . . . . . 18
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . 17		9. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
	9.1. Normative References . . . . . . . . . . . . . . . . . . 17		9.1. Normative References . . . . . . . . . . . . . . . . . . 18
	9.2. Informative References . . . . . . . . . . . . . . . . . 19		9.2. Informative References . . . . . . . . . . . . . . . . . 19
	Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 20		Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 21
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 20		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 21
	1. Introduction		1. Introduction
	1.1. History		1.1. History
	HTTP has used the CONNECT method for proxying TCP connections since		HTTP has used the CONNECT method for proxying TCP connections since
	HTTP/1.1. When using CONNECT, the request target specifies a host		HTTP/1.1. When using CONNECT, the request target specifies a host
	and port number, and the proxy forwards TCP payloads between the		and port number, and the proxy forwards TCP payloads between the
	client and this destination ([HTTP], Section 9.3.6). To date, this		client and this destination ([HTTP], Section 9.3.6). To date, this
	is the only mechanism defined for proxying TCP over HTTP. In this		is the only mechanism defined for proxying TCP over HTTP. In this
	specification, this is referred to as a "classic HTTP CONNECT proxy".		specification, this is referred to as a "classic HTTP CONNECT proxy".
	HTTP/3 uses a UDP transport, so it cannot be forwarded using the pre-		HTTP/3 uses a UDP transport, so it cannot be forwarded using the pre-
	skipping to change at page 7, line 7 ¶		skipping to change at page 7, line 17 ¶
	o The :path and :scheme pseudo-header fields SHALL contain the path		o The :path and :scheme pseudo-header fields SHALL contain the path
	and scheme of the request URI derived from the proxy's URI		and scheme of the request URI derived from the proxy's URI
	Template.		Template.
	A templated TCP proxying request that does not conform to all of		A templated TCP proxying request that does not conform to all of
	these requirements represents a client error (see [HTTP],		these requirements represents a client error (see [HTTP],
	Section 15.5) and may be malformed (see Section 8.1.1 of [RFC9113]		Section 15.5) and may be malformed (see Section 8.1.1 of [RFC9113]
	and Section 4.1.2 of [RFC9114]).		and Section 4.1.2 of [RFC9114]).
	Additionally the "capsule-protocol" header field SHOULD be present		Additionally, the "capsule-protocol" header field SHOULD be present
	with a value of "?1" (as recommended in [CAPSULE], Section 3.4).		with a value of "?1" (as recommended in [CAPSULE], Section 3.4).
	HEADERS		HEADERS
	:method = CONNECT		:method = CONNECT
	:scheme = https		:scheme = https
	:authority = request-proxy.example		:authority = templated-proxy.example
	:path = /proxy?target_host=2001%3Adb8%3A%3A1&target_port=443		:path = /proxy?target_host=2001%3Adb8%3A%3A1&target_port=443
	:protocol = connect-tcp		:protocol = connect-tcp
	capsule-protocol = ?1		capsule-protocol = ?1
	...		...
	Templated TCP proxy example in HTTP/2		Templated TCP proxy example in HTTP/2
	3.3. Use of Other Relevant Headers		3.3. Use of Other Relevant Headers
	3.3.1. Origin-scoped Headers		3.3.1. Origin-scoped Headers
	skipping to change at page 8, line 17 ¶		skipping to change at page 8, line 26 ¶
	Clients SHOULD assume that all proxy resources generated by a single		Clients SHOULD assume that all proxy resources generated by a single
	template share a protection space (i.e., a realm) ([HTTP],		template share a protection space (i.e., a realm) ([HTTP],
	Section 11.5). For many authentication schemes, this will allow the		Section 11.5). For many authentication schemes, this will allow the
	client to avoid waiting for a "401 (Unauthorized)" response before		client to avoid waiting for a "401 (Unauthorized)" response before
	each new connection through the proxy.		each new connection through the proxy.
	TLS Client Certificate authentication can also be used (see		TLS Client Certificate authentication can also be used (see
	Section 7.2).		Section 7.2).
			3.3.3. Caching Headers
			In HTTP/2 and HTTP/3, this specification uses the CONNECT method,
			which is not subject to caching ([HTTP], Section 9.3.6). However, in
			HTTP/1.1, the method is GET, which in other usages can be cacheable.
			To minimize discrepancies between HTTP versions, the following
			requirements apply when using HTTP/1.1:
			o If the response has a heuristically cacheable status code ([HTTP],
			Section 15.1), it SHOULD also carry a "Cache-Control: no-store"
			header field.
			* This can occur if the request is rejected or the connection
			fails.
			o The proxy SHOULD NOT attach any other caching-related header
			fields to the response.
	3.4. Closing Connections		3.4. Closing Connections
	Connection termination is essentially symmetrical for proxies and		Connection termination is essentially symmetrical for proxies and
	their clients. In this section, we use the term "endpoint" to		their clients. In this section, we use the term "endpoint" to
	describe an implementation of this specification in either role.		describe an implementation of this specification in either role.
	When closing connections, endpoints are subject to the following		When closing connections, endpoints are subject to the following
	requirements:		requirements:
	o When an endpoint receives a valid TCP FIN, it MUST send a		o When an endpoint receives a valid TCP FIN, it MUST send a
	skipping to change at page 8, line 42 ¶		skipping to change at page 9, line 21 ¶
	o When a TCP connection reaches the TIME-WAIT or CLOSED state, the		o When a TCP connection reaches the TIME-WAIT or CLOSED state, the
	associated endpoint MUST close its send stream.		associated endpoint MUST close its send stream.
	* If the connection closed gracefully, the endpoint MUST close		* If the connection closed gracefully, the endpoint MUST close
	the send stream gracefully.		the send stream gracefully.
	* Otherwise, the endpoint SHOULD close the send stream abruptly,		* Otherwise, the endpoint SHOULD close the send stream abruptly,
	using a mechanism appropriate to the HTTP version:		using a mechanism appropriate to the HTTP version:
	+ HTTP/3: reset the stream with H3_CONNECT_ERROR; see [QUIC],		+ HTTP/3: reset the stream with H3_CONNECT_ERROR; see [QUIC],
	Section 19.4 and [RFC9114], Section 8.1		Section 19.4 and [RFC9114], Section 8.1.
	+ HTTP/2: reset the stream with CONNECT_ERROR; see [RFC9113],		+ HTTP/2: reset the stream with CONNECT_ERROR; see [RFC9113],
	Sections 6.4 and 7		Sections 6.4 and 7.
	+ HTTP/1.1 over TLS: TCP shutdown without a TLS closure alert;		+ HTTP/1.1 over TLS: TCP shutdown without a TLS closure alert;
	see [TLS], Section 6.1.		see [TLS], Section 6.1.
	+ HTTP/1.1 without TLS: TCP RST		+ HTTP/1.1 without TLS: TCP RST.
	o When the receive stream is closed abruptly or without a FINAL_DATA		o When the receive stream is closed abruptly or without a FINAL_DATA
	capsule received, the endpoint SHOULD send a TCP RST if the TCP		capsule received, the endpoint SHOULD send a TCP RST if the TCP
	subsystem permits it.		subsystem permits it.
	The mandatory behaviors above enable endpoints to detect any		The mandatory behaviors above enable endpoints to detect any
	truncation of incoming TCP data. The recommended behaviors propagate		truncation of incoming TCP data. The recommended behaviors propagate
	any TCP errors through the proxy connection.		any TCP errors through the proxy connection.
	+-------+ +------------+ +------------+ +-------+		In HTTP/3, endpoints MAY negotiate and use the RESET_STREAM_AT frame
	| TCP A | | Endpoint A | | Endpoint B | | TCP B |		in order to reduce data loss during an abrupt closure
	+-+-----+ +-+----------+ +----------+-+ +-----+-+		[I-D.ietf-quic-reliable-stream-reset]. However, RESET_STREAM_AT may
	+---"abc"--->+-------DATA{"abc"}------->+---"abc"--->|		not be very effective in this case, as TCP implementations will
	+----FIN---->+------FINAL_DATA{""}----->+----FIN---->|		typically discard pending data when a RST is received.
	|<---FIN-----+<-----FINAL_DATA{""}------+<---FIN-----+
	| |<----QUIC.STREAM{FIN}-----+ |		+-------+ +------------+ +------------+ +-------+
	+---FINACK-->+-----QUIC.STREAM{FIN}---->| |		| TCP A | | Endpoint A | | Endpoint B | | TCP B |
	| | | |		+-+-----+ +-+----------+ +----------+-+ +-----+-+
			+---"abc"--->+--------DATA{"abc"}------->+---"abc"--->|
			+----FIN---->+------FINAL_DATA{""}------>+----FIN---->|
			|<---FIN-----+<-----FINAL_DATA{""}-------+<---FIN-----+
			| |<----QUIC.STREAM{FIN}------+ |
			+---FINACK-->+-----QUIC.STREAM{FIN}----->| |
			| | | |
	Simple graceful termination example (HTTP/3)		Simple graceful termination example (HTTP/3)
	+-------+ +------------+ +------------+ +-------+		+-------+ +------------+ +------------+ +-------+
	| TCP A | | Endpoint A | | Endpoint B | | TCP B |		| TCP A | | Endpoint A | | Endpoint B | | TCP B |
	+-+-----+ +-+----------+ +----------+-+ +-----+-+		+-+-----+ +-+----------+ +----------+-+ +-----+-+
	+----RST---->+---RST_STREAM{CON_ERR}--->+----RST---->|		+----RST---->+----RST_STREAM{CON_ERR}--->+----RST---->|
	| | | |		| | | |
	Simple TCP RST termination example (HTTP/2)		Simple TCP RST termination example (HTTP/2)
	+-------+ +------------+ +------------+ +-------+		+-------+ +------------+ +------------+ +-------+
	| TCP A | | Endpoint A | | Endpoint B | | TCP B |		| TCP A | | Endpoint A | | Endpoint B | | TCP B |
	+-+-----+ +-+----------+ +----------+-+ +-----+-+		+-+-----+ +-+----------+ +----------+-+ +-----+-+
	+---"abc"--->+-------DATA{"abc"}------->+---"abc"--->|		+---"abc"--->+--------DATA{"abc"}------->+---"abc"--->|
	| | (... timeout @ A ...) | |		| | (... timeout @ A ...) | |
	| +--FIN (no close_notify)-->+----RST---->|		| +--FIN (no close_notify) -->+----RST---->|
	| | | |		| | | |
	Timeout example (HTTP/1.1)		Timeout example (HTTP/1.1)
	+-------+ +------------+ +------------+ +-------+		+-------+ +------------+ +------------+ +-------+
	| TCP A | | Endpoint A | | Endpoint B | | TCP B |		| TCP A | | Endpoint A | | Endpoint B | | TCP B |
	+-+-----+ +-+----------+ +----------+-+ +-----+-+		+-+-----+ +-+----------+ +----------+-+ +-----+-+
	+-----FIN--->+-------FINAL_DATA{""}---->+-----FIN--->|		+-----FIN--->+-------FINAL_DATA{""}----->+-----FIN--->|
	| | | |		| | | |
	| (FIN) | | (FIN) |		| (FIN) | | (FIN) |
	|<---"abc"---+<----FINAL_DATA{"abc"}----+<---"abc"---+		|<---"abc"---+<----FINAL_DATA{"abc"}-----+<---"abc"---+
	| |<----QUIC.STREAM{FIN}-----+ |		| |<----QUIC.STREAM{FIN}------+ |
	+-----RST--->+-----H3_CONNECT_ERROR---->+-----RST--->|		+-----RST--->+-----H3_CONNECT_ERROR----->+-----RST--->|
	| | | |		| | | |
	RST after FIN example (HTTP/3)		RST after FIN example (HTTP/3)
	3.4.1. Handling Invalid Data		3.4.1. Handling Invalid Data
	An endpoint that receives invalid data from its peer is subject to		An endpoint that receives invalid data from its peer is subject to
	the same requirements as when receiving an abrupt closure of the		the same requirements as when receiving an abrupt closure of the
	receive stream (see Section 3.4). Some examples of invalid data		receive stream (see Section 3.4). Some examples of invalid data
	include:		include:
	skipping to change at page 11, line 50 ¶		skipping to change at page 12, line 32 ¶
	o Clients can apply separate timeouts to the proxying request and		o Clients can apply separate timeouts to the proxying request and
	connection establishment.		connection establishment.
	o In HTTP/2 and HTTP/3, clients have the option to delay some or all		o In HTTP/2 and HTTP/3, clients have the option to delay some or all
	of the optimistic payload data until after confirming that the		of the optimistic payload data until after confirming that the
	request is permissible. This strategy reduces wasted effort when		request is permissible. This strategy reduces wasted effort when
	the request is rejected.		the request is rejected.
	Proxies implementing this specification SHOULD include a "Proxy-		Proxies implementing this specification SHOULD include a "Proxy-
	Status" response header field [RFC9209] in any success or failure		Status" response header field [PROXY-STATUS] in any success or
	response (i.e., status codes 101, 2XX, 4XX, or 5XX) to support		failure response (i.e., status codes 101, 2XX, 4XX, or 5XX) to
	advanced client behaviors and diagnostics. Clients and proxies MUST		support advanced client behaviors and diagnostics. Clients and
	NOT send trailer fields on "connect-tcp" streams.		proxies MUST NOT send trailer fields on "connect-tcp" streams.
	5. Applicability		5. Applicability
	5.1. Servers		5.1. Servers
	For server operators, template-driven TCP proxies are particularly		For server operators, template-driven TCP proxies are particularly
	valuable in situations where virtual-hosting is needed, or where		valuable in situations where virtual-hosting is needed, or where
	multiple proxies must share an origin. For example, the proxy might		multiple proxies must share an origin. For example, the proxy might
	benefit from sharing an HTTP gateway that provides DDoS defense,		benefit from sharing an HTTP gateway that provides DDoS defense,
	performs request sanitization, or enforces user authorization.		performs request sanitization, or enforces user authorization.
	skipping to change at page 13, line 34 ¶		skipping to change at page 14, line 16 ¶
	SHOULD retry the request using the registered default template for		SHOULD retry the request using the registered default template for
	"connect-tcp" (Figure 2). If this request succeeds, the client		"connect-tcp" (Figure 2). If this request succeeds, the client
	SHOULD record a preference for "connect-tcp" to avoid further retry		SHOULD record a preference for "connect-tcp" to avoid further retry
	delays.		delays.
	6. Security Considerations		6. Security Considerations
	Template-driven TCP proxying is largely subject to the same security		Template-driven TCP proxying is largely subject to the same security
	risks as classic HTTP CONNECT. For example, any restrictions on		risks as classic HTTP CONNECT. For example, any restrictions on
	authorized use of the proxy (see [HTTP], Section 9.3.6) apply equally		authorized use of the proxy (see [HTTP], Section 9.3.6) apply equally
	to both.		to both. The "destination_ip_prohibited" Proxy Error Type from
			Section 2.3.5 of [PROXY-STATUS] can be useful when rejecting
			unauthorized requests.
	A small additional risk is posed by the use of a URI Template parser		A small additional risk is posed by the use of a URI Template parser
	on the client side. The template input string could be crafted to		on the client side. The template input string could be crafted to
	exploit any vulnerabilities in the parser implementation. Client		exploit any vulnerabilities in the parser implementation. Client
	implementers should apply their usual precautions for code that		implementers should apply their usual precautions for code that
	processes untrusted inputs.		processes untrusted inputs.
			See Section 7 of [CONNECT-UDP] for a comparison of the risks of
			operating a TCP or UDP proxy.
	6.1. Resource Exhaustion attacks		6.1. Resource Exhaustion attacks
	A malicious client can achieve cause highly asymmetric resource usage		A malicious client can cause highly asymmetric resource usage at the
	at the proxy by colluding with a destination server and violating the		proxy by colluding with a destination server and violating the
	ordinary rules of TCP or HTTP. Some example attacks, and mitigations		ordinary rules of TCP or HTTP. Some example attacks, and mitigations
	that proxies can apply:		that proxies can apply:
	o *Connection Pileup*: A malicious client can attempt to open a		o *Connection Pileup*: A malicious client can attempt to open a
	large number of connections to exhaust the proxy's memory, port,		large number of connections to exhaust the proxy's memory, port,
	or file descriptor limits. When using HTTP/2 or HTTP/3, each		or file descriptor limits. When using HTTP/2 or HTTP/3, each
	incremental TCP connection imposes a much higher cost on the proxy		incremental TCP connection imposes a much higher cost on the proxy
	than on the attacker.		than on the attacker.
	* Mitigation: Limit the number of concurrent connections per		* Mitigation: Limit the number of concurrent connections per
	skipping to change at page 18, line 10 ¶		skipping to change at page 18, line 41 ¶
	[CONNECT-UDP]		[CONNECT-UDP]
	Schinazi, D., "Proxying UDP in HTTP", RFC 9298,		Schinazi, D., "Proxying UDP in HTTP", RFC 9298,
	DOI 10.17487/RFC9298, August 2022,		DOI 10.17487/RFC9298, August 2022,
	<https://www.rfc-editor.org/info/rfc9298>.		<https://www.rfc-editor.org/info/rfc9298>.
	[HTTP] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,		[HTTP] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
	Ed., "HTTP Semantics", STD 97, RFC 9110,		Ed., "HTTP Semantics", STD 97, RFC 9110,
	DOI 10.17487/RFC9110, June 2022,		DOI 10.17487/RFC9110, June 2022,
	<https://www.rfc-editor.org/info/rfc9110>.		<https://www.rfc-editor.org/info/rfc9110>.
			[PROXY-STATUS]
			Nottingham, M. and P. Sikora, "The Proxy-Status HTTP
			Response Header Field", RFC 9209, DOI 10.17487/RFC9209,
			June 2022, <https://www.rfc-editor.org/info/rfc9209>.
	[QUIC] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based		[QUIC] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
	Multiplexed and Secure Transport", RFC 9000,		Multiplexed and Secure Transport", RFC 9000,
	DOI 10.17487/RFC9000, May 2021,		DOI 10.17487/RFC9000, May 2021,
	<https://www.rfc-editor.org/info/rfc9000>.		<https://www.rfc-editor.org/info/rfc9000>.
	[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>.
	skipping to change at page 18, line 48 ¶		skipping to change at page 19, line 38 ¶
	Ed., "HTTP/1.1", STD 99, RFC 9112, DOI 10.17487/RFC9112,		Ed., "HTTP/1.1", STD 99, RFC 9112, DOI 10.17487/RFC9112,
	June 2022, <https://www.rfc-editor.org/info/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>.
	[RFC9114] Bishop, M., Ed., "HTTP/3", RFC 9114, DOI 10.17487/RFC9114,		[RFC9114] Bishop, M., Ed., "HTTP/3", RFC 9114, DOI 10.17487/RFC9114,
	June 2022, <https://www.rfc-editor.org/info/rfc9114>.		June 2022, <https://www.rfc-editor.org/info/rfc9114>.
	[RFC9209] Nottingham, M. and P. Sikora, "The Proxy-Status HTTP
	Response Header Field", RFC 9209, DOI 10.17487/RFC9209,
	June 2022, <https://www.rfc-editor.org/info/rfc9209>.
	[RFC9220] Hamilton, R., "Bootstrapping WebSockets with HTTP/3",		[RFC9220] Hamilton, R., "Bootstrapping WebSockets with HTTP/3",
	RFC 9220, DOI 10.17487/RFC9220, June 2022,		RFC 9220, DOI 10.17487/RFC9220, June 2022,
	<https://www.rfc-editor.org/info/rfc9220>.		<https://www.rfc-editor.org/info/rfc9220>.
	[TLS] Rescorla, E., "The Transport Layer Security (TLS) Protocol		[TLS] Rescorla, E., "The Transport Layer Security (TLS) Protocol
	Version 1.3", RFC 9846, DOI 10.17487/RFC9846, July 2026,		Version 1.3", RFC 9846, DOI 10.17487/RFC9846, July 2026,
	<https://www.rfc-editor.org/info/rfc9846>.		<https://www.rfc-editor.org/info/rfc9846>.
	9.2. Informative References		9.2. Informative References
	skipping to change at page 20, line 11 ¶		skipping to change at page 20, line 46 ¶
	Schinazi, D. and L. Pardue, "The HTTP Wrap Up Capsule",		Schinazi, D. and L. Pardue, "The HTTP Wrap Up Capsule",
	draft-ietf-httpbis-wrap-up-01 (work in progress), July		draft-ietf-httpbis-wrap-up-01 (work in progress), July
	2025.		2025.
	[I-D.ietf-intarea-proxy-config]		[I-D.ietf-intarea-proxy-config]
	Pauly, T., Damjanovic, D., and Y. Rosomakho,		Pauly, T., Damjanovic, D., and Y. Rosomakho,
	"Communicating Proxy Configurations in Provisioning		"Communicating Proxy Configurations in Provisioning
	Domains", draft-ietf-intarea-proxy-config-14 (work in		Domains", draft-ietf-intarea-proxy-config-14 (work in
	progress), May 2026.		progress), May 2026.
			[I-D.ietf-quic-reliable-stream-reset]
			Seemann, M. and K. Oku, "QUIC Stream Resets with Partial
			Delivery", draft-ietf-quic-reliable-stream-reset-11 (work
			in progress), September 2026.
	[RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265,		[RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265,
	DOI 10.17487/RFC6265, April 2011,		DOI 10.17487/RFC6265, April 2011,
	<https://www.rfc-editor.org/info/rfc6265>.		<https://www.rfc-editor.org/info/rfc6265>.
	[RFC7323] Borman, D., Braden, B., Jacobson, V., and R.		[RFC7323] Borman, D., Braden, B., Jacobson, V., and R.
	Scheffenegger, Ed., "TCP Extensions for High Performance",		Scheffenegger, Ed., "TCP Extensions for High Performance",
	RFC 7323, DOI 10.17487/RFC7323, September 2014,		RFC 7323, DOI 10.17487/RFC7323, September 2014,
	<https://www.rfc-editor.org/info/rfc7323>.		<https://www.rfc-editor.org/info/rfc7323>.
	[RFC8942] Grigorik, I. and Y. Weiss, "HTTP Client Hints", RFC 8942,		[RFC8942] Grigorik, I. and Y. Weiss, "HTTP Client Hints", RFC 8942,
End of changes. 29 change blocks.
	71 lines changed or deleted		106 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/