Behold bufret data etter et HTTP CONNECT-svar
Unngå en fastlåst HTTP CONNECT-håndtrykk ved å finne grensen for svarheaderne og beholde bytene som kommer etter den.
En liten proxy-wrapper kan fungere for HTTPS og deretter henge når den brukes på nytt for en protokoll der serveren snakker først. Den mistenkelige linjen er ofte den som venter på at mottaksbufferen ender med \r\n\r\n.
TCP gir klienten en strøm. Ett mottakskall kan returnere halve HTTP-statuslinjen, et fullstendig CONNECT-svar, eller det svaret umiddelbart etterfulgt av tunneldatа. Det finnes ingen garanti for at en lesing stopper ved slutten av headerne.
Finn grensen inne i bufferen
For en HTTP/1.1 CONNECT-utveksling samler du byter til header-avslutningen dukker opp hvor som helst i bufferen. Del ved første forekomst. Tolk statuslinjen og headerne 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 forbindelse i stedet for en ny invitasjon til å løkke.
Et endelig vellykket 2xx-svar setter forbindelsen i tunnelmodus umiddelbart etter disse headerne. Bytene som følger er allerede tunnelbyter. Ikke kast dem, ikke vent på en CONNECT-svarskropp, 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å sende restene sine videre
Å returnere bare den underliggende socketen mister de 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 byter fra et mislykket CONNECT-svar ikke en tunnelhilsen. En 407 tilhører fortsatt proxy-utvekslingen og krever håndtering av autentisering; en annen ikke-vellykket status krever en passende feilvei.
Dette er spesielt viktig når en FTP- eller SSH-klient tilpasses gjennom en HTTP-proxy. Proxyen må også tillate den forespurte destinasjonsporten, og FTP kan trenge flere datatilkoblinger. Korrekt headertolkning løser strømoverleveringen; den kan ikke gi CONNECT-tillatelse eller skaffe FTPs andre kanal.