Bevar bufret data efter et HTTP CONNECT-svar
Undgå et fastlåst HTTP CONNECT-håndtryk ved at finde svarets header-grænse og bevare de bytes, der ankommer efter den.
En lille proxy-indpakning kan fungere til HTTPS og derefter gå i stå, når den genbruges til en protokol, hvor serveren taler først. Den mistænkelige linje er ofte den, der venter på, at modtagebufferen slutter med \r\n\r\n.
TCP giver klienten en strøm. Ét modtagekald kan returnere en halv HTTP-statuslinje, et komplet CONNECT-svar eller det svar umiddelbart efterfulgt af tunneldatas. Der er ingen garanti for, at en læsning stopper ved headersenes afslutning.
Find grænsen inde i bufferen
Ved en HTTP/1.1 CONNECT-udveksling akkumuleres bytes, indtil header-terminatoren vises hvor som helst i bufferen. Opdel ved dens første forekomst. Pars statuslinjen og headerne fra den første del; gem alt efter grænsen separat. Anvend en grænse for headerstørrelse og en timeout, mens der ventes, og behandl en tom socket-læsning som en lukket forbindelse i stedet for en ny invitation til at loope.
Et endeligt vellykket 2xx-svar skifter forbindelsen til tunnel-tilstand umiddelbart efter disse headers. Dets efterfølgende bytes er allerede tunnelbytes. Kassér dem ikke, vent ikke på en CONNECT-svarskrop, og fortolk ikke et Content-Length-felt som tilladelse til at forbruge en del af den nye protokol. Informationssvar skal, hvis de findes, håndteres før det endelige svar.
Indpakningen skal give sine rester videre
Returneres kun den underliggende socket, mistes alle bytes, som håndtryksparseren allerede har trukket ud af den. Den næste læser har brug for en bufret strøm, der først leverer den gemte hale og derefter genoptager socket-læsninger. Ved en server-first-protokol kan tabet af den indledende hilsen efterlade begge sider ventende i det uendelige.
Omvendt er bytes fra et mislykket CONNECT-svar ikke en tunnelhilsen. Et 407 hører stadig til proxy-udvekslingen og kræver godkendelseshåndtering; en anden ikke-successtatus kræver en passende fejlsti.
Det er især vigtigt, når en FTP- eller SSH-klient tilpasses gennem en HTTP-proxy. Proxyen skal også tillade den ønskede destinationsport, og FTP kan kræve yderligere dataforbindelser. Korrekt headerparsing løser strømoverdragelsen; den kan ikke give CONNECT-tilladelse eller levere FTP’s anden kanal.