Preserve Buffered Data After an HTTP CONNECT Reply
Avoid a stuck HTTP CONNECT handshake by finding the response header boundary and preserving bytes that arrive after it.
A small proxy wrapper can work for HTTPS and then hang when reused for a protocol whose server speaks first. The suspicious line is often the one waiting for the receive buffer to end with \r\n\r\n.
TCP gives the client a stream. One receive call might return half an HTTP status line, a complete CONNECT reply, or that reply followed immediately by tunnel data. There is no promise that a read stops at the end of the headers.
Find the boundary inside the buffer
For an HTTP/1.1 CONNECT exchange, accumulate bytes until the header terminator appears anywhere in the buffer. Split at its first occurrence. Parse the status line and headers from the first part; retain everything after the boundary separately. Apply a header size limit and a timeout while waiting, and treat an empty socket read as a closed connection rather than another invitation to loop.
A final successful 2xx response switches the connection into tunnel mode immediately after those headers. Its trailing bytes are already tunnel bytes. Do not discard them, wait for a CONNECT response body, or interpret a Content-Length field as permission to consume part of the new protocol. Informational responses, if present, need to be handled before that final response.
The wrapper must pass its leftovers on
Returning only the underlying socket loses any bytes the handshake parser already pulled out of it. The next reader needs a buffered stream that yields the saved tail first and then resumes socket reads. For a server-first protocol, losing that initial greeting can leave both sides waiting indefinitely.
Conversely, bytes from a failed CONNECT response are not a tunnel greeting. A 407 still belongs to the proxy exchange and needs authentication handling; another non-success status needs an appropriate error path.
This matters especially when adapting an FTP or SSH client through an HTTP proxy. The proxy also has to permit the requested destination port, and FTP may need additional data connections. Correct header parsing solves the stream handoff; it cannot grant CONNECT permission or supply FTP's second channel.