draft-ietf-httpbis-connect-tcp-02.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 December 07, 2023		Intended status: Standards Track April 22, 2024
	Expires: June 9, 2024		Expires: October 24, 2024
	Template-Driven HTTP CONNECT Proxying for TCP		Template-Driven HTTP CONNECT Proxying for TCP
	draft-ietf-httpbis-connect-tcp-02		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 June 9, 2024.		This Internet-Draft will expire on October 24, 2024.
	Copyright Notice		Copyright Notice
	Copyright (c) 2023 IETF Trust and the persons identified as the		Copyright (c) 2024 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
	skipping to change at page 2, line 19 ¶		skipping to change at page 2, line 19 ¶
	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 . . . . . . . . . . . . . . . . . . 5
	3.3. Use of Relevant Headers . . . . . . . . . . . . . . . . . 6		3.3. Use of Relevant Headers . . . . . . . . . . . . . . . . . 6
	3.3.1. Origin-scoped Headers . . . . . . . . . . . . . . . . 6		3.3.1. Origin-scoped Headers . . . . . . . . . . . . . . . . 6
	3.3.2. Authentication Headers . . . . . . . . . . . . . . . 6		3.3.2. Authentication Headers . . . . . . . . . . . . . . . 7
			3.4. Relationship to the Capsule Protocol . . . . . . . . . . 7
	4. Additional Connection Setup Behaviors . . . . . . . . . . . . 7		4. Additional Connection Setup Behaviors . . . . . . . . . . . . 7
	4.1. Latency optimizations . . . . . . . . . . . . . . . . . . 7		4.1. Latency optimizations . . . . . . . . . . . . . . . . . . 7
	4.2. Conveying metadata . . . . . . . . . . . . . . . . . . . 7		4.2. Conveying metadata . . . . . . . . . . . . . . . . . . . 8
	5. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 8		5. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 8
	5.1. Servers . . . . . . . . . . . . . . . . . . . . . . . . . 8		5.1. Servers . . . . . . . . . . . . . . . . . . . . . . . . . 8
	5.2. Clients . . . . . . . . . . . . . . . . . . . . . . . . . 8		5.2. Clients . . . . . . . . . . . . . . . . . . . . . . . . . 9
	5.3. Multi-purpose proxies . . . . . . . . . . . . . . . . . . 9		5.3. Multi-purpose proxies . . . . . . . . . . . . . . . . . . 9
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 9		6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
	7. Operational Considerations . . . . . . . . . . . . . . . . . 9		7. Operational Considerations . . . . . . . . . . . . . . . . . 10
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
	8.1. New Upgrade Token . . . . . . . . . . . . . . . . . . . . 10		8.1. New Upgrade Token . . . . . . . . . . . . . . . . . . . . 11
	8.2. New MASQUE Default Template . . . . . . . . . . . . . . . 10		8.2. New MASQUE Default Template . . . . . . . . . . . . . . . 11
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10		9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
	9.1. Normative References . . . . . . . . . . . . . . . . . . 10		9.1. Normative References . . . . . . . . . . . . . . . . . . 11
	9.2. Informative References . . . . . . . . . . . . . . . . . 11		9.2. Informative References . . . . . . . . . . . . . . . . . 12
	Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 12		Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 13
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13
	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 4, line 14 ¶		skipping to change at page 4, line 16 ¶
	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
	"tcp_port". The client substitutes the destination host and port		"tcp_port". The client substitutes the destination host and port
	number into these variables to produce the request URI.		number into these variables to produce the request URI.
	The "target_host" variable MUST be a domain name, an IP address		The "target_host" variable MUST be a domain name, an IP address
	literal, or a list of IP addresses. The "tcp_port" variable MUST be		literal, or a list of IP addresses. The "tcp_port" variable MUST be
	a single integer. If "target_host" is a list (as in Section 2.4.2 of		a single integer. If "target_host" is a list (as in Section 3.2.1 of
	[RFC6570]), the server SHOULD perform the same connection procedure		[RFC6570]), the server SHOULD perform the same connection procedure
	as if these addresses had been returned in response to A and AAAA		as if these IP addresses had been returned in response to A and AAAA
	queries for a domain name.		queries for a domain name.
	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 SHALL include a single "Host" header field containing		o The request SHALL include a single "Host" header field containing
	skipping to change at page 4, line 40 ¶		skipping to change at page 4, line 42 ¶
	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'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.
	If the request is well-formed and permissible, the proxy MUST attempt		If the request is well-formed and permissible, the proxy MUST attempt
	the TCP connection before returning its response header. If the TCP		the TCP connection before sending any response status code other than
	connection is successful, the response SHALL be as follows:		"100 (Continue)" (see Section 4.2). If the TCP 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".
	If the request is malformed or impermissible, the proxy MUST return a		If the request is malformed or impermissible, the proxy MUST return a
	skipping to change at page 5, line 14 ¶		skipping to change at page 5, line 20 ¶
	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.
	After a success response is returned, the connection SHALL conform to		After a success response is returned, the connection SHALL conform to
	all the usual requirements for classic CONNECT proxies in HTTP/1.1		all the usual requirements for classic CONNECT proxies in HTTP/1.1
	([RFC9110], Section 9.3.6). Additionally, if the proxy observes a		([RFC9110], Section 9.3.6). Additionally, if the proxy observes a
	connection error from the client (e.g., a TCP RST, TCP timeout, or		connection error from the client (e.g., a TCP RST, TCP timeout, or
	TLS error), it SHOULD send a TCP RST to the target. If the proxy		TLS error), it SHOULD send a TCP RST to the target. If the proxy
	observes a connection error from the target, it SHOULD send a TLS		observes a connection error from the target, it SHOULD send a TLS
	"internal_error" alert to the client, or set the TCP RST bit if TLS		"internal_error" alert to the client, or set the TCP RST bit if TLS
	is not in use.		is not in use. These behaviors avoid truncation of transfers between
			the client and the target on vulnerable protocols (e.g., HTTP/1.1
			without TLS) while preserving the confidentiality and integrity
			guarantees of the "https" scheme.
	Client Proxy		Client Proxy
	GET /proxy?target_host=192.0.2.1&tcp_port=443 HTTP/1.1		GET /proxy?target_host=192.0.2.1&tcp_port=443 HTTP/1.1
	Host: example.com		Host: example.com
	Connection: Upgrade		Connection: Upgrade
	Upgrade: connect-tcp		Upgrade: connect-tcp
	** Proxy establishes a TCP connection to 192.0.2.1:443 **		** Proxy establishes a TCP connection to 192.0.2.1:443 **
	HTTP/1.1 101 Switching Protocols		HTTP/1.1 101 Switching Protocols
	Connection: Upgrade		Connection: Upgrade
	Upgrade: connect-tcp		Upgrade: connect-tcp
	Templated TCP proxy example in HTTP/1.1		Templated TCP proxy example in HTTP/1.1
	3.2. In HTTP/2 and HTTP/3		3.2. In HTTP/2 and HTTP/3
	In HTTP/2 and HTTP/3, the client uses the proxy by issuing an		In HTTP/2 and HTTP/3, the proxy MUST include
	"extended CONNECT" request as follows:		SETTINGS_ENABLE_CONNECT_PROTOCOL in its SETTINGS frame [RFC8441]
			[RFC9220]. The client uses the proxy by issuing an "extended
			CONNECT" request as follows:
	o The :method pseudo-header field SHALL be "CONNECT".		o The :method pseudo-header field SHALL be "CONNECT".
	o The :protocol pseudo-header field SHALL be "connect-tcp".		o The :protocol pseudo-header field SHALL be "connect-tcp".
	o The :authority pseudo-header field SHALL contain the authority of		o The :authority pseudo-header field SHALL contain the authority of
	the proxy.		the proxy.
	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.
	From this point on, the request and response SHALL conform to all the		From this point on, the request and response SHALL conform to all the
	usual requirements for classic CONNECT proxies in this HTTP version		usual requirements for classic CONNECT proxies in this HTTP version
	(see Section 8.5 of [RFC9113] and Section 4.4 of [RFC9114]).		(see Section 8.5 of [RFC9113] and Section 4.4 of [RFC9114]).
			A templated TCP proxying request that does not conform to all of
			these requirements represents a client error (see [RFC9110],
			Section 15.5) and may be malformed (see Section 8.1.1 of [RFC9113]
			and Section 4.1.2 of [RFC9114]).
	HEADERS		HEADERS
	:method = CONNECT		:method = CONNECT
	:scheme = https		:scheme = https
	:authority = request-proxy.example		:authority = request-proxy.example
	:path = /proxy?target_host=192.0.2.1,2001:db8::1&tcp_port=443		:path = /proxy?target_host=192.0.2.1,2001:db8::1&tcp_port=443
	:protocol = connect-tcp		:protocol = connect-tcp
	...		...
	Templated TCP proxy example in HTTP/2		Templated TCP proxy example in HTTP/2
	skipping to change at page 7, line 11 ¶		skipping to change at page 7, line 23 ¶
	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).
	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.
			3.4. Relationship to the Capsule Protocol
			Unlike the datagram-oriented templated HTTP proxying specifications
			[CONNECT-UDP] [CONNECT-IP], this specification does not make use of
			the Capsule Protocol [RFC9297]. A future specification could define
			a procedure for performing TCP proxying using the Capsule Protocol,
			but no such procedure is defined here.
			When implementing this specification, clients and servers MUST NOT
			send a "Capsule-Protocol: ?1" header field.
	4. Additional Connection Setup Behaviors		4. Additional Connection Setup Behaviors
	This section discusses some behaviors that are permitted or		This section discusses some behaviors that are permitted or
	recommended in order to enhance the performance or functionality of		recommended in order to enhance the performance or functionality of
	connection setup.		connection setup.
	4.1. Latency optimizations		4.1. Latency optimizations
	When using this specification in HTTP/2 or HTTP/3, clients MAY start		When using this specification in HTTP/2 or HTTP/3, clients MAY start
	sending TCP stream content optimistically, subject to flow control		sending TCP stream content optimistically, subject to flow control
	limits (Section 5.2 of [RFC9113] or Section 4.1 of [RFC9000]).		limits (Section 5.2 of [RFC9113] or Section 4.1 of [RFC9000]).
	Proxies MUST buffer this "optimistic" content until the TCP stream		Proxies MUST buffer this "optimistic" content until the TCP stream
	becomes writable, and discard it if the TCP connection fails. (This		becomes writable, and discard it if the TCP connection fails.
	"optimistic" behavior is not permitted in HTTP/1.1 because it would		(Clients MUST NOT use "optimistic" behavior in HTTP/1.1, as this
	interfere with reuse of the connection after an error response such		would interfere with reuse of the connection after an error response
	as "401 (Unauthorized)".)		such as "401 (Unauthorized)".)
	Servers that host a proxy under this specification MAY offer support		Servers that host a proxy under this specification MAY offer support
	for TLS early data in accordance with [RFC8470]. Clients MAY send		for TLS early data in accordance with [RFC8470]. Clients MAY send
	"connect-tcp" requests in early data, and MAY include "optimistic"		"connect-tcp" requests in early data, and MAY include "optimistic"
	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
	skipping to change at page 7, line 49 ¶		skipping to change at page 8, line 23 ¶
	the TCP connection until the TLS handshake completes.		the TCP connection until the TLS handshake completes.
	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. Implementation of "100 (Continue)" support is		before failing. Clients MAY send "Expect: 100-continue", and proxies
	OPTIONAL for clients and REQUIRED for proxies.		MUST respect it by returning "100 (Continue)" if the request is not
			immediately rejected.
	Proxies implementing this specification SHOULD include a "Proxy-		Proxies implementing this specification SHOULD include a "Proxy-
	Status" response header [RFC9209] in any success or failure response		Status" response header [RFC9209] in any success or failure response
	(i.e., status codes 101, 2XX, 4XX, or 5XX) to support advanced client		(i.e., status codes 101, 2XX, 4XX, or 5XX) to support advanced client
	behaviors and diagnostics. In HTTP/2 or HTTP/3, proxies MAY		behaviors and diagnostics. In HTTP/2 or HTTP/3, proxies MAY
	additionally send a "Proxy-Status" trailer in the event of an unclean		additionally send a "Proxy-Status" trailer in the event of an unclean
	shutdown.		shutdown.
	5. Applicability		5. Applicability
	skipping to change at page 11, line 14 ¶		skipping to change at page 11, line 44 ¶
	[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>.
	[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>.
			[RFC8441] McManus, P., "Bootstrapping WebSockets with HTTP/2",
			RFC 8441, DOI 10.17487/RFC8441, September 2018,
			<https://www.rfc-editor.org/info/rfc8441>.
	[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol		[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
	Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,		Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
	<https://www.rfc-editor.org/info/rfc8446>.		<https://www.rfc-editor.org/info/rfc8446>.
	[RFC8470] Thomson, M., Nottingham, M., and W. Tarreau, "Using Early		[RFC8470] Thomson, M., Nottingham, M., and W. Tarreau, "Using Early
	Data in HTTP", RFC 8470, DOI 10.17487/RFC8470, September		Data in HTTP", RFC 8470, DOI 10.17487/RFC8470, September
	2018, <https://www.rfc-editor.org/info/rfc8470>.		2018, <https://www.rfc-editor.org/info/rfc8470>.
	[RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based		[RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
	Multiplexed and Secure Transport", RFC 9000,		Multiplexed and Secure Transport", RFC 9000,
	skipping to change at page 11, line 43 ¶		skipping to change at page 12, line 30 ¶
	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		[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",
			RFC 9220, DOI 10.17487/RFC9220, June 2022,
			<https://www.rfc-editor.org/info/rfc9220>.
	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/>.
End of changes. 20 change blocks.
	30 lines changed or deleted		62 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/