Handle EOF in a Python SOCKS Read Loop
Handle EOF explicitly in a SOCKS exact-read loop instead of treating a closed connection as a timeout that never arrives.
A loop wants eight bytes of a SOCKS reply. It has received three. The next read returns b'', and the loop appends it, checks the length, and tries again forever.
That is an EOF-handling bug, not a slow proxy that needs a longer timeout. For a normal stream-socket receive, an empty byte string means the peer has disconnected. The remaining five bytes will not arrive on that connection.
An exact-read helper needs three distinct outcomes: accumulate nonempty chunks, fail on EOF before the required length, and propagate a timeout or other socket error. Those cases should not collapse into one generic retry loop.
Set the socket's intended timeout before the operation, and read the field lengths specified by the proxy protocol. A single receive can return only part of a reply. Conversely, asking for a large fixed buffer does not make every SOCKS address have that length.
Do not repair a dependency by pasting an old MSG_WAITALL snippet into its source and assuming it covers EOF, signals, and platform behavior. Prefer the maintained implementation's supported fix, or implement the helper's contract deliberately when the parser is your code.
Retain how many bytes were expected and received, without logging credential payloads. “EOF after three of eight reply bytes” explains the broken exchange far better than “proxy hung again.”