Summary

  • draft-ietf-httpbis-connect-tcp-14 makes a URI Template containing target_host and target_port the configured entry point for TCP proxy requests, giving the proxy a distinct HTTP origin and resource path.
  • The design uses ordinary HTTP authentication and gateway policy, then carries TCP bytes in ordered DATA and FINAL_DATA capsules; a template, credential decision and tunnel result are separate receipts.
  • The document is in IETF Last Call until 1 October 2026. It is an active Internet-Draft, not an approved RFC or evidence of implementation, deployment or end-to-end outcome.

The address now names the gate

A client wants a TCP connection to a service. Under classic CONNECT, the request target is essentially the destination host and port. Revision 14 of the CONNECT-TCP draft inserts a more explicit gate in front of that destination. The client is configured with a URI Template, substitutes target_host and target_port, and sends the resulting request to a proxy origin.

That change looks syntactic until authority is traced through it. The template determines which origin receives the request, which path a gateway routes, which protection space supplies credentials, and where origin-scoped state such as HSTS, Alt-Svc or cookies can attach. A string capable of selecting all those controls is not merely a formatting convenience. Its source and permitted variable space are part of the authorization surface.

The draft borrows the validation contract used by CONNECT-UDP. The template must be absolute, contain non-empty scheme, authority and path components, keep variables in the path or query, contain both target variables and avoid several risky expansion forms. The client must reject a detected invalid configuration before sending the request.

Those checks are valuable. They answer whether a supplied template is structurally admissible and whether the target values can be expanded under a defined grammar. They do not answer who supplied the template, whether that supplier was authorised to redirect this workload, or whether the proxy origin represents the administrative service the operator intended to trust.

One service, three HTTP mappings

The wire procedure changes with the HTTP version while the logical service remains the same. In HTTP/1.1, the client sends a GET request to the expanded URI and asks to upgrade to connect-tcp. If the request is well formed and permissible, the proxy must attempt the destination TCP connection before returning a final status other than 100 Continue. A successful connection produces 101 Switching Protocols.

In HTTP/2 and HTTP/3, the proxy advertises extended CONNECT support. The request uses :protocol = connect-tcp, puts the proxy in :authority, and places the template-derived scheme and path in the corresponding pseudo-fields. A successful CONNECT response opens the stream for the capsule protocol.

This distinction matters operationally. A 100 Continue confirms that the proxy received the request and did not reject it immediately; it deliberately does not wait for the destination handshake. A later 101 or successful extended CONNECT response reports a stronger fact: under the protocol, the proxy established a TCP connection. Neither fact identifies the application on the far end, validates its TLS certificate, proves that bytes reached it, or shows that it performed the requested work.

Ordinary HTTP authentication changes the control point

The templated proxy is a resource at an HTTP origin, so revision 14 normally uses 401, WWW-Authenticate and Authorization. It does not use classic 407 proxy authentication because those fields do not traverse ordinary HTTP gateways. Resources generated by one template are expected to share a protection space; TLS client certificates can also be used.

This is a practical advantage. An operator can place the proxy behind gateway routing, DDoS controls, request sanitisation and user authorization. A high-entropy path or concealed authentication can make the service difficult for unauthorised probes to discover.

But authentication should retain its exact object. A valid credential says that a client satisfied an authentication scheme for the proxy’s protection space. Destination policy still decides whether that principal may reach this host and port. DNS resolution still chooses addresses. Target TLS still proves—or fails to prove—the application endpoint. The application still decides whether the authenticated party may perform a business action.

Classic HTTP already warns proxies to restrict CONNECT targets because arbitrary ports can turn a tunnel service into a relay for unintended protocols. The new template does not remove that risk. It gives the policy decision a clearer HTTP surface on which to operate.

Capsules preserve order, not business meaning

After setup, the draft carries TCP payload in DATA capsules. FINAL_DATA carries payload too, but also marks the directional equivalent of TCP FIN. An endpoint must not send more DATA or FINAL_DATA after FINAL_DATA. A received TCP FIN must become FINAL_DATA; a valid FINAL_DATA must become TCP FIN.

The boundaries are deliberately not sacred. They need not match TCP segments, TLS records, HTTP DATA frames or QUIC stream frames. An intermediary may merge or split consecutive capsules as long as byte order is preserved and the final output retains the final input’s closure meaning.

This yields a narrow, testable invariant: ordered bytes and half-close state can cross HTTP intermediaries without pretending capsule boundaries are application records. It also explains why capture at one layer is not proof at another. A client may have submitted bytes into an HTTP stream while the proxy is still buffering optimistic content. A proxy may have written bytes to a TCP socket while the target application has not processed them. FINAL_DATA may have preserved a FIN while the reverse direction later fails abruptly.

The evidence chain should therefore record template provenance, validation, proxy TLS identity, HTTP authentication, destination-policy decision, address selection, TCP attempt and result, response status, capsule ordering, target-side TLS identity, delivered bytes, closure state and observed application outcome separately.

The standard is still being decided

The IESG opened Last Call on 17 September and requested comments by 1 October. Datatracker lists revision 14 as active, submitted to the IESG, and intended for Proposed Standard publication.

Those are process facts, not a completed standard. The text itself remains an Internet-Draft and may be revised, replaced or allowed to expire. Even publication as an RFC would establish a protocol contract, not prove that gateways support the upgrade, clients validate provisioning correctly, products implement closure semantics, or operators have selected safe destination policy.

Running-code primacy supplies the right discipline here: the record should prove only what the running system exposed. Minimum initial specification and local future decision suggests a similarly narrow boundary. Common syntax can preserve ordering, validation and interoperable closure. Trust in provisioning, target policy, credentials and acceptable outcomes remains with the actors who bear the loss.

The proxy can say yes to a tunnel. It cannot make every claim beyond that tunnel true.

Sources