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

从 src/client/legacy/connect/proxy/tunnel.rs 中的 CONNECT 响应处理开始，然后阅读 src/common/rewind.rs 中的私有 Rewind 结构，以了解缓冲上下文。检查 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