draft-ietf-httpbis-connect-tcp-11.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 March 23, 2026		Intended status: Standards Track April 23, 2026
	Expires: September 24, 2026		Expires: October 25, 2026
	Template-Driven HTTP CONNECT Proxying for TCP		Template-Driven HTTP CONNECT Proxying for TCP
	draft-ietf-httpbis-connect-tcp-11		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 September 24, 2026.		This Internet-Draft will expire on October 25, 2026.
	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
	skipping to change at page 2, line 15 ¶		skipping to change at page 2, line 15 ¶
	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 . . . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . 6		3.3. Use of Other Relevant Headers . . . . . . . . . . . . . . 7
	3.3.1. Origin-scoped Headers . . . . . . . . . . . . . . . . 6		3.3.1. Origin-scoped Headers . . . . . . . . . . . . . . . . 7
	3.3.2. Authentication Headers . . . . . . . . . . . . . . . 7		3.3.2. Authentication Headers . . . . . . . . . . . . . . . 7
	3.4. Closing Connections . . . . . . . . . . . . . . . . . . . 7		3.4. Closing Connections . . . . . . . . . . . . . . . . . . . 8
	4. Additional Connection Setup Behaviors . . . . . . . . . . . . 9		4. Additional Connection Setup Behaviors . . . . . . . . . . . . 10
	4.1. Latency optimizations . . . . . . . . . . . . . . . . . . 9		4.1. Latency optimizations . . . . . . . . . . . . . . . . . . 10
	4.2. Conveying metadata . . . . . . . . . . . . . . . . . . . 10		4.2. Conveying metadata . . . . . . . . . . . . . . . . . . . 10
	5. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 10		5. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 11
	5.1. Servers . . . . . . . . . . . . . . . . . . . . . . . . . 10		5.1. Servers . . . . . . . . . . . . . . . . . . . . . . . . . 11
	5.2. Clients . . . . . . . . . . . . . . . . . . . . . . . . . 10		5.2. Clients . . . . . . . . . . . . . . . . . . . . . . . . . 11
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 11		6. Security Considerations . . . . . . . . . . . . . . . . . . . 12
	6.1. Resource Exhaustion attacks . . . . . . . . . . . . . . . 11		6.1. Resource Exhaustion attacks . . . . . . . . . . . . . . . 12
	7. Operational Considerations . . . . . . . . . . . . . . . . . 12		7. Operational Considerations . . . . . . . . . . . . . . . . . 13
	7.1. Avoiding HTTP/1.1 . . . . . . . . . . . . . . . . . . . . 12		7.1. Avoiding HTTP/1.1 . . . . . . . . . . . . . . . . . . . . 13
	7.2. Gateway Compatibility . . . . . . . . . . . . . . . . . . 13		7.2. Gateway Compatibility . . . . . . . . . . . . . . . . . . 14
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
	8.1. New Upgrade Token . . . . . . . . . . . . . . . . . . . . 14		8.1. New Upgrade Token . . . . . . . . . . . . . . . . . . . . 14
	8.2. New MASQUE Default Template . . . . . . . . . . . . . . . 14		8.1.1. Interop testing . . . . . . . . . . . . . . . . . . . 15
	8.3. New Capsule Type . . . . . . . . . . . . . . . . . . . . 14		8.2. New MASQUE Default Template . . . . . . . . . . . . . . . 15
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . 15		8.3. New Capsule Type . . . . . . . . . . . . . . . . . . . . 15
	9.1. Normative References . . . . . . . . . . . . . . . . . . 15		8.3.1. Interop testing . . . . . . . . . . . . . . . . . . . 15
	9.2. Informative References . . . . . . . . . . . . . . . . . 16		9. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
	Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 17		9.1. Normative References . . . . . . . . . . . . . . . . . . 16
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 17		9.2. Informative References . . . . . . . . . . . . . . . . . 17
			Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 18
			Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 18
	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 ([RFC9110], Section 9.3.6). To date,		client and this destination ([RFC9110], 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
	skipping to change at page 3, line 32 ¶		skipping to change at page 3, line 33 ¶
	multiple distinct proxy services, as the server cannot distinguish		multiple distinct proxy services, as the server cannot distinguish
	them by path (as with distinct resources) or by origin (as in		them by path (as with distinct resources) or by origin (as in
	"virtual hosting").		"virtual hosting").
	The absence of an explicit origin for the proxy also rules out the		The absence of an explicit origin for the proxy also rules out the
	usual defenses against server port misdirection attacks (see		usual defenses against server port misdirection attacks (see
	Section 7.4 of [RFC9110]) and creates ambiguity about the use of		Section 7.4 of [RFC9110]) and creates ambiguity about the use of
	origin-scoped response header fields (e.g., "Alt-Svc" [RFC7838],		origin-scoped response header fields (e.g., "Alt-Svc" [RFC7838],
	"Strict-Transport-Security" [RFC6797]).		"Strict-Transport-Security" [RFC6797]).
	Classic HTTP CONNECT requests cannot carry in-stream metadata. For		Classic HTTP CONNECT requests are not extensible to carry in-stream
	example, the WRAP_UP capsule [I-D.schinazi-httpbis-wrap-up] cannot be		metadata. For example, the WRAP_UP capsule
	used with Classic HTTP CONNECT.		[I-D.ietf-httpbis-wrap-up] cannot be used with Classic HTTP CONNECT.
	1.3. Overview		1.3. Overview
	This specification describes an alternative mechanism for proxying		This specification describes an alternative mechanism for proxying
	TCP in HTTP. Like [CONNECT-UDP] and [CONNECT-IP], the proxy service		TCP in HTTP. Like [CONNECT-UDP] and [CONNECT-IP], the proxy service
	is identified by a URI Template. Proxy interactions reuse standard		is identified by a URI Template. Proxy interactions reuse standard
	HTTP components and semantics, avoiding changes to the core HTTP		HTTP components and semantics, avoiding changes to the core HTTP
	protocol.		protocol.
	2. Conventions and Definitions		2. Conventions and Definitions
	skipping to change at page 4, line 10 ¶		skipping to change at page 4, line 10 ¶
	"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.
	3. Specification		3. Specification
	A template-driven TCP transport proxy for HTTP is identified by a URI		A template-driven TCP transport proxy for HTTP is identified by a URI
	Template [RFC6570] containing variables named "target_host" and		Template [RFC6570] containing variables named "target_host" and
	"target_port". This URI Template and its variable values MUST meet		"target_port". This URI Template and its variable values MUST meet
	all the same requirements as for UDP proxying ([RFC9298], Section 2),		all the same requirements as for UDP proxying ([CONNECT-UDP],
	and are subject to the same validation rules. The client MUST		Section 2), and are subject to the same validation rules. The client
	substitute the destination host and port number into this template to		MUST substitute the destination host and port number into this
	produce the request URI. The derived URI serves as the destination		template to produce the request URI. The derived URI serves as the
	of a Capsule Protocol connection using the Upgrade Token "connect-		destination of a Capsule Protocol connection using the Upgrade Token
	tcp" (see registration in Section 8.1).		"connect-tcp" (see registration in Section 8.1).
	When using "connect-tcp", TCP payload data is sent in the payload of		When using "connect-tcp", TCP payload data is sent in the payload of
	new Capsule Types named DATA and FINAL_DATA (see registrations in		new Capsule Types named DATA and FINAL_DATA (see Figure 1 and
	Section 8.3). The ordered concatenation of these capsule payloads		registrations in Section 8.3). The ordered concatenation of these
	represents the TCP payload data. A FINAL_DATA capsule additionally		capsule payloads, which MAY be empty, represents the TCP payload
	indicates that the sender has closed this stream, semantically		data. A FINAL_DATA capsule additionally indicates that the sender
	equivalent to TCP FIN. After sending a FINAL_DATA capsule, an		has closed this stream, semantically equivalent to TCP FIN. After
	endpoint MUST NOT send any more DATA or FINAL_DATA capsules on this		sending a FINAL_DATA capsule, an endpoint MUST NOT send any more DATA
	data stream. (See Section 3.4 for related requirements.)		or FINAL_DATA capsules on this data stream. (See Section 3.4 for
			related requirements.)
	An intermediary MAY merge and split successive DATA and FINAL_DATA		DATA Capsule {
	capsules, subject to the following requirements:		Type (i) = $TBD1,
			Length (i), # MAY be zero
			TCP Payload (..),
			}
			FINAL_DATA Capsule {
			Type (i) = $TBD2,
			Length (i), # MAY be zero
			TCP Payload (..),
			}
			Figure 1: DATA and FINAL_DATA Capsule Formats
			The boundaries between DATA and FINAL_DATA capsules are not
			significant, and are not expected to match TCP segments, TLS records,
			HTTP DATA frames, QUIC STREAM frames, etc. Recipients SHOULD begin
			forwarding payload from a DATA or FINAL_DATA capsule without waiting
			to receive the entire capsule. An intermediary MAY merge and split
			successive DATA and FINAL_DATA capsules, subject to the following
			requirements:
	o There are no intervening capsules of other types.		o There are no intervening capsules of other types.
	o The order of payload content is preserved.		o The order of payload content is preserved.
	o The final emitted capsule uses the same capsule type (DATA or		o The final emitted capsule uses the same capsule type (DATA or
	FINAL_DATA) as the final input capsule, and all others use the		FINAL_DATA) as the final input capsule, and all others use the
	DATA capsule type.		DATA capsule type.
			This protocol can be extended by defining additional relevant Capsule
			Types. According to the Capsule Protocol ([RFC9297], Section 3.2),
			new Capsule Types should be ignored by pre-existing proxies and
			intermediaries. If a new Capsule Type cannot safely be ignored, the
			endpoints can confirm support using a new HTTP header field.
	3.1. In HTTP/1.1		3.1. In HTTP/1.1
	In HTTP/1.1, the client uses the proxy by issuing a request as		In HTTP/1.1, the client uses the proxy by issuing a request as
	follows:		follows:
	o The method SHALL be "GET".		o The method SHALL be "GET".
	o The request's target SHALL correspond to the URI derived from		o The request's target SHALL correspond to the URI derived from
	expansion of the proxy's URI Template.		expansion of the proxy's URI Template.
	skipping to change at page 7, line 12 ¶		skipping to change at page 7, line 35 ¶
	Unlike classic HTTP CONNECT proxies, a templated TCP proxy has an		Unlike classic HTTP CONNECT proxies, a templated TCP proxy has an
	unambiguous origin of its own. Origin-scoped headers apply to this		unambiguous origin of its own. Origin-scoped headers apply to this
	origin when they are associated with a templated TCP proxy response.		origin when they are associated with a templated TCP proxy response.
	Here are some origin-scoped headers that could potentially be sent by		Here are some origin-scoped headers that could potentially be sent by
	a templated TCP proxy:		a templated TCP proxy:
	o "Alt-Svc" [RFC7838]		o "Alt-Svc" [RFC7838]
	o "Strict-Transport-Security" [RFC6797]		o "Strict-Transport-Security" [RFC6797]
	o "Public-Key-Pins" [RFC7469]
	o "Accept-CH" [RFC8942]		o "Accept-CH" [RFC8942]
	o "Set-Cookie" [RFC6265], which has configurable scope.		o "Set-Cookie" [RFC6265], which has configurable scope.
	o "Clear-Site-Data" [CLEAR-SITE-DATA]		o "Clear-Site-Data" [CLEAR-SITE-DATA]
	3.3.2. Authentication Headers		3.3.2. Authentication Headers
	Authentication to a templated TCP proxy normally uses ordinary HTTP		Authentication to a templated TCP proxy normally uses ordinary HTTP
	authentication via the "401 (Unauthorized)" response code, the "WWW-		authentication via the "401 (Unauthorized)" response code, the "WWW-
	Authenticate" response header field, and the "Authorization" request		Authenticate" response header field, and the "Authorization" request
	header field ([RFC9110], Section 11.6). A templated TCP proxy does		header field ([RFC9110], Section 11.6). A templated TCP proxy does
	not use the "407 (Proxy Authentication Required)" response code and		not use the "407 (Proxy Authentication Required)" response code and
	related header fields ([RFC9110], Section 11.7) because they do not		related header fields ([RFC9110], Section 11.7) because they do not
	traverse HTTP gateways (see Section 7).		traverse HTTP gateways (see Section 7.2).
	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) ([RFC9110],		template share a protection space (i.e., a realm) ([RFC9110],
	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
			Section 7.2).
	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 10, line 9 ¶		skipping to change at page 10, line 35 ¶
	TCP content in early data (in HTTP/2 and HTTP/3). At the TLS layer,		TCP content in early data (in HTTP/2 and HTTP/3). At the TLS layer,
	proxies MAY ignore, reject, or accept the "early_data" extension		proxies MAY ignore, reject, or accept the "early_data" extension
	([RFC8446], Section 4.2.10). At the HTTP layer, proxies MAY process		([RFC8446], Section 4.2.10). At the HTTP layer, proxies MAY process
	the request immediately, return a "425 (Too Early)" response		the request immediately, return a "425 (Too Early)" response
	([RFC8470], Section 5.2), or delay some or all processing of the		([RFC8470], Section 5.2), or delay some or all processing of the
	request until the handshake completes. For example, a proxy with		request until the handshake completes. For example, a proxy with
	limited anti-replay defenses might choose to perform DNS resolution		limited anti-replay defenses might choose to perform DNS resolution
	of the "target_host" when a request arrives in early data, but delay		of the "target_host" when a request arrives in early data, but delay
	the TCP connection until the TLS handshake completes.		the TCP connection until the TLS handshake completes.
			When DNS resolution of "target_host" produces multiple IP addresses,
			proxies SHOULD use a racing procedure such as Happy Eyeballs
			[RFC8305] to accelerate connection establishment. Proxies that race
			multiple connection attempts MUST buffer any optimistic content until
			a connection is selected and MUST NOT transmit any payload data on
			the other connections.
	4.2. Conveying metadata		4.2. Conveying metadata
	This specification supports the "Expect: 100-continue" request header		This specification supports the "Expect: 100-continue" request header
	([RFC9110], Section 10.1.1) in any HTTP version. The "100		([RFC9110], Section 10.1.1) in any HTTP version. The "100
	(Continue)" status code confirms receipt of a request at the proxy		(Continue)" status code confirms receipt of a request at the proxy
	without waiting for the proxy-destination TCP handshake to succeed or		without waiting for the proxy-destination TCP handshake to succeed or
	fail. This might be particularly helpful when the destination host		fail. This might be particularly helpful when the destination host
	is not responding, as TCP handshakes can hang for several minutes		is not responding, as TCP handshakes can hang for several minutes
	before failing. Clients MAY send "Expect: 100-continue", and proxies		before failing. Clients MAY send "Expect: 100-continue", and proxies
	MUST respect it by returning "100 (Continue)" if the request is not		MUST respect it by returning "100 (Continue)" if the request is not
	skipping to change at page 14, line 5 ¶		skipping to change at page 14, line 30 ¶
	* only after forwarding the upgrade request to the origin and		* only after forwarding the upgrade request to the origin and
	observing a success response.		observing a success response.
	o forward the "connect-tcp" protocol to the origin.		o forward the "connect-tcp" protocol to the origin.
	o convert "connect-tcp" requests between all supported HTTP server		o convert "connect-tcp" requests between all supported HTTP server
	and client versions.		and client versions.
	o allow any "Proxy-Status" headers to traverse the gateway.		o allow any "Proxy-Status" headers to traverse the gateway.
			If the proxy relies on TLS Client Certificates for client
			authentication, the gateway must perform this authentication itself
			or pass the relevant information to the origin (e.g., using a
			"Client-Cert" request header field [RFC9440]).
	8. IANA Considerations		8. IANA Considerations
	8.1. New Upgrade Token		8.1. New Upgrade Token
	IF APPROVED, IANA is requested to add the following entry to the HTTP		IF APPROVED, IANA is requested to add the following entry to the HTTP
	Upgrade Token Registry:		Upgrade Token Registry:
	+---------------+--------------------------+-----------------+		+---------------+--------------------------+-----------------+
	| Value | Description | Reference |		| Value | Description | Reference |
	+---------------+--------------------------+-----------------+		+---------------+--------------------------+-----------------+
	| "connect-tcp" | Proxying of TCP payloads | (This document) |		| "connect-tcp" | Proxying of TCP payloads | (This document) |
	+---------------+--------------------------+-----------------+		+---------------+--------------------------+-----------------+
			8.1.1. Interop testing
			This section is to be removed before publishing as an RFC.
	For interoperability testing of this draft version, implementations		For interoperability testing of this draft version, implementations
	SHALL use the value "connect-tcp-07".		SHALL use the value "connect-tcp-12".
	8.2. New MASQUE Default Template		8.2. New MASQUE Default Template
	IF APPROVED, IANA is requested to add the following entry to the		IF APPROVED, IANA is requested to add the following entry to the
	"MASQUE URI Suffixes" registry:		"MASQUE URI Suffixes" registry:
	+--------------+--------------+-----------------+		+--------------+--------------+-----------------+
	| Path Segment | Description | Reference |		| Path Segment | Description | Reference |
	+--------------+--------------+-----------------+		+--------------+--------------+-----------------+
	| tcp | TCP Proxying | (This document) |		| tcp | TCP Proxying | (This document) |
	+--------------+--------------+-----------------+		+--------------+--------------+-----------------+
	8.3. New Capsule Type		8.3. New Capsule Type
	IF APPROVED, IANA is requested to add the following entry to the		IF APPROVED, IANA is requested to add the following entry to the
	"HTTP Capsule Types" registry:		"HTTP Capsule Types" registry:
	+------+------------+-----------+------------+------------+---------+		+-------+-----------+-----------+------------+------------+---------+
	| Valu | Capsule | Status | Reference | Change | Contact |		| Value | Capsule | Status | Reference | Change | Contact |
	| e | Type | | | Controller | |		| | Type | | | Controller | |
	+------+------------+-----------+------------+------------+---------+		+-------+-----------+-----------+------------+------------+---------+
	| (TBD | DATA | permanent | (This | IETF | HTTPBIS |		| (TBD1 | DATA | permanent | (This | IETF | HTTPBIS |
	| ) | | | document), | | |		| ) | | | document), | | |
	| | | | Section 3 | | |		| | | | Section 3 | | |
	| | | | | | |		| | | | | | |
	| (TBD | FINAL_DATA | permanent | (This | IETF | HTTPBIS |		| (TBD2 | FINAL_DAT | permanent | (This | IETF | HTTPBIS |
	| ) | | | document), | | |		| ) | A | | document), | | |
	| | | | Section 3 | | |		| | | | Section 3 | | |
	+------+------------+-----------+------------+------------+---------+		+-------+-----------+-----------+------------+------------+---------+
			8.3.1. Interop testing
			This section is to be removed before publishing as an RFC.
	For this draft version of the protocol, the Capsule Type values		For this draft version of the protocol, the Capsule Type values
	"0x2028d7f0" and "0x2028d7f1" shall be used provisionally for		"0x2028d7f2" and "0x2028d7f3" shall be used provisionally for
	testing, under the names "DATA-08" and "FINAL_DATA-08".		testing, under the names "DATA-12" and "FINAL_DATA-12".
	9. References		9. References
	9.1. Normative References		9.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>.
	[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>.
	[RFC6570] Gregorio, J., Fielding, R., Hadley, M., Nottingham, M.,		[RFC6570] Gregorio, J., Fielding, R., Hadley, M., Nottingham, M.,
	and D. Orchard, "URI Template", RFC 6570,		and D. Orchard, "URI Template", RFC 6570,
	DOI 10.17487/RFC6570, March 2012,		DOI 10.17487/RFC6570, March 2012,
	<https://www.rfc-editor.org/info/rfc6570>.		<https://www.rfc-editor.org/info/rfc6570>.
	skipping to change at page 16, line 17 ¶		skipping to change at page 17, line 20 ¶
	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		[RFC9297] Schinazi, D. and L. Pardue, "HTTP Datagrams and the
	Capsule Protocol", RFC 9297, DOI 10.17487/RFC9297, August		Capsule Protocol", RFC 9297, DOI 10.17487/RFC9297, August
	2022, <https://www.rfc-editor.org/info/rfc9297>.		2022, <https://www.rfc-editor.org/info/rfc9297>.
	[RFC9298] Schinazi, D., "Proxying UDP in HTTP", RFC 9298,
	DOI 10.17487/RFC9298, August 2022,
	<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/>.
	[CLEAR-SITE-DATA]		[CLEAR-SITE-DATA]
	"Clear Site Data", November 2017,		"Clear Site Data", November 2017,
	<https://www.w3.org/TR/clear-site-data/>.		<https://www.w3.org/TR/clear-site-data/>.
	[CONNECT-IP]		[CONNECT-IP]
	Pauly, T., Ed., Schinazi, D., Chernyakhovsky, A.,		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>.
	[CONNECT-UDP]		[I-D.ietf-httpbis-wrap-up]
	Schinazi, D., "Proxying UDP in HTTP", RFC 9298,
	DOI 10.17487/RFC9298, August 2022,
	<https://www.rfc-editor.org/info/rfc9298>.
	[I-D.schinazi-httpbis-wrap-up]
	Schinazi, D. and L. Pardue, "The HTTP Wrap Up Capsule",		Schinazi, D. and L. Pardue, "The HTTP Wrap Up Capsule",
	draft-schinazi-httpbis-wrap-up-01 (work in progress),		draft-ietf-httpbis-wrap-up-01 (work in progress), July
	October 2024.		2025.
	[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>.
	[RFC6797] Hodges, J., Jackson, C., and A. Barth, "HTTP Strict		[RFC6797] Hodges, J., Jackson, C., and A. Barth, "HTTP Strict
	Transport Security (HSTS)", RFC 6797,		Transport Security (HSTS)", RFC 6797,
	DOI 10.17487/RFC6797, November 2012,		DOI 10.17487/RFC6797, November 2012,
	<https://www.rfc-editor.org/info/rfc6797>.		<https://www.rfc-editor.org/info/rfc6797>.
	[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>.
	[RFC7469] Evans, C., Palmer, C., and R. Sleevi, "Public Key Pinning
	Extension for HTTP", RFC 7469, DOI 10.17487/RFC7469, April
	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>.
			[RFC8305] Schinazi, D. and T. Pauly, "Happy Eyeballs Version 2:
			Better Connectivity Using Concurrency", RFC 8305,
			DOI 10.17487/RFC8305, December 2017,
			<https://www.rfc-editor.org/info/rfc8305>.
	[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>.
			[RFC9440] Campbell, B. and M. Bishop, "Client-Cert HTTP Header
			Field", RFC 9440, DOI 10.17487/RFC9440, July 2023,
			<https://www.rfc-editor.org/info/rfc9440>.
	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. 29 change blocks.
	77 lines changed or deleted		127 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/