En loop vill ha åtta byte av ett SOCKS-svar. Den har fått tre. Nästa läsning returnerar b'', och loopen lägger till den, kontrollerar längden och försöker igen i oändlighet.

Det är en EOF-hanteringsbugg, inte en långsam proxy som behöver en längre timeout. Vid ett normalt mottagande över en stream-socket betyder en tom bytesträng att motparten har kopplat från. De återstående fem byten kommer inte på den anslutningen.

En hjälpare för exakt läsning behöver tre olika utfall: ackumulera icke-tomma delar, misslyckas vid EOF före den krävda längden och vidarebefordra en timeout eller ett annat socketfel. Dessa fall bör inte kollapsa till en enda generisk återförsöksloop.

Ställ in socketens avsedda timeout före operationen och läs de fältlängder som proxyprotokollet anger. Ett enda mottagande kan bara returnera en del av ett svar. Omvänt gör en begäran om en stor fast buffert inte att varje SOCKS-adress har den längden.

Reparera inte ett beroende genom att klistra in ett gammalt MSG_WAITALL-utdrag i dess källkod och anta att det täcker EOF, signaler och plattformsbeteende. Föredra den underhållna implementationens stödda rättelse, eller implementera hjälparens kontrakt avsiktligt när parsern är din kod.

Behåll hur många byte som förväntades och togs emot, utan att logga inloggningsnyttolaster. ”EOF efter tre av åtta svarsbyten” förklarar det trasiga utbytet mycket bättre än ”proxyn hänger igen”.

Relaterade artiklar