Bevar bufret data etter et HTTP CONNECT-svar
Unngå en fastlåst HTTP CONNECT-håndtrykk ved å finne grensen for svarhodene og bevare bytene som kommer etter den.
En liten proxy-innpakning kan fungere for HTTPS og deretter henge når den gjenbrukes for en protokoll der serveren snakker først. Den mistenkelige linjen er ofte den som venter på at mottaksbufferen slutter med \r\n\r\n.
TCP gir klienten en strøm. Ett mottakskall kan returnere halve HTTP-statuslinjen, et komplett CONNECT-svar, eller det svaret umiddelbart etterfulgt av tunneldata. Det er ingen garanti for at en lesing stopper ved slutten av hodene.
Finn grensen inne i bufferen
For en HTTP/1.1 CONNECT-utveksling, samle bytes til header-avslutningen dukker opp hvor som helst i bufferen. Del ved første forekomst. Analyser statuslinjen og hodene fra den første delen; behold alt etter grensen separat. Bruk en grense for headerstørrelse og en tidsavbrudd mens du venter, og behandle en tom socket-lesing som en lukket tilkobling i stedet for en ny invitasjon til å løkke.
Et endelig vellykket 2xx-svar setter tilkoblingen i tunnelmodus umiddelbart etter disse hodene. Bytene som følger er allerede tunnelbytes. Ikke forkast dem, ikke vent på en CONNECT-svarkropp, og ikke tolk et Content-Length-felt som tillatelse til å bruke en del av den nye protokollen. Informasjonssvar, hvis de finnes, må håndteres før det endelige svaret.
Innpakningen må videresende restene sine
Å returnere bare den underliggende socketen mister bytene som håndtrykksparseren allerede har trukket ut av den. Neste leser trenger en bufret strøm som gir den lagrede halen først og deretter gjenopptar socket-lesingene. For en server-først-protokoll kan tapet av den første hilsenen la begge sider vente i det uendelige.
Omvendt er bytes fra et mislykket CONNECT-svar ikke en tunnelhilsen. En 407 tilhører fortsatt proxy-utvekslingen og krever autentiseringshåndtering; en annen ikke-vellykket status krever en passende feilvei.
Dette er spesielt viktig når du tilpasser en FTP- eller SSH-klient gjennom en HTTP-proxy. Proxyen må også tillate den forespurte destinasjonsporten, og FTP kan trenge flere datatilkoblinger. Korrekt headerparsing løser strømoverleveringen; den kan ikke gi CONNECT-tillatelse eller skaffe FTPs andre kanal.