HTTP CONNECT proxy tunnel has lax response parsing and loses early data
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 48/100
- Issue type
- Bug
- Clarity
- Mostly clear
- Activity status
- Active
- Tech stack
- rust
- Domain
- networking
Research direction
Start in src/client/legacy/connect/proxy/tunnel.rs at the CONNECT response handling, then read the private Rewind struct in src/common/rewind.rs to understand the buffering context. Review the handshake API and determine how strict response parsing and retained early data should be represented; done means malformed responses are rejected and target-server data is preserved after the tunnel is established.
Written by the indexing model from the issue text.
Description
Version
hyper-util 0.1.20
Platform
Linux 6.18.14
Summary
While evaluating hyper-util's client::legacy::connect::proxy::tunnel for use with gRPC routing over HTTP CONNECT proxies, I identified two limitations in the current handshake implementation.
1. Lax Response Parsing
It heuristically matches the start and end of the expected response, potentially accepting malformed responses.
This can be fixed by using httparse to properly parse the response.
2. No Buffering for Early Data
It assumes the read buffer contains no data from the target server immediately after the proxy's response. This assumption holds for protocols where the client always speaks first (e.g., TLS) after the tunnel is established. However, since gRPC implementations must work with any security protocol, they must handle cases where the server sends data immediately.
Fixing this would require an API change, as the returned I/O stream would need to incorporate a buffer for the peeked data, similar to the private Rewind struct.
Although the handshaking code is simple enough to be re-implemented in gRPC, I wanted to check if these fixes can be upstreamed to allow us to use hyper-util.
Code Sample
Expected Behavior
- The proxy response must be correctly parsed.
- The data from the target server must be retained.
Actual Behavior
- A malformed proxy response may be accepted
- The data from the target server may be lost.
Additional Context
No response
- Dominant language
- Rust
- Stars
- 16.3k
- Forks
- 1.8k
- Avg merge
- 1d 23h
- Merged PRs (30d)
- 13
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from hyperium/hyper
-
C-feature
Difficulty 1/5 Under an hour Newbie friendliness 65/100
-
C-feature
Difficulty 5/5 Over a week Newbie friendliness 35/100
-
C-bug S-waiting-on-author
-
A-http2 C-bug
-
C-bug
Difficulty 4/5 3-5 days Newbie friendliness 48/100
Similar issues
-
bug github_actions
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
registrystack/registry-stack#1393 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
longbridge/gpui-kit#3223 ·
-
bug engine
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
rocky-data/rocky#2181 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
oasisprotocol/oasis-sdk#2523 ·
-
[indexer] [QA] Add a focused test for the new NonRetryableError / assertSocketAlive() behavior. Openbot:ai-assisted component:indexer QA-roadmap status:untriaged
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
midnightntwrk/midnight-indexer#1557 ·