Bevara buffrad data efter ett HTTP CONNECT-svar
Undvik en fastlåst HTTP CONNECT-handskakning genom att hitta gränsen för svarshuvudena och bevara de byte som kommer efter den.
En liten proxy-wrapper kan fungera för HTTPS och sedan hänga sig när den återanvänds för ett protokoll vars server talar först. Den misstänkta raden är ofta den som väntar på att mottagningsbufferten slutar med \r\n\r\n.
TCP ger klienten en ström. Ett mottagningsanrop kan returnera halva HTTP-statusraden, ett komplett CONNECT-svar, eller det svaret omedelbart följt av tunneldatа. Det finns inget löfte om att en läsning stannar vid slutet av huvudena.
Hitta gränsen inuti bufferten
För ett HTTP/1.1 CONNECT-utbyte, samla byte tills huvudavslutningen dyker upp var som helst i bufferten. Dela vid dess första förekomst. Tolka statusraden och huvudena från den första delen; behåll allt efter gränsen separat. Tillämpa en gräns för huvudstorlek och en tidsgräns medan du väntar, och behandla en tom socket-läsning som en stängd anslutning i stället för en ny inbjudan att loopa.
Ett slutligt lyckat 2xx-svar växlar anslutningen till tunnelläge direkt efter dessa huvuden. Byten som följer är redan tunnelbyten. Kasta inte bort dem, vänta inte på en CONNECT-svarskropp, och tolka inte ett Content-Length-fält som tillstånd att förbruka en del av det nya protokollet. Informationssvar, om sådana finns, måste hanteras före det slutliga svaret.
Wrappern måste lämna vidare sina rester
Att bara returnera den underliggande socketen förlorar de byten som handskakningsparsern redan har dragit ut ur den. Nästa läsare behöver en buffrad ström som först ger den sparade svansen och sedan återupptar socket-läsningarna. För ett server-först-protokoll kan förlusten av den första hälsningen låta båda sidor vänta i oändlighet.
Omvänt är byte från ett misslyckat CONNECT-svar ingen tunnelhälsning. En 407 tillhör fortfarande proxy-utbytet och kräver autentiseringshantering; en annan icke-lyckad status kräver en lämplig felväg.
Detta är särskilt viktigt när en FTP- eller SSH-klient anpassas via en HTTP-proxy. Proxyn måste också tillåta den begärda målporten, och FTP kan behöva ytterligare dataanslutningar. Korrekt huvudtolkning löser strömöverlämningen; den kan inte bevilja CONNECT-tillstånd eller tillhandahålla FTP:s andra kanal.