Zachovat bufrovaná data po odpovědi HTTP CONNECT

Malý obal proxy může fungovat pro HTTPS a pak ztuhnout, když se znovu použije pro protokol, v němž mluví první server. Podezřelý řádek je často ten, který čeká, až přijímací buffer skončí na \r\n\r\n.

TCP dává klientovi proud. Jedno volání příjmu může vrátit polovinu stavového řádku HTTP, úplnou odpověď CONNECT, nebo tuto odpověď následovanou okamžitě daty tunelu. Neexistuje žádný slib, že se čtení zastaví na konci hlaviček.

Najděte hranici uvnitř bufferu

U výměny HTTP/1.1 CONNECT hromadějte bajty, dokud se terminátor hlaviček neobjeví kdekoli v bufferu. Rozdělte na jeho prvním výskytu. Z první části analyzujte stavový řádek a hlavičky; vše po hranici uchovejte zvlášť. Při čekání uplatněte limit velikosti hlaviček a časový limit a prázdné čtení soketu považujte za uzavřené spojení, nikoli za další výzvu k opakování.

Konečná úspěšná odpověď 2xx přepne spojení do režimu tunelu ihned po těchto hlavičkách. Její následující bajty jsou už bajty tunelu. Nezahazujte je, nečekejte tělo odpovědi CONNECT a nevykládejte pole Content-Length jako svolení spotřebovat část nového protokolu. Informační odpovědi, pokud existují, je třeba zpracovat před touto konečnou odpovědí.

Obal musí předat své zbytky

Vrácení pouze podkladového soketu ztratí všechny bajty, které z něj analyzátor handshaku už vytáhl. Další čtenář potřebuje bufrovaný proud, který nejprve vydá uložený ocas a poté obnoví čtení ze soketu. U protokolu, kde mluví první server, může ztráta tohoto úvodního pozdravu nechat obě strany čekat nekonečně.

Naopak bajty z neúspěšné odpovědi CONNECT nejsou pozdravem tunelu. 407 stále patří k výměně s proxy a vyžaduje zpracování autentizace; jiný neúspěšný stav vyžaduje odpovídající chybovou cestu.

To je důležité zejména při adaptaci klienta FTP nebo SSH přes HTTP proxy. Proxy také musí povolit požadovaný cílový port a FTP může potřebovat další datová spojení. Správné zpracování hlaviček řeší předání proudu; nemůže udělit povolení CONNECT ani zajistit druhý kanál FTP.