[6londe]

A single socket read does not necessarily contain exactly the HTTP CONNECT response headers. Fragmented replies currently fail parsing or return before the headers finish; a reply coalesced with the first tunnel bytes discards those bytes.

Read through the complete \r\n\r\n delimiter in both HTTP connectors, leaving subsequent bytes in the existing stream for the caller. RFC 9110 §9.3.6 defines that boundary between response headers and tunnel data.

The handshake uses one-byte read(1) calls with explicit EOF handling so it works with all existing socket/TLS stream implementations without adding buffering APIs. Headers are bounded to 64 KiB; this does not change tunnel reads or the accepted status-code policy.

Validation on current master 8d054e5:

• Original suite: 403 passed, 93% coverage.
• New framing regressions on unchanged source: 10 failures, 4 passing controls. Cases cover split status/headers, coalesced binary tunnel bytes, incomplete/oversized headers, and the exact 64 KiB boundary.
• uv run pytest tests --cov=./python_socks --cov-report=term: 417 passed, 93% coverage.
• uv run ruff check python_socks tests, uv run ruff format --check python_socks tests, and uv run mypy python_socks tests: passed.
• Independent loopback TCP proxy: 50 affected flows fail before the fix while 10 controls pass; all 60 pass afterward. This exercises sync, asyncio, Trio and AnyIO v1/v2 public APIs, including both AnyIO backends, and checks binary tunnel payloads, premature EOF and oversized headers.

Local validation used macOS arm64 / Python 3.12.13. Other Python versions and operating systems were not run locally. #33/#46 concern SOCKS5 reply parsing; this change is confined to HTTP CONNECT.

AI assistance: Codex authored the implementation and tests and ran the validation above. No human review has been performed.