Gestire l'EOF in un ciclo di lettura SOCKS in Python
Gestisci l'EOF esplicitamente in un ciclo di lettura esatta SOCKS invece di trattare una connessione chiusa come un timeout che non arriva mai.
Un ciclo vuole otto byte di una risposta SOCKS. Ne ha ricevuti tre. La lettura successiva restituisce b'', il ciclo lo aggiunge, controlla la lunghezza e riprova all'infinito.
È un bug di gestione dell'EOF, non un proxy lento che richiede un timeout più lungo. In una normale ricezione su socket di flusso, una stringa di byte vuota significa che il peer si è disconnesso. I cinque byte rimanenti non arriveranno su quella connessione.
Un helper di lettura esatta ha bisogno di tre esiti distinti: accumulare frammenti non vuoti, fallire su EOF prima della lunghezza richiesta e propagare un timeout o un altro errore di socket. Quei casi non dovrebbero collassare in un unico ciclo di tentativi generico.
Imposta il timeout previsto del socket prima dell'operazione e leggi le lunghezze dei campi specificate dal protocollo del proxy. Una singola ricezione può restituire solo una parte di una risposta. Al contrario, chiedere un grande buffer fisso non fa sì che ogni indirizzo SOCKS abbia quella lunghezza.
Non riparare una dipendenza incollando un vecchio frammento MSG_WAITALL nel suo sorgente e assumendo che copra EOF, segnali e comportamento della piattaforma. Preferisci la correzione supportata dell'implementazione mantenuta, oppure implementa deliberatamente il contratto dell'helper quando il parser è il tuo codice.
Conserva quanti byte erano attesi e ricevuti, senza registrare payload di credenziali. «EOF dopo tre degli otto byte di risposta» spiega lo scambio rotto molto meglio di «il proxy si è bloccato di nuovo».