Gebufferde gegevens bewaren na een HTTP CONNECT-antwoord
Voorkom een vastgelopen HTTP CONNECT-handshake door de grens van de antwoordheaders te vinden en de bytes die daarna aankomen te bewaren.
Een kleine proxy-wrapper kan werken voor HTTPS en daarna hangen wanneer hij opnieuw wordt gebruikt voor een protocol waarvan de server eerst spreekt. De verdachte regel is vaak degene die wacht tot de ontvangstbuffer eindigt met \r\n\r\n.
TCP geeft de client een stream. Eén ontvangstaanroep kan de helft van een HTTP-statusregel teruggeven, een volledig CONNECT-antwoord, of dat antwoord onmiddellijk gevolgd door tunnelgegevens. Er is geen belofte dat een leesbewerking bij het einde van de headers stopt.
Vind de grens in de buffer
Voor een HTTP/1.1 CONNECT-uitwisseling verzamel je bytes tot de header-terminator ergens in de buffer verschijnt. Splits bij het eerste voorkomen. Parseer de statusregel en headers uit het eerste deel; bewaar alles na de grens apart. Pas een limiet op de headergrootte en een time-out toe tijdens het wachten, en behandel een lege socket-leesbewerking als een gesloten verbinding in plaats van als een nieuwe uitnodiging om te blijven loopen.
Een laatste geslaagd 2xx-antwoord schakelt de verbinding direct na die headers naar tunnelmodus. De bytes die erop volgen zijn al tunnelbytes. Gooi ze niet weg, wacht niet op een CONNECT-antwoordlichaam, en interpreteer een Content-Length-veld niet als toestemming om een deel van het nieuwe protocol te verbruiken. Informationele antwoorden, indien aanwezig, moeten vóór dat laatste antwoord worden afgehandeld.
De wrapper moet zijn restanten doorgeven
Alleen de onderliggende socket teruggeven verliest de bytes die de handshake-parser er al uit heeft gehaald. De volgende lezer heeft een gebufferde stream nodig die eerst de bewaarde staart levert en daarna de socket-leesbewerkingen hervat. Voor een server-first-protocol kan het verlies van die eerste begroeting beide kanten oneindig laten wachten.
Omgekeerd zijn bytes van een mislukt CONNECT-antwoord geen tunnelbegroeting. Een 407 hoort nog steeds bij de proxy-uitwisseling en vereist afhandeling van authenticatie; een andere niet-succesvolle status vereist een passend foutpad.
Dit is vooral belangrijk bij het aanpassen van een FTP- of SSH-client via een HTTP-proxy. De proxy moet ook de gevraagde bestemmingspoort toestaan, en FTP kan extra dataconnecties nodig hebben. Correcte header-parsing lost de streamoverdracht op; het kan geen CONNECT-toestemming geven of het tweede kanaal van FTP leveren.