Skip to content

feat(client): add HttpConnect connector that keeps early tunnel data - #320

Open
heitzlki wants to merge 1 commit into
hyperium:masterfrom
heitzlki:http-connect-proxy
Open

heitzlki wants to merge 1 commit into
hyperium:masterfrom
heitzlki:http-connect-proxy

Conversation

@heitzlki

@heitzlki heitzlki commented Sep 11, 2026

Copy link
Copy Markdown

Follow-up to hyperium/hyper#4095: #315 fixed the parsing, but tunnel() still throws away anything after the header end, which breaks protocols where the server speaks first. Fixing it in place changes Tunnel's response type, which is why #313 went nowhere.

So this is the alternative @seanmonstar suggested on the issue: a new connector, HttpConnect, that sends an actual CONNECT request over an h1 connection and returns the upgraded IO, early bytes survive through hyper's own upgrade buffer. The conn future is driven inside the connector future, so nothing needs to be spawned. The returned IO forwards Connected so it works with the legacy client. Tunnel itself is untouched except a pub(super) on the shared Headers enum.

HTTP/1 only for now, h2 CONNECT could go behind the same type later.

Closes hyperium/hyper#4095

Tunnel drops whatever the destination sends right after the proxy's
200, and fixing that in place would change its response type (hyperium#313).
HttpConnect does a real CONNECT request over an h1 connection and
returns the upgraded IO, so leftover bytes survive via hyper's
upgrade buffer. HTTP/1 only for now.

Closes hyperium/hyper#4095
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

HTTP CONNECT proxy tunnel has lax response parsing and loses early data

1 participant