Skip to content

fix(client): don't reject CONNECT tunnel responses split across reads - #300

Closed
chatman-media wants to merge 1 commit into
hyperium:masterfrom
chatman-media:fix-tunnel-split-response
Closed

chatman-media wants to merge 1 commit into
hyperium:masterfrom
chatman-media:fix-tunnel-split-response

Conversation

@chatman-media

Copy link
Copy Markdown

The tunnel handshake in client::legacy::connect::proxy::Tunnel matches the proxy's status line against whatever bytes came back from the last read(), so if "HTTP/1.1 200 OK" happens to arrive split across two TCP segments, the first partial read (say, just "HTTP/1.1 2") doesn't match any of the expected prefixes and the whole thing bails out with TunnelUnsuccessful — even though a valid response is still on its way. Loopback tests never catch this since a single write_all almost always shows up as one read, but real proxies over a real network can and do split responses like this.

Fix just checks whether what we've got so far could still turn into a recognized status line before giving up, instead of only checking for a full/exact prefix match. Added a test that writes the response in two separate flushed writes with a delay in between (fails without the fix, passes with it), plus a test that a genuinely bad response split the same way still gets rejected promptly rather than hanging.

The proxy tunnel handshake in `Tunnel::call` matches the status line
against the raw bytes from each individual `read()`, so if a proxy's
"HTTP/1.1 200 OK" response happens to arrive in more than one TCP
segment, the first partial read (e.g. just "HTTP/1.1 2") doesn't match
any of the expected prefixes and gets rejected as TunnelUnsuccessful
right away, even though the rest of the response is on its way.

Added tests covering a valid response split across two reads (should
now succeed) and a genuinely bad response also split across reads
(should still fail promptly, not hang waiting for more data).
@cratelyn

cratelyn commented Sep 24, 2026 •

Copy link
Copy Markdown
Member

i believe this was superseded by #308. if this is mistaken, let me know!

@cratelyn cratelyn closed this Sep 24, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

A-legacy-client Area: legacy client. C-fix Category: bug fix. This is fixing a bug.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants