draft-ietf-httpbis-connect-tcp-08.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 June 11, 2025		Intended status: Standards Track July 01, 2025
	Expires: December 13, 2025		Expires: January 2, 2026
	Template-Driven HTTP CONNECT Proxying for TCP		Template-Driven HTTP CONNECT Proxying for TCP
	draft-ietf-httpbis-connect-tcp-08		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 December 13, 2025.		This Internet-Draft will expire on January 2, 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 16 ¶		skipping to change at page 2, line 16 ¶
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	1.1. History . . . . . . . . . . . . . . . . . . . . . . . . . 2		1.1. History . . . . . . . . . . . . . . . . . . . . . . . . . 2
	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 . . . . . . . . . . . . . . . . . 3
	3. Specification . . . . . . . . . . . . . . . . . . . . . . . . 4		3. Specification . . . . . . . . . . . . . . . . . . . . . . . . 4
	3.1. In HTTP/1.1 . . . . . . . . . . . . . . . . . . . . . . . 4		3.1. In HTTP/1.1 . . . . . . . . . . . . . . . . . . . . . . . 4
	3.2. In HTTP/2 and HTTP/3 . . . . . . . . . . . . . . . . . . 5		3.2. In HTTP/2 and HTTP/3 . . . . . . . . . . . . . . . . . . 6
	3.3. Use of Other Relevant Headers . . . . . . . . . . . . . . 6		3.3. Use of Other Relevant Headers . . . . . . . . . . . . . . 6
	3.3.1. Origin-scoped Headers . . . . . . . . . . . . . . . . 6		3.3.1. Origin-scoped Headers . . . . . . . . . . . . . . . . 6
	3.3.2. Authentication Headers . . . . . . . . . . . . . . . 7		3.3.2. Authentication Headers . . . . . . . . . . . . . . . 7
	3.4. Closing Connections . . . . . . . . . . . . . . . . . . . 7		3.4. Closing Connections . . . . . . . . . . . . . . . . . . . 7
	4. Additional Connection Setup Behaviors . . . . . . . . . . . . 9		4. Additional Connection Setup Behaviors . . . . . . . . . . . . 9
	4.1. Latency optimizations . . . . . . . . . . . . . . . . . . 9		4.1. Latency optimizations . . . . . . . . . . . . . . . . . . 9
	4.2. Conveying metadata . . . . . . . . . . . . . . . . . . . 9		4.2. Conveying metadata . . . . . . . . . . . . . . . . . . . 10
	5. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 10		5. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 10
	5.1. Servers . . . . . . . . . . . . . . . . . . . . . . . . . 10		5.1. Servers . . . . . . . . . . . . . . . . . . . . . . . . . 10
	5.2. Clients . . . . . . . . . . . . . . . . . . . . . . . . . 10		5.2. Clients . . . . . . . . . . . . . . . . . . . . . . . . . 10
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 11		6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
	6.1. Resource Exhaustion attacks . . . . . . . . . . . . . . . 11		6.1. Resource Exhaustion attacks . . . . . . . . . . . . . . . 11
	7. Operational Considerations . . . . . . . . . . . . . . . . . 12		7. Operational Considerations . . . . . . . . . . . . . . . . . 12
	7.1. Avoiding HTTP/1.1 . . . . . . . . . . . . . . . . . . . . 12		7.1. Avoiding HTTP/1.1 . . . . . . . . . . . . . . . . . . . . 12
	7.2. Gateway Compatibility . . . . . . . . . . . . . . . . . . 13		7.2. Gateway Compatibility . . . . . . . . . . . . . . . . . . 13
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
	8.1. New Upgrade Token . . . . . . . . . . . . . . . . . . . . 13		8.1. New Upgrade Token . . . . . . . . . . . . . . . . . . . . 13
	8.2. New MASQUE Default Template . . . . . . . . . . . . . . . 13		8.2. New MASQUE Default Template . . . . . . . . . . . . . . . 14
	8.3. New Capsule Type . . . . . . . . . . . . . . . . . . . . 14		8.3. New Capsule Type . . . . . . . . . . . . . . . . . . . . 14
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14		9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
	9.1. Normative References . . . . . . . . . . . . . . . . . . 14		9.1. Normative References . . . . . . . . . . . . . . . . . . 14
	9.2. Informative References . . . . . . . . . . . . . . . . . 15		9.2. Informative References . . . . . . . . . . . . . . . . . 16
	Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 17		Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 17
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 17		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 17
	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
	skipping to change at page 5, line 8 ¶		skipping to change at page 5, line 8 ¶
	o The request SHALL include a single "Host" header field containing		o The request SHALL include a single "Host" header field containing
	the origin of the proxy.		the origin of the proxy.
	o The request SHALL include a "Connection" header field with the		o The request SHALL include a "Connection" header field with the
	value "Upgrade". (Note that this requirement is case-insensitive		value "Upgrade". (Note that this requirement is case-insensitive
	as per Section 7.6.1 of [RFC9110].)		as per Section 7.6.1 of [RFC9110].)
	o The request SHALL include an "Upgrade" header field with the value		o The request SHALL include an "Upgrade" header field with the value
	"connect-tcp".		"connect-tcp".
	o The request SHOULD include a "Capsule-Protocol: ?1" header.		o The request SHOULD include a "Capsule-Protocol: ?1" header (as
			recommended in [RFC9297], Section 3.4).
	If the request is well-formed and permissible, the proxy MUST attempt		If the request is well-formed and permissible, the proxy MUST attempt
	to establish the TCP connection before sending any response status		to establish the TCP connection before sending any response status
	code other than "100 (Continue)" (see Section 4.2). If the TCP		code other than "100 (Continue)" (see Section 4.2). If the TCP
	connection is successful, the response SHALL be as follows:		connection is successful, the response SHALL be as follows:
	o The HTTP status code SHALL be "101 (Switching Protocols)".		o The HTTP status code SHALL be "101 (Switching Protocols)".
	o The response SHALL include a "Connection" header field with the		o The response SHALL include a "Connection" header field with the
	value "Upgrade".		value "Upgrade".
	o The response SHALL include a single "Upgrade" header field with		o The response SHALL include a single "Upgrade" header field with
	the value "connect-tcp".		the value "connect-tcp".
	o The response SHOULD include a "Capsule-Protocol: ?1" header.		o The response SHOULD include a "Capsule-Protocol: ?1" header (as
			above).
	If the request is malformed or impermissible, the proxy MUST return a		If the request is malformed or impermissible, the proxy MUST return a
	4XX error code. If a TCP connection was not established, the proxy		4XX error code. If a TCP connection was not established, the proxy
	MUST NOT switch protocols to "connect-tcp", and the client MAY reuse		MUST NOT switch protocols to "connect-tcp", and the client MAY reuse
	this connection for additional HTTP requests.		this connection for additional HTTP requests.
	Client Proxy		Client Proxy
	GET /proxy?target_host=192.0.2.1&target_port=443 HTTP/1.1		GET /proxy?target_host=192.0.2.1&target_port=443 HTTP/1.1
	Host: example.com		Host: example.com
	skipping to change at page 6, line 21 ¶		skipping to change at page 6, line 28 ¶
	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 [RFC9110],		these requirements represents a client error (see [RFC9110],
	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
			with a value of "?1" (as recommended in [RFC9297], Section 3.4).
	HEADERS		HEADERS
	:method = CONNECT		:method = CONNECT
	:scheme = https		:scheme = https
	:authority = request-proxy.example		:authority = request-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
	skipping to change at page 15, line 42 ¶		skipping to change at page 16, line 5 ¶
	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		[RFC9209] Nottingham, M. and P. Sikora, "The Proxy-Status HTTP
	Response Header Field", RFC 9209, DOI 10.17487/RFC9209,		Response Header Field", RFC 9209, DOI 10.17487/RFC9209,
	June 2022, <https://www.rfc-editor.org/info/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>.
			[RFC9297] Schinazi, D. and L. Pardue, "HTTP Datagrams and the
			Capsule Protocol", RFC 9297, DOI 10.17487/RFC9297, August
			2022, <https://www.rfc-editor.org/info/rfc9297>.
	[RFC9298] Schinazi, D., "Proxying UDP in HTTP", RFC 9298,		[RFC9298] 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>.
	9.2. Informative References		9.2. Informative References
	[CAPABILITY]		[CAPABILITY]
	"Good Practices for Capability URLs", February 2014,		"Good Practices for Capability URLs", February 2014,
	<https://www.w3.org/TR/capability-urls/>.		<https://www.w3.org/TR/capability-urls/>.
	skipping to change at page 17, line 5 ¶		skipping to change at page 17, line 17 ¶
	2015, <https://www.rfc-editor.org/info/rfc7469>.		2015, <https://www.rfc-editor.org/info/rfc7469>.
	[RFC7838] Nottingham, M., McManus, P., and J. Reschke, "HTTP		[RFC7838] Nottingham, M., McManus, P., and J. Reschke, "HTTP
	Alternative Services", RFC 7838, DOI 10.17487/RFC7838,		Alternative Services", RFC 7838, DOI 10.17487/RFC7838,
	April 2016, <https://www.rfc-editor.org/info/rfc7838>.		April 2016, <https://www.rfc-editor.org/info/rfc7838>.
	[RFC8942] Grigorik, I. and Y. Weiss, "HTTP Client Hints", RFC 8942,		[RFC8942] Grigorik, I. and Y. Weiss, "HTTP Client Hints", RFC 8942,
	DOI 10.17487/RFC8942, February 2021,		DOI 10.17487/RFC8942, February 2021,
	<https://www.rfc-editor.org/info/rfc8942>.		<https://www.rfc-editor.org/info/rfc8942>.
	[RFC9297] Schinazi, D. and L. Pardue, "HTTP Datagrams and the
	Capsule Protocol", RFC 9297, DOI 10.17487/RFC9297, August
	2022, <https://www.rfc-editor.org/info/rfc9297>.
	Acknowledgments		Acknowledgments
	Thanks to Amos Jeffries, Tommy Pauly, Kyle Nekritz, David Schinazi,		Thanks to Amos Jeffries, Tommy Pauly, Kyle Nekritz, David Schinazi,
	and Kazuho Oku for close review and suggested changes.		and Kazuho Oku for close review and suggested changes.
	Author's Address		Author's Address
	Benjamin M. Schwartz		Benjamin M. Schwartz
	Meta Platforms, Inc.		Meta Platforms, Inc.
End of changes. 12 change blocks.
	14 lines changed or deleted		19 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/