Pangasiwaan ang EOF sa isang Python SOCKS Read Loop

Isang loop ang gustong makakuha ng walong byte ng isang SOCKS na sagot. May tatlo na itong natanggap. Ang susunod na pagbasa ay nagbabalik ng b'', idinadagdag ito ng loop, sinusuri ang haba, at paulit-ulit na sinusubukan magpakailanman.

Ito ay isang bug sa paghawak ng EOF, hindi isang mabagal na proxy na nangangailangan ng mas mahabang timeout. Sa normal na pagtanggap sa isang stream socket, ang walang laman na byte string ay nangangahulugang nag-disconnect ang peer. Ang natitirang limang byte ay hindi darating sa koneksyong iyon.

Ang isang exact-read helper ay nangangailangan ng tatlong magkakaibang kinalabasan: ipon ang mga hindi walang laman na tipak, mabigo sa EOF bago ang kinakailangang haba, at ipasa ang timeout o iba pang error ng socket. Ang mga kasong iyon ay hindi dapat mahulog sa isang generic na paulit-ulit na loop.

Itakda ang nilalayong timeout ng socket bago ang operasyon, at basahin ang mga haba ng field na tinukoy ng protocol ng proxy. Ang isang pagtanggap ay maaaring magbalik lamang ng bahagi ng isang sagot. Sa kabaligtaran, ang paghingi ng malaking fixed buffer ay hindi ginagawang ganoon ang haba ng bawat SOCKS address.

Huwag ayusin ang isang dependency sa pamamagitan ng pag-paste ng lumang MSG_WAITALL snippet sa source nito at pag-aakalang sakop nito ang EOF, mga signal, at pag-uugali ng platform. Piliin ang sinusuportahang pagwawasto ng pinapanatili na implementasyon, o sadyang ipatupad ang kontrata ng helper kapag ang parser ay iyong code.

Itago kung ilang byte ang inaasahan at natanggap, nang hindi nila-log ang mga credential payload. Ang “EOF pagkatapos ng tatlo sa walong response byte” ay mas mahusay na nagpapaliwanag ng sirang palitan kaysa sa “nag-hang na naman ang proxy”.