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 August 20, 2026
Expires: September 24, 2026 Expires: February 21, 2027
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 February 21, 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
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 3.4.1. Handling Invalid Data . . . . . . . . . . . . . . . . 10
4.1. Latency optimizations . . . . . . . . . . . . . . . . . . 9 4. Additional Connection Setup Behaviors . . . . . . . . . . . . 10
4.2. Conveying metadata . . . . . . . . . . . . . . . . . . . 10 4.1. Latency optimizations . . . . . . . . . . . . . . . . . . 10
5. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 10 4.2. Conveying metadata . . . . . . . . . . . . . . . . . . . 11
5.1. Servers . . . . . . . . . . . . . . . . . . . . . . . . . 10 5. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 12
5.2. Clients . . . . . . . . . . . . . . . . . . . . . . . . . 10 5.1. Servers . . . . . . . . . . . . . . . . . . . . . . . . . 12
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 5.2. Clients . . . . . . . . . . . . . . . . . . . . . . . . . 12
6.1. Resource Exhaustion attacks . . . . . . . . . . . . . . . 11 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
7. Operational Considerations . . . . . . . . . . . . . . . . . 12 6.1. Resource Exhaustion attacks . . . . . . . . . . . . . . . 13
7.1. Avoiding HTTP/1.1 . . . . . . . . . . . . . . . . . . . . 12 7. Operational Considerations . . . . . . . . . . . . . . . . . 14
7.2. Gateway Compatibility . . . . . . . . . . . . . . . . . . 13 7.1. Avoiding HTTP/1.1 . . . . . . . . . . . . . . . . . . . . 15
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 7.2. Gateway Compatibility . . . . . . . . . . . . . . . . . . 15
8.1. New Upgrade Token . . . . . . . . . . . . . . . . . . . . 14 7.3. Timeouts . . . . . . . . . . . . . . . . . . . . . . . . 16
8.2. New MASQUE Default Template . . . . . . . . . . . . . . . 14 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
8.3. New Capsule Type . . . . . . . . . . . . . . . . . . . . 14 8.1. New Upgrade Token . . . . . . . . . . . . . . . . . . . . 16
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 8.1.1. Interop testing . . . . . . . . . . . . . . . . . . . 17
9.1. Normative References . . . . . . . . . . . . . . . . . . 15 8.2. New MASQUE Default Template . . . . . . . . . . . . . . . 17
9.2. Informative References . . . . . . . . . . . . . . . . . 16 8.3. New Capsule Type . . . . . . . . . . . . . . . . . . . . 17
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 17 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 17 9.1. Normative References . . . . . . . . . . . . . . . . . . 17
9.2. Informative References . . . . . . . . . . . . . . . . . 19
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 20
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 20
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 ([HTTP], Section 9.3.6). To date, this
this is the only mechanism defined for proxying TCP over HTTP. In is the only mechanism defined for proxying TCP over HTTP. In this
this specification, this is referred to as a "classic HTTP CONNECT specification, this is referred to as a "classic HTTP CONNECT proxy".
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-
existing CONNECT mechanism. To enable forward proxying of HTTP/3, existing CONNECT mechanism. To enable forward proxying of HTTP/3,
the MASQUE effort has defined proxy mechanisms that are capable of the MASQUE effort has defined proxy mechanisms that are capable of
proxying UDP datagrams [CONNECT-UDP], and more generally IP datagrams proxying UDP datagrams [CONNECT-UDP], and more generally IP datagrams
[CONNECT-IP]. The destination host and port number (if applicable) [CONNECT-IP]. The destination host and port number (if applicable)
are encoded into the HTTP resource path, and end-to-end datagrams are are encoded into the HTTP resource path, and end-to-end datagrams are
wrapped into HTTP Datagrams [RFC9297] on the client-proxy path. wrapped into HTTP Datagrams [CAPSULE] on the client-proxy path.
1.2. Problems 1.2. Problems
HTTP clients can be configured to use proxies by selecting a proxy HTTP clients can be configured to use proxies by selecting a proxy
hostname, a port, and whether to use a security protocol. However, hostname, a port, and whether to use a security protocol. However,
Classic HTTP CONNECT requests using the proxy do not carry this Classic HTTP CONNECT requests using the proxy do not carry this
configuration information. Instead, they only indicate the hostname configuration information. Instead, they only indicate the hostname
and port of the target. This prevents any HTTP server from hosting and port of the target. This prevents any HTTP server from hosting
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 [HTTP]) and creates ambiguity about the use of origin-
origin-scoped response header fields (e.g., "Alt-Svc" [RFC7838], scoped response header fields (e.g., "Alt-Svc" [ALT-SVC], "Strict-
"Strict-Transport-Security" [RFC6797]). Transport-Security" [HSTS]).
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.)
DATA Capsule {
Type (i) = 0x08,
Length (i), # MAY be zero
TCP Payload (..),
}
FINAL_DATA Capsule {
Type (i) = 0x09,
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 An intermediary MAY merge and split successive DATA and FINAL_DATA
capsules, subject to the following requirements: 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.
For example, an intermediary holding two successive DATA capsules in
its transmission buffer could merge them, saving at least 2 bytes of
encapsulation overhead when they are forwarded.
This protocol can be extended by defining additional relevant Capsule
Types. According to the Capsule Protocol ([CAPSULE], 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 [RFC9112], the client uses the proxy by issuing a request
follows: as 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.
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 [HTTP].)
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 (as o The request SHOULD include a "Capsule-Protocol: ?1" header (as
recommended in [RFC9297], Section 3.4). recommended in [CAPSULE], 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".
skipping to change at page 6, line 24 skipping to change at page 6, line 52
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.
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 [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 [RFC9297], 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 = 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
... ...
skipping to change at page 7, line 8 skipping to change at page 7, line 36
the request or response. An origin-scoped HTTP header is a special the request or response. An origin-scoped HTTP header is a special
response header that is intended to change the client's behavior for response header that is intended to change the client's behavior for
subsequent requests to any resource on this origin. subsequent requests to any resource on this origin.
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" [ALT-SVC]
o "Strict-Transport-Security" [RFC6797]
o "Public-Key-Pins" [RFC7469] o "Strict-Transport-Security" [HSTS]
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 ([HTTP], Section 11.6). A templated TCP proxy does not
not use the "407 (Proxy Authentication Required)" response code and use the "407 (Proxy Authentication Required)" response code and
related header fields ([RFC9110], Section 11.7) because they do not related header fields ([HTTP], 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) ([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
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 8, line 14 skipping to change at page 8, line 41
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 + HTTP/3: reset the stream with H3_CONNECT_ERROR; see [QUIC],
[RFC9000], 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 [RFC8446], 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.
skipping to change at page 9, line 28 skipping to change at page 10, line 18
+-----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
An endpoint that receives invalid data from its peer is subject to
the same requirements as when receiving an abrupt closure of the
receive stream (see Section 3.4). Some examples of invalid data
include:
o A second FINAL_DATA capsule.
o A DATA capsule after FINAL_DATA.
o Data that results in a parsing error under the Capsule Protocol.
o A capsule that is truncated by the end of the stream.
o A capsule that would require unreasonable effort to process.
Note that very large DATA and FINAL_DATA capsules are still valid, as
they can be forwarded incrementally using a bounded memory buffer.
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 [QUIC]). Proxies
Proxies MUST buffer this "optimistic" content until the TCP stream MUST buffer this "optimistic" content until the TCP stream becomes
becomes writable, and discard it if the TCP connection fails. writable, and discard it if the TCP connection fails. (Clients MUST
(Clients MUST NOT use "optimistic" behavior in HTTP/1.1, as this NOT use "optimistic" behavior in HTTP/1.1, as this would interfere
would interfere with reuse of the connection after an error response with reuse of the connection after an error response such as "401
such as "401 (Unauthorized)".) (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 ([TLS], Section 4.2.10). At the HTTP layer, proxies MAY process the
the request immediately, return a "425 (Too Early)" response request immediately, return a "425 (Too Early)" response ([RFC8470],
([RFC8470], Section 5.2), or delay some or all processing of the Section 5.2), or delay some or all processing of the request until
request until the handshake completes. For example, a proxy with the handshake completes. For example, a proxy with limited anti-
limited anti-replay defenses might choose to perform DNS resolution replay defenses might choose to perform DNS resolution of the
of the "target_host" when a request arrives in early data, but delay "target_host" when a request arrives in early data, but delay the TCP
the TCP connection until the TLS handshake completes. 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 [HEv2]
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 ([HTTP], Section 10.1.1) in any HTTP version. The "100 (Continue)"
(Continue)" status code confirms receipt of a request at the proxy status code confirms receipt of a request at the proxy without
without waiting for the proxy-destination TCP handshake to succeed or waiting for the proxy-destination TCP handshake to succeed or fail.
fail. This might be particularly helpful when the destination host Clients MAY send "Expect: 100-continue", and proxies MUST respect it
is not responding, as TCP handshakes can hang for several minutes by returning "100 (Continue)" if the request is not immediately
before failing. Clients MAY send "Expect: 100-continue", and proxies rejected. This allows for a few useful improvements:
MUST respect it by returning "100 (Continue)" if the request is not
immediately rejected. o Clients can provide a clearer status indication while waiting for
the destination host to respond. (TCP handshakes can hang for
several minutes before failing.)
o Clients can apply separate timeouts to the proxying request and
connection establishment.
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
request is permissible. This strategy reduces wasted effort when
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 [RFC9209] in any success or failure
response (i.e., status codes 101, 2XX, 4XX, or 5XX) to support response (i.e., status codes 101, 2XX, 4XX, or 5XX) to support
advanced client behaviors and diagnostics. Clients and proxies MUST advanced client behaviors and diagnostics. Clients and proxies MUST
NOT send trailer fields on "connect-tcp" streams. 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.
The URI template can also be structured to generate high-entropy Template-driven TCP proxies can also be made invisible to probes from
Capability URLs [CAPABILITY], so that only authorized users can unauthorized clients:
discover the proxy service.
o The URI template can include a high-entropy path, similar to
Capability URLs [CAPABILITY].
o The proxy can require HTTP Concealed Authentication ([CONCEALED],
Section 6.4).
5.2. Clients 5.2. Clients
Clients that support both classic HTTP CONNECT proxies and template- Clients for this specification MAY accept various configuration
driven TCP proxies MAY accept both types via a single configuration inputs, including:
string. If the configuration string can be parsed as a URI Template
containing the required variables, it is a template-driven TCP proxy.
Otherwise, it is presumed to represent a classic HTTP CONNECT proxy.
In some cases, it is valuable to allow "connect-tcp" clients to reach o A URI Template string, as described in Section 3.
"connect-tcp"-only proxies when using a legacy configuration method
that cannot convey a URI Template. To support this arrangement, o An IP address or hostname, with optional or required port and
clients SHOULD treat certain errors during classic HTTP CONNECT as scheme (as often used to describe classic HTTP CONNECT proxies).
A corresponding template-driven TCP proxy might be found in two
ways:
* At the default template for "connect-tcp" (Figure 2).
* In the "proxy" dictionary of a provisioning domain resource at
the corresponding .well-known URI
([I-D.ietf-intarea-proxy-config], Section 2).
o The full URI, including path, of a provisioning domain resource
containing one or more "connect-tcp" proxy sub-dictionaries
([I-D.ietf-intarea-proxy-config], Section 3).
https://$PROXY_HOST:$PROXY_PORT/.well-known/masque
/tcp/{target_host}/{target_port}/
Figure 2: Registered default template
All of these input types MAY share a single input string, as they can
be disambiguated reliably by parsing and probing. However, it may be
preferable to indicate the configuration input type explicitly, to
reduce probing delays while supporting clients with differing
capabilities.
Clients SHOULD treat certain errors during classic HTTP CONNECT as
indications that the proxy might only support "connect-tcp": indications that the proxy might only support "connect-tcp":
o In HTTP/1.1: the response status code is "426 (Upgrade Required)", o In HTTP/1.1: the response status code is "426 (Upgrade Required)",
with an "Upgrade: connect-tcp" response header. with an "Upgrade: connect-tcp" response header.
o In any HTTP version: the response status code is "501 (Not o In any HTTP version: the response status code is "501 (Not
Implemented)". Implemented)".
* Requires SETTINGS_ENABLE_CONNECT_PROTOCOL to have been * Requires SETTINGS_ENABLE_CONNECT_PROTOCOL to have been
negotiated in HTTP/2 or HTTP/3. negotiated in HTTP/2 or HTTP/3.
If the client infers that classic HTTP CONNECT is not supported, it If the client infers that classic HTTP CONNECT is not supported, it
SHOULD retry the request using the registered default template for SHOULD retry the request using the registered default template for
"connect-tcp": "connect-tcp" (Figure 2). If this request succeeds, the client
SHOULD record a preference for "connect-tcp" to avoid further retry
https://$PROXY_HOST:$PROXY_PORT/.well-known/masque delays.
/tcp/{target_host}/{target_port}/
Registered default template
If this request succeeds, the client SHOULD record a preference for
"connect-tcp" to avoid further retry 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 [RFC9110], Section 9.3.6) apply authorized use of the proxy (see [HTTP], Section 9.3.6) apply equally
equally to both. to both.
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.
6.1. Resource Exhaustion attacks 6.1. Resource Exhaustion attacks
A malicious client can achieve cause highly asymmetric resource usage A malicious client can achieve cause highly asymmetric resource usage
skipping to change at page 12, line 11 skipping to change at page 14, line 11
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
client. client.
o *Window Bloat*: An attacker can grow the receive window size by o *Window Bloat*: An attacker can grow the receive window size by
simulating a "long, fat network" [RFC7323], then fill the window simulating a "long, fat network" ([RFC7323], Section 1.1), then
(from the sender) and stop acknowledging it (at the receiver). fill the window (from the sender) and stop acknowledging it (at
This leaves the proxy buffering up to 1 GiB of TCP data until some the receiver). This leaves the proxy buffering up to 1 GiB of TCP
timeout, while the attacker does not have to retain a large data until some timeout, while the attacker does not have to
buffer. retain a large buffer.
* Mitigation: Limit the maximum receive window for TCP and HTTP * Mitigation: Limit the maximum receive window for TCP and HTTP
connections, and the size of userspace buffers used for connections, and the size of userspace buffers used for
proxying. Alternatively, monitor the connections' send queues proxying. Alternatively, monitor the connections' send queues
and limit the total buffered data per client. and limit the total buffered data per client.
o *WAIT Abuse*: An attacker can force the proxy into a TIME-WAIT, o *WAIT Abuse*: An attacker can force the proxy into a TIME-WAIT,
CLOSE-WAIT, or FIN-WAIT state until the timer expires, tying up a CLOSE-WAIT, or FIN-WAIT state until the timer expires, tying up a
proxy-to-destination 4-tuple for up to four minutes after the proxy-to-destination 4-tuple for up to four minutes after the
client's connection is closed. client's connection is closed.
* Mitigation: Limit the number of connections for each client to * Mitigations:
each destination, even if those connections are in a waiting
state and the corresponding CONNECT stream is closed.
Alternatively, allocate a large range of IP addresses for TCP
connections (especially in IPv6).
7. Operational Considerations + Enable the PAWS optimization ([RFC7323], Section 5) across
successive connections (e.g., Linux's "tcp_tw_reuse=1"
[SYSCTL]). This makes TIME-WAIT 4-tuples rapidly reusable
if the destination enables TCP Timestamps, which most do.
+ Allocate a large range of IP addresses for TCP connections
(especially in IPv6).
+ Limit the number of connections for each client to each
destination, even if those connections are in a waiting
state and the corresponding CONNECT stream is closed.
+ If necessary, perform an abrupt TCP closure that destroys
the Transmission Control Block. Note that reusing a 4-tuple
in this way can increase the risk of interference between
successive connections.
7. Operational Considerations
7.1. Avoiding HTTP/1.1 7.1. Avoiding HTTP/1.1
While this specification is fully functional under HTTP/1.1, While this specification is fully functional under HTTP/1.1,
performance-sensitive deployments SHOULD use HTTP/2 or HTTP/3 performance-sensitive deployments SHOULD use HTTP/2 or HTTP/3
instead. When using HTTP/1.1: instead. When using HTTP/1.1:
o Each CONNECT request requires a new TCP and TLS connection, o Each CONNECT request requires a new TCP and TLS connection,
imposing a higher cost in setup latency, congestion control imposing a higher cost in setup latency, congestion control
convergence, CPU time, and data transfer. convergence, CPU time, and data transfer.
o The graceful and abrupt closure signals (Section 3.4) are more o The graceful and abrupt closure signals (Section 3.4) are more
likely to be missing or corrupted: likely to be missing or corrupted:
* Some implementations may be unable to emit the recommended * Some implementations may be unable to emit the recommended
abrupt closure signals, due to limitations in their TCP and TLS abrupt closure signals, due to limitations in their TCP and TLS
subsystems. subsystems.
* Faulty implementations may fail to send a TLS closure alert * Faulty implementations may fail to send a TLS closure alert
during graceful shutdown, or fail to report an error when the during graceful shutdown, or fail to report an error when the
expected closure alert is not received. These misbehaviors are expected closure alert is not received. These misbehaviors are
not compliant with [RFC8446], but they are common nonetheless not compliant with [TLS], but they are common nonetheless among
among HTTP/1.1 implementations today. HTTP/1.1 implementations today.
o The number of active connections through each client may be o The number of active connections through each client may be
limited by the number of available TCP client ports, especially limited by the number of available TCP client ports, especially
if: if:
* The client only has one IP address that can be used to reach * The client only has one IP address that can be used to reach
the proxy. the proxy.
* The client is shared between many parties, such as when acting * The client is shared between many parties, such as when acting
as a gateway or concentrator. as a gateway or concentrator.
skipping to change at page 14, line 5 skipping to change at page 16, line 18
* 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]).
7.3. Timeouts
Except when actively sending or receiving data, an endpoint is always
waiting for an event from its peer or its TCP connection. HTTP and
TCP are designed to ensure that such an event always arrives, so the
connection is never permanently stuck in any state until it is fully
closed. However, for efficient operation, it may be necessary to
adjust the settings for TCP keep-alives ([TCP], Section 3.8.4), QUIC
idle timeouts ([QUIC], Section 10.1), HTTP/2 PING frames ([RFC9113],
Section 6.7), and other transport options.
Endpoints MAY impose additional timeouts, especially as a defense
against certain resource exhaustion attacks (Section 6.1). However,
operators should apply timeouts cautiously to minimize the impact on
connections that are functioning but slow. Any timeout imposed by
the endpoint MUST be treated as an abrupt closure of the affected
stream or connection (Section 3.4).
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) |
skipping to change at page 14, line 41 skipping to change at page 17, line 32
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 | | Valu | Capsule | Status | Reference | Change | Contact |
| e | Type | | | Controller | | | e | Type | | | Controller | |
+------+------------+-----------+------------+------------+---------+ +------+------------+-----------+------------+------------+---------+
| (TBD | DATA | permanent | (This | IETF | HTTPBIS | | 0x08 | DATA | permanent | (This | IETF | HTTPBIS |
| ) | | | document), | | | | | | | document), | | |
| | | | Section 3 | | | | | | | Section 3 | | |
| | | | | | | | | | | | | |
| (TBD | FINAL_DATA | permanent | (This | IETF | HTTPBIS | | 0x09 | FINAL_DATA | permanent | (This | IETF | HTTPBIS |
| ) | | | document), | | | | | | | document), | | |
| | | | Section 3 | | | | | | | Section 3 | | |
+------+------------+-----------+------------+------------+---------+ +------+------------+-----------+------------+------------+---------+
For this draft version of the protocol, the Capsule Type values
"0x2028d7f0" and "0x2028d7f1" shall be used provisionally for
testing, under the names "DATA-08" and "FINAL_DATA-08".
9. References 9. References
9.1. Normative References 9.1. Normative References
[CAPSULE] 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>.
[CONNECT-UDP]
Schinazi, D., "Proxying UDP in HTTP", RFC 9298,
DOI 10.17487/RFC9298, August 2022,
<https://www.rfc-editor.org/info/rfc9298>.
[HTTP] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "HTTP Semantics", STD 97, RFC 9110,
DOI 10.17487/RFC9110, June 2022,
<https://www.rfc-editor.org/info/rfc9110>.
[QUIC] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
Multiplexed and Secure Transport", RFC 9000,
DOI 10.17487/RFC9000, May 2021,
<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>.
[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", [RFC8441] McManus, P., "Bootstrapping WebSockets with HTTP/2",
RFC 8441, DOI 10.17487/RFC8441, September 2018, RFC 8441, DOI 10.17487/RFC8441, September 2018,
<https://www.rfc-editor.org/info/rfc8441>. <https://www.rfc-editor.org/info/rfc8441>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<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 [RFC9112] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Multiplexed and Secure Transport", RFC 9000, Ed., "HTTP/1.1", STD 99, RFC 9112, DOI 10.17487/RFC9112,
DOI 10.17487/RFC9000, May 2021, June 2022, <https://www.rfc-editor.org/info/rfc9112>.
<https://www.rfc-editor.org/info/rfc9000>.
[RFC9110] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "HTTP Semantics", STD 97, RFC 9110,
DOI 10.17487/RFC9110, June 2022,
<https://www.rfc-editor.org/info/rfc9110>.
[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 [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 [TLS] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Capsule Protocol", RFC 9297, DOI 10.17487/RFC9297, August Version 1.3", RFC 9846, DOI 10.17487/RFC9846, July 2026,
2022, <https://www.rfc-editor.org/info/rfc9297>. <https://www.rfc-editor.org/info/rfc9846>.
[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
[ALT-SVC] Nottingham, M., McManus, P., and J. Reschke, "HTTP
Alternative Services", RFC 7838, DOI 10.17487/RFC7838,
April 2016, <https://www.rfc-editor.org/info/rfc7838>.
[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/>.
[CONCEALED]
Schinazi, D., Oliver, D., and J. Hoyland, "The Concealed
HTTP Authentication Scheme", RFC 9729,
DOI 10.17487/RFC9729, February 2025,
<https://www.rfc-editor.org/info/rfc9729>.
[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] [HEv2] Schinazi, D. and T. Pauly, "Happy Eyeballs Version 2:
Schinazi, D., "Proxying UDP in HTTP", RFC 9298, Better Connectivity Using Concurrency", RFC 8305,
DOI 10.17487/RFC9298, August 2022, DOI 10.17487/RFC8305, December 2017,
<https://www.rfc-editor.org/info/rfc9298>. <https://www.rfc-editor.org/info/rfc8305>.
[I-D.schinazi-httpbis-wrap-up] [HSTS] Hodges, J., Jackson, C., and A. Barth, "HTTP Strict
Transport Security (HSTS)", RFC 6797,
DOI 10.17487/RFC6797, November 2012,
<https://www.rfc-editor.org/info/rfc6797>.
[I-D.ietf-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.
[I-D.ietf-intarea-proxy-config]
Pauly, T., Damjanovic, D., and Y. Rosomakho,
"Communicating Proxy Configurations in Provisioning
Domains", draft-ietf-intarea-proxy-config-14 (work in
progress), May 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>.
[RFC6797] Hodges, J., Jackson, C., and A. Barth, "HTTP Strict
Transport Security (HSTS)", RFC 6797,
DOI 10.17487/RFC6797, November 2012,
<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
Alternative Services", RFC 7838, DOI 10.17487/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>.
[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>.
[SYSCTL] "IP Sysctl -- The Linux Kernel documentation", June 2026,
<https://www.kernel.org/doc/html/v7.1/networking/ip-
sysctl.html>.
[TCP] Eddy, W., Ed., "Transmission Control Protocol (TCP)",
STD 7, RFC 9293, DOI 10.17487/RFC9293, August 2022,
<https://www.rfc-editor.org/info/rfc9293>.
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. 57 change blocks. 
176 lines changed or deleted 328 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/