Păstrați datele tamponate după un răspuns HTTP CONNECT
Evitați un handshake HTTP CONNECT blocat găsind limita antetelor răspunsului și păstrând octeții care sosesc după ea.
Un mic wrapper de proxy poate funcționa pentru HTTPS și apoi se poate bloca atunci când este reutilizat pentru un protocol al cărui server vorbește primul. Linia suspectă este adesea cea care așteaptă ca bufferul de recepție să se termine cu \r\n\r\n.
TCP oferă clientului un flux. Un singur apel de recepție poate returna jumătate dintr-o linie de stare HTTP, un răspuns CONNECT complet sau acel răspuns urmat imediat de date de tunel. Nu există nicio garanție că o citire se oprește la sfârșitul antetelor.
Găsiți limita în interiorul bufferului
Pentru un schimb HTTP/1.1 CONNECT, acumulați octeți până când terminatorul antetelor apare oriunde în buffer. Împărțiți la prima sa apariție. Analizați linia de stare și antetele din prima parte; păstrați separat tot ce urmează limitei. Aplicați o limită de dimensiune a antetelor și un timeout în timpul așteptării, și tratați o citire goală a socketului ca o conexiune închisă, nu ca o nouă invitație la buclă.
Un răspuns 2xx final reușit comută conexiunea în modul tunel imediat după acele antete. Octeții care îl urmează sunt deja octeți de tunel. Nu îi aruncați, nu așteptați un corp de răspuns CONNECT și nu interpretați câmpul Content-Length ca permisiune de a consuma o parte din noul protocol. Răspunsurile informative, dacă există, trebuie tratate înaintea acelui răspuns final.
Wrapperul trebuie să transmită resturile sale
Returnarea doar a socketului subiacent pierde octeții pe care parserul de handshake i-a extras deja din el. Următorul cititor are nevoie de un flux tamponat care să livreze mai întâi coada salvată și apoi să reia citirile din socket. Pentru un protocol în care serverul vorbește primul, pierderea acelui salut inițial poate lăsa ambele părți să aștepte la nesfârșit.
Invers, octeții dintr-un răspuns CONNECT eșuat nu sunt un salut de tunel. Un 407 aparține în continuare schimbului cu proxy și necesită tratarea autentificării; un alt status nereușit necesită o cale de eroare adecvată.
Acest lucru contează mai ales la adaptarea unui client FTP sau SSH printr-un proxy HTTP. Proxyul trebuie să permită și portul de destinație solicitat, iar FTP poate avea nevoie de conexiuni de date suplimentare. Analiza corectă a antetelor rezolvă predarea fluxului; nu poate acorda permisiunea CONNECT și nu poate furniza al doilea canal al FTP.