Obslužné rutiny CONNECT v Node.js musí zachovat buffer head
Pracujte se socketem CONNECT a bufferem head v Node na hranici mezi HTTP a tunelem a zachovejte bajty již přečtené za hlavičkami.
Server Node HTTP obsluhuje běžný požadavek proxy prostřednictvím svého callbacku požadavku. CONNECT jde jinou cestou: server vyšle connect s požadavkem, klientským socketem a bufferem head.
Tato událost je předáním mezi parsováním HTTP a tunelem. Neexistuje běžný objekt ServerResponse, který by bylo možné nadále používat pro tunelovaný provoz.
| Argument | Co nese |
|---|---|
req | Požadavek CONNECT včetně cílové autority a hlaviček |
clientSocket | Spojení zpět ke klientovi |
head | Tunelová data, která Node již přečetl za hlavičkami HTTP, případně prázdná |
Dokončete rozhodnutí HTTP dříve, než předáte bajty
Ověřte požadovaný hostitel a port, použijte zásady přístupu a ověřování proxy a navázejte upstream spojení. CONNECT identifikuje autoritu jako service.example:443; tuto formu parsujte s ohledem na autority IPv6, místo abyste slepě dělili na každém dvojtečce.
Když je tunel přijat, odešlete úspěšnou odpověď HTTP následovanou jejím ukončujícím prázdným řádkem. Poté předejte všechny bajty head upstream, než budete pokračovat s dalšími bajty z klientského socketu. Připojením nového posluchače dat nelze obnovit buffer, který již byl obsluze předán samostatně.
Oficiální příklad tunelování v Node provádí toto předání pomocí serverSocket.write(head) před spojením obou směrů toku. Jeho malý příklad ilustruje přechod; nasazená proxy také potřebuje omezené pokusy o připojení, řízení přístupu a správu životního cyklu.
Po úspěchu bajty patří protokolu služby
Úspěšná odpověď CONNECT změní spojení na bajtový tok. Pokud je cílem web HTTPS, jeho výměna TLS probíhá uvnitř tohoto toku. Pouhé tunelování nevyžaduje, aby proxy vydala náhradní certifikát webu.
Před přijetím CONNECT může chyba HTTP vysvětlit, proč bylo odmítnuto. Po přijetí by zápis HTTP 500 do toku vložil bajty do tunelovaného protokolu. Při pozdějších selháních raději ukončete nebo zrušte příslušná spojení.
Spojte oba směry pomocí zpracování toku s ohledem na protitlak a rozhodněte, jak události end, error a close ukončí protějšek. Zachovejte počáteční buffer head jako součást stejného modelu vlastnictví; jsou to aplikační data, nikoli nadbytečné hlavičky HTTP k zahození.