Summary

  • Classic HTTP CONNECT names the destination but gives the proxy service no explicit origin or path. The new connect-tcp mode supplies a URI template and carries the byte stream in Capsule Protocol messages.
  • The IESG approved the draft for Proposed Standard publication on 30 October. Gateways that support it must translate the new tunnel across the HTTP versions they handle; the draft reports no deployment count or field results.

The proxy has a name. The gateway has a new job.

For years, HTTP CONNECT has let a client ask a proxy to open a TCP connection to a destination host and port. The proxy then carries bytes between the client and that destination. A shared server can do the work, but the request does not give the proxy service its own path or origin. The request names where the tunnel should go, not which proxy service the client is using.

That distinction becomes awkward when one HTTP server hosts more than one proxy service. With no service path or origin, it cannot distinguish those services the way it distinguishes ordinary web resources or virtual hosts. The draft also points to a security consequence: classic CONNECT's missing proxy origin leaves familiar defenses against server port misdirection unavailable and makes the scope of headers such as Alt-Svc or Strict-Transport-Security unclear.

On 30 October, the IESG approved draft-ietf-httpbis-connect-tcp for publication as a Proposed Standard. The current text, version 17, was published the previous day. It proposes a new way to tunnel TCP over HTTP, not a new rule about which destinations a user may reach. That distinction is the whole story: the proxy gets a better-defined address; the permission decision stays with the proxy operator.

The draft identifies a proxy with a URI Template containing target_host and target_port. The client fills in the destination and sends the resulting request URI to the proxy. In HTTP/1.1, that is a GET followed by an Upgrade to connect-tcp. In HTTP/2 and HTTP/3, it is Extended CONNECT with :protocol set to connect-tcp. The proxy advertises whether it supports Extended CONNECT in its settings.

The TCP stream travels inside Capsule Protocol messages. DATA carries bytes; FINAL_DATA carries the final bytes and signals the equivalent of a TCP FIN. Capsule boundaries do not pretend to be TCP segments or TLS records. They are packaging for the stream as it moves through HTTP.

A defined origin and path give a proxy service a place in ordinary HTTP semantics. The proxy can distinguish services on one server, and origin-scoped headers acquire a scope. But the draft preserves the existing authorization boundary: a proxy still needs its own rules for permitted destinations. CONNECT-TCP does not turn a URI template into an access-control list.

Now comes the bill. A gateway that claims compatibility must handle HTTP/1.1 Upgrade or Extended CONNECT, forward the connect-tcp protocol, and convert requests among the HTTP versions it supports. It must also let Proxy-Status pass through. If the origin authenticates users with TLS client certificates, the gateway must do that authentication itself or pass the relevant certificate information onward.

The IETF has written the handoff into the requirements. It has not supplied the gateway upgrade. The public draft and decision record contain no count of deployed gateways, no adoption forecast and no measured interoperation results. A standard can settle the wire shape; operators still have to find every proxy, gateway and authentication boundary that touches it.

Sources