Trajtuesit CONNECT të Node.js duhet të ruajnë buffer-in head
Trajtoni socket-in CONNECT dhe buffer-in head të Node në kufirin nga HTTP në tunel, duke ruajtur bajtët e lexuar tashmë përtej header-ave.
Një server HTTP i Node trajton një kërkesë normale proxy përmes callback-ut të kërkesës. CONNECT ndjek një rrugë tjetër: serveri lëshon connect bashkë me kërkesën, socket-in e klientit dhe një buffer head.
Ai ngjarje është dorëzimi midis analizimit HTTP dhe një tuneli. Nuk ka objekt normal ServerResponse për të vazhduar përdorimin për trafikun e tunelizuar.
| Argument | Çfarë mbart |
|---|---|
req | Kërkesa CONNECT, duke përfshirë autoritetin e destinacionit dhe header-at |
clientSocket | Lidhja përsëri te klienti |
head | Të dhëna tuneli që Node ka lexuar tashmë përtej header-ave HTTP, ndoshta bosh |
Përfundoni vendimin HTTP përpara se të përcillni bajtë
Vërtetoni host-in dhe portin e kërkuar, zbatoni politikën e aksesit dhe vërtetimit të proxy-t dhe krijoni lidhjen lart. CONNECT identifikon një autoritet si service.example:443; analizoni atë formë duke pasur parasysh autoritetet IPv6 në vend që të ndani verbërisht në çdo dy pika.
Kur tuneli pranohet, dërgoni përgjigjen e suksesshme HTTP të ndjekur nga rreshti bosh që e përfundon. Më pas përcillni çdo bajt head lart përpara se të vazhdoni me bajtët e mëvonshëm nga socket-i i klientit. Bashkangjitja e një dëgjuesi të ri të dhënash nuk mund të rikuperojë një buffer që tashmë i është dorëzuar veçmas trajtuesit.
Shembulli zyrtar i tunelizimit të Node kryen atë dorëzim me serverSocket.write(head) përpara se të lidhë dy drejtimet e rrjedhës. Shembulli i tij i vogël ilustron tranzicionin; një proxy i vendosur ka nevojë gjithashtu për përpjekje të kufizuara lidhjeje, kontrolle aksesi dhe menaxhim të ciklit të jetës.
Pas suksesit, bajtët i përkasin protokollit të shërbimit
Një përgjigje e suksesshme CONNECT e kthen lidhjen në një rrjedhë bajtësh. Nëse objektivi është një faqe HTTPS, shkëmbimi i saj TLS udhëton brenda asaj rrjedhe. Vetëm tunelizimi nuk kërkon që proxy të lëshojë një certifikatë zëvendësuese të faqes.
Përpara se të pranohet CONNECT, një gabim HTTP mund të shpjegojë pse u refuzua. Pas pranimit, shkrimi i një HTTP 500 në rrjedhë do të injektonte bajtë në protokollin e tunelizuar. Në vend të kësaj, përfundoni ose shkatërroni lidhjet e duhura në dështimet e mëvonshme.
Lidhni të dy drejtimet me trajtimi i rrjedhës me ndërgjegjësim për kundërpresionin, dhe vendosni si ngjarjet end, error dhe close e përfundojnë partnerin. Ruani buffer-in fillestar head si pjesë e të njëjtit model pronësie; janë të dhëna aplikacioni, jo header-a HTTP të tepërta për t'u hedhur.