Node.js CONNECT-käsitlejad peavad head-puhvri säilitama
Käsitlege Node'i CONNECT-soklit ja head-puhvrit HTTP ja tunneli piiril, säilitades päisedest kaugemale juba loetud baidid.
Node'i HTTP-server käsitleb tavalist pärineerimispäringut oma päringu callbacki kaudu. CONNECT läheb teist teed: server väljastab connect koos päringu, kliendi sokli ja head-puhvriga.
See sündmus on üleandmine HTTP-parsimise ja tunneli vahel. Tavalist ServerResponse-objekti, mida tunneliliikluse jaoks edasi kasutada, ei ole.
| Argument | Mida see kannab |
|---|---|
req | CONNECT-päring, sealhulgas selle sihtasutus ja päised |
clientSocket | Ühendus tagasi kliendi juurde |
head | Tunneliandmed, mille Node on juba HTTP-päistest kaugemale lugenud, võib-olla tühjad |
Lõpetage HTTP-otsus enne baitide edastamist
Valideerige nõutud host ja port, rakendage puhverserveri juurdepääsu- ja autentimispoliitikat ning looge ülemvooluühendus. CONNECT tuvastab asutuse nagu service.example:443; parsige seda vormi IPv6-asutusi silmas pidades, selle asemel et igal koolonil pimesi jagada.
Kui tunnel on vastu võetud, saatke edukas HTTP-vastus koos selle lõpetava tühja reaga. Seejärel edastage kõik head-baidid ülesvoolu enne, kui jätkate kliendi soklist tulevate hilisemate baitidega. Uue andmekuulaja lisamine ei suuda taastada puhvrit, mis on juba käsitlejale eraldi üle antud.
Node'i ametlik tunnelinäide teostab selle üleandmise serverSocket.write(head) abil enne kahe voosuuna ühendamist. Selle väike näide illustreerib üleminekut; juurutatud puhverserver vajab ka piiratud ühenduskatsete arvu, juurdepääsukontrolle ja elutsükli haldamist.
Pärast õnnestumist kuuluvad baidid teenuseprotokollile
Edukas CONNECT-vastus muudab ühenduse baidivooks. Kui sihtkoht on HTTPS-i sait, toimub selle TLS-vahetus selle voo sees. Ainuüksi tunnelamine ei nõua, et puhverserver väljastaks asendava veebisaidi sertifikaadi.
Enne CONNECT-i vastuvõtmist võib HTTP-viga selgitada, miks see tagasi lükati. Pärast vastuvõtmist sisestaks HTTP 500 kirjutamine voogu baidid tunneliprotokolli. Selle asemel lõpetage või hävitage hilisemate tõrgete korral asjakohased ühendused.
Ühendage mõlemad suunad vastusurveteadlik voo käsitlemine abil ja otsustage, kuidas end-, error- ja close-sündmused vastaspoole lõpetavad. Säilitage algne head-puhver sama omandimudeli osana; see on rakenduse andmed, mitte üleliigsed HTTP-päised, mille võib ära visata.