Ruani të dhënat e buferuara pas një përgjigjeje HTTP CONNECT
Shmangni një handshake HTTP CONNECT të bllokuar duke gjetur kufirin e header-ave të përgjigjes dhe duke ruajtur bajt-at që vijnë pas tij.
Një mbështjellës i vogël proxy mund të funksionojë për HTTPS dhe më pas të ngecë kur ripërdoret për një protokoll, serveri i të cilit flet i pari. Rreshti i dyshimtë është shpesh ai që pret që buferi i marrjes të përfundojë me \r\n\r\n.
TCP i jep klientit një rrjedhë. Një thirrje marrjeje mund të kthejë gjysmën e një rreshti statusi HTTP, një përgjigje të plotë CONNECT, ose atë përgjigje të ndjekur menjëherë nga të dhëna tuneli. Nuk ka asnjë premtim që një lexim ndalon në fund të header-ave.
Gjeni kufirin brenda buferit
Për një shkëmbim HTTP/1.1 CONNECT, grumbulloni bajt derisa përfunduesi i header-ave të shfaqet kudo në bufer. Ndajeni në shfaqjen e tij të parë. Analizoni rreshtin e statusit dhe header-at nga pjesa e parë; mbani veçmas gjithçka pas kufirit. Zbatoni një kufi madhësie header-ash dhe një afat kohor gjatë pritjes, dhe trajtojeni një lexim bosh të socket-it si lidhje të mbyllur, jo si një ftesë tjetër për cikël.
Një përgjigje finale 2xx e suksesshme e kalon lidhjen në modalitetin tunel menjëherë pas atyre header-ave. Bajt-at që e ndjekin janë tashmë bajt tuneli. Mos i hidhni, mos prisni një trup përgjigjeje CONNECT dhe mos e interpretoni fushën Content-Length si leje për të konsumuar një pjesë të protokollit të ri. Përgjigjet informuese, nëse ekzistojnë, duhet të trajtohen përpara asaj përgjigjeje finale.
Mbështjellësi duhet t’i kalojë mbetjet e tij
Kthimi vetëm i socket-it bazë humb çdo bajt që analizuesi i handshake-ut ka nxjerrë tashmë prej tij. Lexuesi i radhës ka nevojë për një rrjedhë të buferuar që jep së pari bishtin e ruajtur dhe më pas rifillon leximet nga socket-i. Për një protokoll ku serveri flet i pari, humbja e atij përshëndetjeje fillestare mund t’i lërë të dyja palët të presin pafundësisht.
Në të kundërt, bajt-at e një përgjigjeje CONNECT të dështuar nuk janë përshëndetje tuneli. Një 407 vazhdon t’i përkasë shkëmbimit me proxy-n dhe kërkon trajtim të vërtetimit; një status tjetër i pasuksesshëm kërkon një rrugë të përshtatshme gabimi.
Kjo ka rëndësi të veçantë kur përshtatet një klient FTP ose SSH përmes një proxy HTTP. Proxy duhet të lejojë gjithashtu portin e destinacionit të kërkuar, dhe FTP mund të ketë nevojë për lidhje shtesë të dhënash. Analizimi i saktë i header-ave zgjidh dorëzimin e rrjedhës; ai nuk mund të japë leje CONNECT ose të sigurojë kanalin e dytë të FTP.