Node HTTP poslužitelj obrađuje običan proxy zahtjev kroz svoj callback za zahtjev. CONNECT ide drugim putem: poslužitelj emitira connect sa zahtjevom, klijentskom utičnicom i head međuspremnikom.

Taj događaj je primopredaja između HTTP parsiranja i tunela. Ne postoji običan ServerResponse objekt koji bi se mogao nastaviti koristiti za tunelirani promet.

ArgumentŠto nosi
reqCONNECT zahtjev, uključujući odredišni autoritet i zaglavlja
clientSocketVeza natrag prema klijentu
headTunelski podaci koje je Node već pročitao nakon HTTP zaglavlja, moguće prazni

Dovršite HTTP odluku prije prosljeđivanja bajtova

Provjerite traženi host i port, primijenite proxyjevu politiku pristupa i autentifikacije te uspostavite vezu prema uzvodnom poslužitelju. CONNECT identificira autoritet poput service.example:443; parsirajte taj oblik imajući na umu IPv6 autoritete, umjesto da slijepo dijelite na svakoj dvotočki.

Kada se tunel prihvati, pošaljite uspješan HTTP odgovor praćen njegovim završnim praznim redom. Zatim proslijedite sve head bajtove uzvodno prije nego nastavite s kasnijim bajtovima iz klijentske utičnice. Priključivanje novog data listenera ne može povratiti međuspremnik koji je već zasebno dostavljen rukovatelju.

Nodeov službeni primjer tuneliranja obavlja tu primopredaju s serverSocket.write(head) prije povezivanja dva smjera toka. Njegov mali primjer ilustrira prijelaz; implementirani proxy također zahtijeva ograničene pokušaje povezivanja, kontrole pristupa i upravljanje životnim ciklusom.

Nakon uspjeha, bajtovi pripadaju protokolu usluge

Uspješan CONNECT odgovor pretvara vezu u tok bajtova. Ako je cilj HTTPS web-mjesto, njegova TLS razmjena putuje unutar tog toka. Samo tuneliranje ne zahtijeva da proxy izda zamjenski certifikat web-mjesta.

Prije prihvaćanja CONNECT, HTTP pogreška može objasniti zašto je odbijen. Nakon prihvaćanja, upisivanje HTTP 500 u tok ubacilo bi bajtove u tunelirani protokol. Umjesto toga, prekinite ili uništite odgovarajuće veze pri kasnijim neuspjesima.

Povežite oba smjera s rukovanje tokom svjesno povratnog pritiska, i odlučite kako end, error i close događaji prekidaju partnera. Sačuvajte početni head međuspremnik kao dio istog modela vlasništva; to su aplikacijski podaci, a ne višak HTTP zaglavlja za odbacivanje.

Povezani članci