Rukovanje EOF-om u Python SOCKS petlji čitanja
Eksplicitno rukujte EOF-om u SOCKS petlji tačnog čitanja umesto da zatvorenu vezu tretirate kao tajmaut koji nikad ne dolazi.
Petlja želi osam bajtova SOCKS odgovora. Primila je tri. Sledeće čitanje vraća b'', petlja ga dodaje, proverava dužinu i ponovo pokušava zauvek.
To je greška u rukovanju EOF-om, a ne spor proxy kome treba duži tajmaut. Kod normalnog primanja preko stream socketa, prazan niz bajtova 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 delove, pasti na EOF pre potrebne dužine i proslediti tajmaut ili drugu grešku socketa. Ti slučajevi ne smeju da se stope u jednu generičku petlju ponovnih pokušaja.
Postavite predviđeni tajmaut socketa pre operacije i čitajte dužine polja koje propisuje proxy protokol. Jedno primanje može vratiti samo deo odgovora. Suprotno tome, zahtev za velikim fiksnim baferom ne čini svaku SOCKS adresu te dužine.
Ne popravljajte zavisnost lepljenjem starog MSG_WAITALL isečka u njen izvorni kod i pretpostavkom da pokriva EOF, signale i ponašanje platforme. Preferirajte podržani popravak u održavanoj implementaciji ili namerno implementirajte ugovor pomoćnika kada je parser vaš kod.
Zadržite koliko je bajtova očekivano i primljeno, bez logovanja korisnih opterećenja akreditive. „EOF nakon tri od osam bajtova odgovora“ objašnjava pokvarenu razmenu mnogo bolje od „proxy se ponovo zamrznuo“.