Rukovanje EOF-om u Python SOCKS petlji čitanja
Eksplicitno rukujte EOF-om u SOCKS petlji tačnog čitanja umjesto da zatvorenu vezu tretirate kao tajmaut koji nikad ne dolazi.
Petlja želi osam bajtova SOCKS odgovora. Primila je tri. Sljedeće čitanje vraća b'', petlja ga dodaje, provjerava dužinu i ponovo pokušava zauvijek.
To je greška u rukovanju EOF-om, a ne spor proxy kojem treba duži tajmaut. Za normalno primanje preko stream socketa, prazan bajt niz znači da se druga strana odspojila. Preostalih pet bajtova neće stići tom vezom.
Pomoćnik za tačno čitanje treba tri različita ishoda: akumulirati neprazne dijelove, pasti na EOF prije potrebne dužine i proslijediti tajmaut ili drugu grešku socketa. Ti se slučajevi ne smiju stopiti u jednu generičku petlju ponovnih pokušaja.
Postavite predviđeni tajmaut socketa prije operacije i čitajte dužine polja koje propisuje proxy protokol. Jedno primanje može vratiti samo dio odgovora. Suprotno tome, zahtjev za velikim fiksnim baferom ne čini svaku SOCKS adresu te dužine.
Ne popravljajte zavisnost lijepljenjem starog MSG_WAITALL isječka u njen izvorni kod i pretpostavkom da pokriva EOF, signale i ponašanje platforme. Preferirajte podržani popravak u održavanoj implementaciji ili namjerno implementirajte ugovor pomoćnika kada je parser vaš kod.
Zadržite koliko je bajtova očekivano i primljeno, bez logovanja korisnih opterećenja akreditiva. „EOF nakon tri od osam bajtova odgovora“ objašnjava pokvarenu razmjenu mnogo bolje od „proxy se ponovo zaledio“.