티스토리 수익 글 보기
Template-Driven HTTP CONNECT Proxying for TCP
draft-ietf-httpbis-connect-tcp-13
| Document | Type | Active Internet-Draft (httpbis WG) | |
|---|---|---|---|
| Author | Benjamin M. Schwartz | ||
| Last updated | 2026-08-17 | ||
| Replaces | draft-schwartz-httpbis-connect-tcp | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Intended RFC status | Proposed Standard | ||
| Formats | |||
| Additional resources | Mailing list discussion | ||
| Stream | WG state | Submitted to IESG for Publication | |
| Document shepherd | Tommy Pauly | ||
| Shepherd write-up | Show Last changed 2026-08-17 | ||
| IESG | IESG state | Publication Requested | |
| Action Holder | |||
| Consensus boilerplate | Yes | ||
| Telechat date | (None) | ||
| Responsible AD | Mike Bishop | ||
| Send notices to | tpauly@apple.com |
draft-ietf-httpbis-connect-tcp-13
httpbis B. M. Schwartz
Internet-Draft Meta Platforms, Inc.
Intended status: Standards Track 17 August 2026
Expires: 18 February 2027
Template-Driven HTTP CONNECT Proxying for TCP
draft-ietf-httpbis-connect-tcp-13
Abstract
TCP proxying using HTTP CONNECT has long been part of the core HTTP
specification. However, this proxying functionality has several
important deficiencies in modern HTTP environments. This
specification defines an alternative HTTP proxy service configuration
for TCP connections. This configuration is described by a URI
Template, similar to the CONNECT-UDP and CONNECT-IP protocols.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 18 February 2027.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Schwartz Expires 18 February 2027 [Page 1]
Internet-Draft Templated CONNECT-TCP August 2026
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. History . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2. Problems . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3. Overview . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions and Definitions . . . . . . . . . . . . . . . . . 3
3. Specification . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. In HTTP/1.1 . . . . . . . . . . . . . . . . . . . . . . . 5
3.2. In HTTP/2 and HTTP/3 . . . . . . . . . . . . . . . . . . 6
3.3. Use of Other Relevant Headers . . . . . . . . . . . . . . 7
3.3.1. Origin-scoped Headers . . . . . . . . . . . . . . . . 7
3.3.2. Authentication Headers . . . . . . . . . . . . . . . 8
3.4. Closing Connections . . . . . . . . . . . . . . . . . . . 8
3.4.1. Handling Invalid Data . . . . . . . . . . . . . . . . 10
4. Additional Connection Setup Behaviors . . . . . . . . . . . . 10
4.1. Latency optimizations . . . . . . . . . . . . . . . . . . 10
4.2. Conveying metadata . . . . . . . . . . . . . . . . . . . 11
5. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 12
5.1. Servers . . . . . . . . . . . . . . . . . . . . . . . . . 12
5.2. Clients . . . . . . . . . . . . . . . . . . . . . . . . . 12
6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
6.1. Resource Exhaustion attacks . . . . . . . . . . . . . . . 13
7. Operational Considerations . . . . . . . . . . . . . . . . . 15
7.1. Avoiding HTTP/1.1 . . . . . . . . . . . . . . . . . . . . 15
7.2. Gateway Compatibility . . . . . . . . . . . . . . . . . . 15
7.3. Timeouts . . . . . . . . . . . . . . . . . . . . . . . . 16
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
8.1. New Upgrade Token . . . . . . . . . . . . . . . . . . . . 16
8.1.1. Interop testing . . . . . . . . . . . . . . . . . . . 17
8.2. New MASQUE Default Template . . . . . . . . . . . . . . . 17
8.3. New Capsule Type . . . . . . . . . . . . . . . . . . . . 17
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
9.1. Normative References . . . . . . . . . . . . . . . . . . 18
9.2. Informative References . . . . . . . . . . . . . . . . . 19
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 21
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 21
1. Introduction
1.1. History
HTTP has used the CONNECT method for proxying TCP connections since
HTTP/1.1. When using CONNECT, the request target specifies a host
and port number, and the proxy forwards TCP payloads between the
client and this destination ([HTTP], Section 9.3.6). To date, this
is the only mechanism defined for proxying TCP over HTTP. In this
specification, this is referred to as a "classic HTTP CONNECT proxy".
Schwartz Expires 18 February 2027 [Page 2]
Internet-Draft Templated CONNECT-TCP August 2026
HTTP/3 uses a UDP transport, so it cannot be forwarded using the pre-
existing CONNECT mechanism. To enable forward proxying of HTTP/3,
the MASQUE effort has defined proxy mechanisms that are capable of
proxying UDP datagrams [CONNECT-UDP], and more generally IP datagrams
[CONNECT-IP]. The destination host and port number (if applicable)
are encoded into the HTTP resource path, and end-to-end datagrams are
wrapped into HTTP Datagrams [CAPSULE] on the client-proxy path.
1.2. Problems
HTTP clients can be configured to use proxies by selecting a proxy
hostname, a port, and whether to use a security protocol. However,
Classic HTTP CONNECT requests using the proxy do not carry this
configuration information. Instead, they only indicate the hostname
and port of the target. This prevents any HTTP server from hosting
multiple distinct proxy services, as the server cannot distinguish
them by path (as with distinct resources) or by origin (as in
"virtual hosting").
The absence of an explicit origin for the proxy also rules out the
usual defenses against server port misdirection attacks (see
Section 7.4 of [HTTP]) and creates ambiguity about the use of origin-
scoped response header fields (e.g., "Alt-Svc" [ALT-SVC], "Strict-
Transport-Security" [HSTS]).
Classic HTTP CONNECT requests are not extensible to carry in-stream
metadata. For example, the WRAP_UP capsule
[I-D.ietf-httpbis-wrap-up] cannot be used with Classic HTTP CONNECT.
1.3. Overview
This specification describes an alternative mechanism for proxying
TCP in HTTP. Like [CONNECT-UDP] and [CONNECT-IP], the proxy service
is identified by a URI Template. Proxy interactions reuse standard
HTTP components and semantics, avoiding changes to the core HTTP
protocol.
2. Conventions and Definitions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
Schwartz Expires 18 February 2027 [Page 3]
Internet-Draft Templated CONNECT-TCP August 2026
3. Specification
A template-driven TCP transport proxy for HTTP is identified by a URI
Template [RFC6570] containing variables named "target_host" and
"target_port". This URI Template and its variable values MUST meet
all the same requirements as for UDP proxying ([CONNECT-UDP],
Section 2), and are subject to the same validation rules. The client
MUST substitute the destination host and port number into this
template to produce the request URI. The derived URI serves as the
destination of a Capsule Protocol connection using the Upgrade Token
"connect-tcp" (see registration in Section 8.1).
When using "connect-tcp", TCP payload data is sent in the payload of
new Capsule Types named DATA and FINAL_DATA (see Figure 1 and
registrations in Section 8.3). The ordered concatenation of these
capsule payloads, which MAY be empty, represents the TCP payload
data. A FINAL_DATA capsule additionally indicates that the sender
has closed this stream, semantically equivalent to TCP FIN. After
sending a FINAL_DATA capsule, an endpoint MUST NOT send any more DATA
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
capsules, subject to the following requirements:
* There are no intervening capsules of other types.
* The order of payload content is preserved.
Schwartz Expires 18 February 2027 [Page 4]
Internet-Draft Templated CONNECT-TCP August 2026
* The final emitted capsule uses the same capsule type (DATA or
FINAL_DATA) as the final input capsule, and all others use the
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
In HTTP/1.1 [HTTP/1.1], the client uses the proxy by issuing a
request as follows:
* The method SHALL be "GET".
* The request's target SHALL correspond to the URI derived from
expansion of the proxy's URI Template.
* The request SHALL include a single "Host" header field containing
the origin of the proxy.
* The request SHALL include a "Connection" header field with the
value "Upgrade". (Note that this requirement is case-insensitive
as per Section 7.6.1 of [HTTP].)
* The request SHALL include an "Upgrade" header field with the value
"connect-tcp".
* The request SHOULD include a "Capsule-Protocol: ?1" header (as
recommended in [CAPSULE], Section 3.4).
If the request is well-formed and permissible, the proxy MUST attempt
to establish the TCP connection before sending any response status
code other than "100 (Continue)" (see Section 4.2). If the TCP
connection is successful, the response SHALL be as follows:
* The HTTP status code SHALL be "101 (Switching Protocols)".
* The response SHALL include a "Connection" header field with the
value "Upgrade".
Schwartz Expires 18 February 2027 [Page 5]
Internet-Draft Templated CONNECT-TCP August 2026
* The response SHALL include a single "Upgrade" header field with
the value "connect-tcp".
* The response SHOULD include a "Capsule-Protocol: ?1" header (as
above).
If the request is malformed or impermissible, the proxy MUST return a
4XX error code. If a TCP connection was not established, the proxy
MUST NOT switch protocols to "connect-tcp", and the client MAY reuse
this connection for additional HTTP requests.
Client Proxy
GET /proxy?target_host=192.0.2.1&target_port=443 HTTP/1.1
Host: example.com
Connection: Upgrade
Upgrade: connect-tcp
Capsule-Protocol: ?1
** Proxy establishes a TCP connection to 192.0.2.1:443 **
HTTP/1.1 101 Switching Protocols
Connection: Upgrade
Upgrade: connect-tcp
Capsule-Protocol: ?1
Figure 2: Templated TCP proxy example in HTTP/1.1
3.2. In HTTP/2 and HTTP/3
In HTTP/2 and HTTP/3, the proxy MUST include
SETTINGS_ENABLE_CONNECT_PROTOCOL in its SETTINGS frame
[RFC8441][RFC9220]. The client uses the proxy by issuing an
"extended CONNECT" request as follows:
* The :method pseudo-header field SHALL be "CONNECT".
* The :protocol pseudo-header field SHALL be "connect-tcp".
* The :authority pseudo-header field SHALL contain the authority of
the proxy.
* The :path and :scheme pseudo-header fields SHALL contain the path
and scheme of the request URI derived from the proxy's URI
Template.
Schwartz Expires 18 February 2027 [Page 6]
Internet-Draft Templated CONNECT-TCP August 2026
A templated TCP proxying request that does not conform to all of
these requirements represents a client error (see [HTTP],
Section 15.5) and may be malformed (see Section 8.1.1 of [HTTP/2] and
Section 4.1.2 of [HTTP/3]).
Additionally the "capsule-protocol" header field SHOULD be present
with a value of "?1" (as recommended in [CAPSULE], Section 3.4).
HEADERS
:method = CONNECT
:scheme = https
:authority = request-proxy.example
:path = /proxy?target_host=2001%3Adb8%3A%3A1&target_port=443
:protocol = connect-tcp
capsule-protocol = ?1
...
Figure 3: Templated TCP proxy example in HTTP/2
3.3. Use of Other Relevant Headers
3.3.1. Origin-scoped Headers
Ordinary HTTP headers apply only to the single resource identified in
the request or response. An origin-scoped HTTP header is a special
response header that is intended to change the client's behavior for
subsequent requests to any resource on this origin.
Unlike classic HTTP CONNECT proxies, a templated TCP proxy has an
unambiguous origin of its own. Origin-scoped headers apply to this
origin when they are associated with a templated TCP proxy response.
Here are some origin-scoped headers that could potentially be sent by
a templated TCP proxy:
* "Alt-Svc" [ALT-SVC]
* "Strict-Transport-Security" [HSTS]
* "Accept-CH" [RFC8942]
* "Set-Cookie" [RFC6265], which has configurable scope.
* "Clear-Site-Data" [CLEAR-SITE-DATA]
Schwartz Expires 18 February 2027 [Page 7]
Internet-Draft Templated CONNECT-TCP August 2026
3.3.2. Authentication Headers
Authentication to a templated TCP proxy normally uses ordinary HTTP
authentication via the "401 (Unauthorized)" response code, the "WWW-
Authenticate" response header field, and the "Authorization" request
header field ([HTTP], Section 11.6). A templated TCP proxy does not
use the "407 (Proxy Authentication Required)" response code and
related header fields ([HTTP], Section 11.7) because they do not
traverse HTTP gateways (see Section 7.2).
Clients SHOULD assume that all proxy resources generated by a single
template share a protection space (i.e., a realm) ([HTTP],
Section 11.5). For many authentication schemes, this will allow the
client to avoid waiting for a "401 (Unauthorized)" response before
each new connection through the proxy.
TLS Client Certificate authentication can also be used (see
Section 7.2).
3.4. Closing Connections
Connection termination is essentially symmetrical for proxies and
their clients. In this section, we use the term "endpoint" to
describe an implementation of this specification in either role.
When closing connections, endpoints are subject to the following
requirements:
* When an endpoint receives a valid TCP FIN, it MUST send a
FINAL_DATA capsule.
* When an endpoint receives a valid FINAL_DATA capsule, it MUST send
a TCP FIN.
* When a TCP connection reaches the TIME-WAIT or CLOSED state, the
associated endpoint MUST close its send stream.
- If the connection closed gracefully, the endpoint MUST close
the send stream gracefully.
- Otherwise, the endpoint SHOULD close the send stream abruptly,
using a mechanism appropriate to the HTTP version:
o HTTP/3: reset the stream with H3_CONNECT_ERROR; see [QUIC],
Section 19.4 and [HTTP/3], Section 8.1
o HTTP/2: reset the stream with CONNECT_ERROR; see [HTTP/2],
Sections 6.4 and 7
Schwartz Expires 18 February 2027 [Page 8]
Internet-Draft Templated CONNECT-TCP August 2026
o HTTP/1.1 over TLS: TCP shutdown without a TLS closure alert;
see [TLS], Section 6.1.
o HTTP/1.1 without TLS: TCP RST
* When the receive stream is closed abruptly or without a FINAL_DATA
capsule received, the endpoint SHOULD send a TCP RST if the TCP
subsystem permits it.
The mandatory behaviors above enable endpoints to detect any
truncation of incoming TCP data. The recommended behaviors propagate
any TCP errors through the proxy connection.
+-------+ +------------+ +------------+ +-------+
| TCP A | | Endpoint A | | Endpoint B | | TCP B |
+-+-----+ +-+----------+ +----------+-+ +-----+-+
+---"abc"--->+-------DATA{"abc"}------->+---"abc"--->|
+----FIN---->+------FINAL_DATA{""}----->+----FIN---->|
|<---FIN-----+<-----FINAL_DATA{""}------+<---FIN-----+
| |<----QUIC.STREAM{FIN}-----+ |
+---FINACK-->+-----QUIC.STREAM{FIN}---->| |
| | | |
Figure 4: Simple graceful termination example (HTTP/3)
+-------+ +------------+ +------------+ +-------+
| TCP A | | Endpoint A | | Endpoint B | | TCP B |
+-+-----+ +-+----------+ +----------+-+ +-----+-+
+----RST---->+---RST_STREAM{CON_ERR}--->+----RST---->|
| | | |
Figure 5: Simple TCP RST termination example (HTTP/2)
+-------+ +------------+ +------------+ +-------+
| TCP A | | Endpoint A | | Endpoint B | | TCP B |
+-+-----+ +-+----------+ +----------+-+ +-----+-+
+---"abc"--->+-------DATA{"abc"}------->+---"abc"--->|
| | (... timeout @ A ...) | |
| +--FIN (no close_notify)-->+----RST---->|
| | | |
Figure 6: Timeout example (HTTP/1.1)
Schwartz Expires 18 February 2027 [Page 9]
Internet-Draft Templated CONNECT-TCP August 2026
+-------+ +------------+ +------------+ +-------+
| TCP A | | Endpoint A | | Endpoint B | | TCP B |
+-+-----+ +-+----------+ +----------+-+ +-----+-+
+-----FIN--->+-------FINAL_DATA{""}---->+-----FIN--->|
| | | |
| (FIN) | | (FIN) |
|<---"abc"---+<----FINAL_DATA{"abc"}----+<---"abc"---+
| |<----QUIC.STREAM{FIN}-----+ |
+-----RST--->+-----H3_CONNECT_ERROR---->+-----RST--->|
| | | |
Figure 7: 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:
* A second FINAL_DATA capsule.
* A DATA capsule after FINAL_DATA.
* Data that results in a parsing error under the Capsule Protocol.
* A capsule that is truncated by the end of the stream.
* 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
This section discusses some behaviors that are permitted or
recommended in order to enhance the performance or functionality of
connection setup.
4.1. Latency optimizations
When using this specification in HTTP/2 or HTTP/3, clients MAY start
sending TCP stream content optimistically, subject to flow control
limits (Section 5.2 of [HTTP/2] or Section 4.1 of [QUIC]). Proxies
MUST buffer this "optimistic" content until the TCP stream becomes
writable, and discard it if the TCP connection fails. (Clients MUST
NOT use "optimistic" behavior in HTTP/1.1, as this would interfere
with reuse of the connection after an error response such as "401
Schwartz Expires 18 February 2027 [Page 10]
Internet-Draft Templated CONNECT-TCP August 2026
(Unauthorized)".)
Servers that host a proxy under this specification MAY offer support
for TLS early data in accordance with [RFC8470]. Clients MAY send
"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,
proxies MAY ignore, reject, or accept the early_data extension
([TLS], Section 4.2.10). At the HTTP layer, proxies MAY process the
request immediately, return a "425 (Too Early)" response ([RFC8470],
Section 5.2), or delay some or all processing of the request until
the handshake completes. For example, a proxy with limited anti-
replay defenses might choose to perform DNS resolution of the
target_host when a request arrives in early data, but delay 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 [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
This specification supports the "Expect: 100-continue" request header
([HTTP], Section 10.1.1) in any HTTP version. The "100 (Continue)"
status code confirms receipt of a request at the proxy without
waiting for the proxy-destination TCP handshake to succeed or fail.
Clients MAY send "Expect: 100-continue", and proxies MUST respect it
by returning "100 (Continue)" if the request is not immediately
rejected. This allows for a few useful improvements:
* Clients can provide a clearer status indication while waiting for
the destination host to respond. (TCP handshakes can hang for
several minutes before failing.)
* Clients can apply separate timeouts to the proxying request and
connection establishment.
* 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.
Schwartz Expires 18 February 2027 [Page 11]
Internet-Draft Templated CONNECT-TCP August 2026
Proxies implementing this specification SHOULD include a "Proxy-
Status" response header field [RFC9209] in any success or failure
response (i.e., status codes 101, 2XX, 4XX, or 5XX) to support
advanced client behaviors and diagnostics. Clients and proxies MUST
NOT send trailer fields on "connect-tcp" streams.
5. Applicability
5.1. Servers
For server operators, template-driven TCP proxies are particularly
valuable in situations where virtual-hosting is needed, or where
multiple proxies must share an origin. For example, the proxy might
benefit from sharing an HTTP gateway that provides DDoS defense,
performs request sanitization, or enforces user authorization.
Template-driven TCP proxies can also be made invisible to probes from
unauthorized clients:
* The URI template can include a high-entropy path, similar to
Capability URLs [CAPABILITY].
* The proxy can require HTTP Concealed Authentication ([CONCEALED],
Section 6.4).
5.2. Clients
Clients for this specification MAY accept various configuration
inputs, including:
* A URI Template string, as described in Section 3.
* An IP address or hostname, with optional or required port and
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 8).
- In the "proxy" dictionary of a provisioning domain resource at
the corresponding .well-known URI
([I-D.ietf-intarea-proxy-config], Section 2).
* 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).
Schwartz Expires 18 February 2027 [Page 12]
Internet-Draft Templated CONNECT-TCP August 2026
https://$PROXY_HOST:$PROXY_PORT/.well-known/masque
/tcp/{target_host}/{target_port}/
Figure 8: 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":
* In HTTP/1.1: the response status code is "426 (Upgrade Required)",
with an "Upgrade: connect-tcp" response header.
* In any HTTP version: the response status code is "501 (Not
Implemented)".
- Requires SETTINGS_ENABLE_CONNECT_PROTOCOL to have been
negotiated in HTTP/2 or HTTP/3.
If the client infers that classic HTTP CONNECT is not supported, it
SHOULD retry the request using the registered default template for
"connect-tcp" (Figure 8). If this request succeeds, the client
SHOULD record a preference for "connect-tcp" to avoid further retry
delays.
6. Security Considerations
Template-driven TCP proxying is largely subject to the same security
risks as classic HTTP CONNECT. For example, any restrictions on
authorized use of the proxy (see [HTTP], Section 9.3.6) apply equally
to both.
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
exploit any vulnerabilities in the parser implementation. Client
implementers should apply their usual precautions for code that
processes untrusted inputs.
6.1. Resource Exhaustion attacks
A malicious client can achieve cause highly asymmetric resource usage
at the proxy by colluding with a destination server and violating the
ordinary rules of TCP or HTTP. Some example attacks, and mitigations
that proxies can apply:
Schwartz Expires 18 February 2027 [Page 13]
Internet-Draft Templated CONNECT-TCP August 2026
* *Connection Pileup*: A malicious client can attempt to open a
large number of connections to exhaust the proxy's memory, port,
or file descriptor limits. When using HTTP/2 or HTTP/3, each
incremental TCP connection imposes a much higher cost on the proxy
than on the attacker.
- Mitigation: Limit the number of concurrent connections per
client.
* *Window Bloat*: An attacker can grow the receive window size by
simulating a "long, fat network" ([RFC7323], Section 1.1), then
fill the window (from the sender) and stop acknowledging it (at
the receiver). This leaves the proxy buffering up to 1 GiB of TCP
data until some timeout, while the attacker does not have to
retain a large buffer.
- Mitigation: Limit the maximum receive window for TCP and HTTP
connections, and the size of userspace buffers used for
proxying. Alternatively, monitor the connections' send queues
and limit the total buffered data per client.
* *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
proxy-to-destination 4-tuple for up to four minutes after the
client's connection is closed.
- Mitigations:
o 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.
o Allocate a large range of IP addresses for TCP connections
(especially in IPv6).
o 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.
o 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.
Schwartz Expires 18 February 2027 [Page 14]
Internet-Draft Templated CONNECT-TCP August 2026
7. Operational Considerations
7.1. Avoiding HTTP/1.1
While this specification is fully functional under HTTP/1.1,
performance-sensitive deployments SHOULD use HTTP/2 or HTTP/3
instead. When using HTTP/1.1:
* Each CONNECT request requires a new TCP and TLS connection,
imposing a higher cost in setup latency, congestion control
convergence, CPU time, and data transfer.
* The graceful and abrupt closure signals (Section 3.4) are more
likely to be missing or corrupted:
- Some implementations may be unable to emit the recommended
abrupt closure signals, due to limitations in their TCP and TLS
subsystems.
- Faulty implementations may fail to send a TLS closure alert
during graceful shutdown, or fail to report an error when the
expected closure alert is not received. These misbehaviors are
not compliant with [TLS], but they are common nonetheless among
HTTP/1.1 implementations today.
* The number of active connections through each client may be
limited by the number of available TCP client ports, especially
if:
- The client only has one IP address that can be used to reach
the proxy.
- The client is shared between many parties, such as when acting
as a gateway or concentrator.
- The proxied connections are often closed by the destination.
This causes the client to initiate closure of the client-to-
proxy connection, leaving the client in a TIME-WAIT state for
up to four minutes.
7.2. Gateway Compatibility
Templated TCP proxies can make use of standard HTTP gateways and
path-routing to ease implementation and allow use of shared
infrastructure. However, current gateways might need modifications
to support TCP proxy services. To be compatible, a gateway must:
Schwartz Expires 18 February 2027 [Page 15]
Internet-Draft Templated CONNECT-TCP August 2026
* support Extended CONNECT (if acting as an HTTP/2 or HTTP/3
server).
* support HTTP/1.1 Upgrade to "connect-tcp" (if acting as an
HTTP/1.1 server)
- only after forwarding the upgrade request to the origin and
observing a success response.
* forward the "connect-tcp" protocol to the origin.
* convert "connect-tcp" requests between all supported HTTP server
and client versions.
* 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 ([HTTP/2],
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.1. New Upgrade Token
IF APPROVED, IANA is requested to add the following entry to the HTTP
Upgrade Token Registry:
Schwartz Expires 18 February 2027 [Page 16]
Internet-Draft Templated CONNECT-TCP August 2026
+===============+==========================+=================+
| Value | Description | Reference |
+===============+==========================+=================+
| "connect-tcp" | Proxying of TCP payloads | (This document) |
+---------------+--------------------------+-----------------+
Table 1
8.1.1. Interop testing
This section is to be removed before publishing as an RFC.
For interoperability testing of this draft version, implementations
SHALL use the value "connect-tcp-12".
8.2. New MASQUE Default Template
IF APPROVED, IANA is requested to add the following entry to the
"MASQUE URI Suffixes" registry:
+==============+==============+=================+
| Path Segment | Description | Reference |
+==============+==============+=================+
| tcp | TCP Proxying | (This document) |
+--------------+--------------+-----------------+
Table 2
8.3. New Capsule Type
IF APPROVED, IANA is requested to add the following entry to the
"HTTP Capsule Types" registry:
+=====+============+===========+============+============+=========+
|Value| Capsule | Status | Reference | Change | Contact |
| | Type | | | Controller | |
+=====+============+===========+============+============+=========+
|0x08 | DATA | permanent | (This | IETF | HTTPBIS |
| | | | document), | | |
| | | | Section 3 | | |
+-----+------------+-----------+------------+------------+---------+
|0x09 | FINAL_DATA | permanent | (This | IETF | HTTPBIS |
| | | | document), | | |
| | | | Section 3 | | |
+-----+------------+-----------+------------+------------+---------+
Table 3
Schwartz Expires 18 February 2027 [Page 17]
Internet-Draft Templated CONNECT-TCP August 2026
9. 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/rfc/rfc9297>.
[CONNECT-UDP]
Schinazi, D., "Proxying UDP in HTTP", RFC 9298,
DOI 10.17487/RFC9298, August 2022,
<https://www.rfc-editor.org/rfc/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/rfc/rfc9110>.
[HTTP/1.1] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "HTTP/1.1", STD 99, RFC 9112, DOI 10.17487/RFC9112,
June 2022, <https://www.rfc-editor.org/rfc/rfc9112>.
[HTTP/2] Thomson, M., Ed. and C. Benfield, Ed., "HTTP/2", RFC 9113,
DOI 10.17487/RFC9113, June 2022,
<https://www.rfc-editor.org/rfc/rfc9113>.
[HTTP/3] Bishop, M., Ed., "HTTP/3", RFC 9114, DOI 10.17487/RFC9114,
June 2022, <https://www.rfc-editor.org/rfc/rfc9114>.
[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/rfc/rfc9000>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC6570] Gregorio, J., Fielding, R., Hadley, M., Nottingham, M.,
and D. Orchard, "URI Template", RFC 6570,
DOI 10.17487/RFC6570, March 2012,
<https://www.rfc-editor.org/rfc/rfc6570>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
Schwartz Expires 18 February 2027 [Page 18]
Internet-Draft Templated CONNECT-TCP August 2026
[RFC8441] McManus, P., "Bootstrapping WebSockets with HTTP/2",
RFC 8441, DOI 10.17487/RFC8441, September 2018,
<https://www.rfc-editor.org/rfc/rfc8441>.
[RFC8470] Thomson, M., Nottingham, M., and W. Tarreau, "Using Early
Data in HTTP", RFC 8470, DOI 10.17487/RFC8470, September
2018, <https://www.rfc-editor.org/rfc/rfc8470>.
[RFC9209] Nottingham, M. and P. Sikora, "The Proxy-Status HTTP
Response Header Field", RFC 9209, DOI 10.17487/RFC9209,
June 2022, <https://www.rfc-editor.org/rfc/rfc9209>.
[RFC9220] Hamilton, R., "Bootstrapping WebSockets with HTTP/3",
RFC 9220, DOI 10.17487/RFC9220, June 2022,
<https://www.rfc-editor.org/rfc/rfc9220>.
[TLS] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 9846, DOI 10.17487/RFC9846, July 2026,
<https://www.rfc-editor.org/rfc/rfc9846>.
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/rfc/rfc7838>.
[CAPABILITY]
"Good Practices for Capability URLs", February 2014,
<https://www.w3.org/TR/capability-urls/>.
[CLEAR-SITE-DATA]
"Clear Site Data", November 2017,
<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/rfc/rfc9729>.
[CONNECT-IP]
Pauly, T., Ed., Schinazi, D., Chernyakhovsky, A.,
Kühlewind, M., and M. Westerlund, "Proxying IP in HTTP",
RFC 9484, DOI 10.17487/RFC9484, October 2023,
<https://www.rfc-editor.org/rfc/rfc9484>.
Schwartz Expires 18 February 2027 [Page 19]
Internet-Draft Templated CONNECT-TCP August 2026
[HEv2] 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/rfc/rfc8305>.
[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/rfc/rfc6797>.
[I-D.ietf-httpbis-wrap-up]
Schinazi, D. and L. Pardue, "The HTTP Wrap Up Capsule",
Work in Progress, Internet-Draft, draft-ietf-httpbis-wrap-
up-01, 7 July 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-
wrap-up-01>.
[I-D.ietf-intarea-proxy-config]
Pauly, T., Damjanovic, D., and Y. Rosomakho,
"Communicating Proxy Configurations in Provisioning
Domains", Work in Progress, Internet-Draft, draft-ietf-
intarea-proxy-config-14, 19 May 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-intarea-
proxy-config-14>.
[RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265,
DOI 10.17487/RFC6265, April 2011,
<https://www.rfc-editor.org/rfc/rfc6265>.
[RFC7323] Borman, D., Braden, B., Jacobson, V., and R.
Scheffenegger, Ed., "TCP Extensions for High Performance",
RFC 7323, DOI 10.17487/RFC7323, September 2014,
<https://www.rfc-editor.org/rfc/rfc7323>.
[RFC8942] Grigorik, I. and Y. Weiss, "HTTP Client Hints", RFC 8942,
DOI 10.17487/RFC8942, February 2021,
<https://www.rfc-editor.org/rfc/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/rfc/rfc9440>.
[SYSCTL] "IP Sysctl -- The Linux Kernel documentation", June 2026,
<https://www.kernel.org/doc/html/v7.1/networking/ip-
sysctl.html>.
Schwartz Expires 18 February 2027 [Page 20]
Internet-Draft Templated CONNECT-TCP August 2026
[TCP] Eddy, W., Ed., "Transmission Control Protocol (TCP)",
STD 7, RFC 9293, DOI 10.17487/RFC9293, August 2022,
<https://www.rfc-editor.org/rfc/rfc9293>.
Acknowledgments
Thanks to Amos Jeffries, Tommy Pauly, Kyle Nekritz, David Schinazi,
and Kazuho Oku for close review and suggested changes.
Author's Address
Benjamin M. Schwartz
Meta Platforms, Inc.
Email: ietf@bemasc.net
Schwartz Expires 18 February 2027 [Page 21]