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

src/client/legacy/connect/proxy/tunnel.rs の CONNECT 応答処理から始め、次に src/common/rewind.rs の private Rewind struct を読んでバッファリングのコンテキストを理解してください。handshake API を確認し、厳密な応答解析と保持された初期データをどのように表現すべきか判断してください。トンネルの確立後に不正な応答が拒否され、ターゲットサーバーのデータが保持されれば完了です。

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