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

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

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.