Node.js CONNECT-traktantoj devas konservi la head-bufron
Traktu la CONNECT-ingon kaj head-bufron de Node ĉe la limo de HTTP al tunelo, konservante bajtojn jam legitajn preter la kaplinioj.
Node HTTP-servilo traktas ordinarion prokuran peton per sia pet-alvoko. CONNECT sekvas alian vojon: la servilo ellasas connect kun la peto, la klienta ingo kaj head-bufro.
Tiu okazaĵo estas la transdono inter HTTP-analizo kaj tunelo. Ne ekzistas ordinara ServerResponse-objekto por daŭre uzi por la tunela trafiko.
| Argumento | Kion ĝi portas |
|---|---|
req | La CONNECT-peto, inkluzive de ĝia cela aŭtoritato kaj kaplinioj |
clientSocket | La konekto reen al la kliento |
head | Tunelaj datumoj, kiujn Node jam legis preter la HTTP-kaplinioj, eble malplenaj |
Finu la HTTP-decidon antaŭ ol plusendi bajtojn
Validigu la petatan gastiganton kaj pordon, apliku la alir- kaj aŭtentikigpolitikon de la prokurilo, kaj starigu la supran konekton. CONNECT identigas aŭtoritaton kiel service.example:443; analizu tiun formon konsiderante IPv6-aŭtoritatojn anstataŭ blinde disigi ĉe ĉiu dupunkto.
Kiam la tunelo akceptiĝas, sendu la sukcesan HTTP-respondon sekvatan de ĝia fina malplena linio. Poste plusendu iujn ajn head-bajtojn supren antaŭ ol daŭrigi kun postaj bajtoj de la klienta ingo. Alkroĉi novan datuman aŭskultanton ne povas reakiri bufron jam aparte liveritan al la traktanto.
La oficiala tunela ekzemplo de Node plenumas tiun transdonon per serverSocket.write(head) antaŭ ol konekti la du fluajn direktojn. Ĝia malgranda ekzemplo ilustras la transiron; deplojita prokurilo ankaŭ bezonas limigitajn konek-provojn, alirkontrolojn kaj vivciklan administradon.
Post sukceso, la bajtoj apartenas al la servprotokolo
Sukcesa CONNECT-respondo ŝanĝas la konekton en bajtan fluon. Se la celo estas HTTPS-ejo, ĝia TLS-interŝanĝo vojaĝas ene de tiu fluo. Nur tuneligi ĝin ne postulas, ke la prokurilo eldonu anstataŭan retejan atestilon.
Antaŭ ol akcepti CONNECT, HTTP-eraro povas klarigi, kial ĝi estis rifuzita. Post akcepto, skribi HTTP 500 en la fluon enĵetus bajtojn en la tunelan protokolon. Anstataŭe, finu aŭ detruu la taŭgajn konektojn ĉe postaj malsukcesoj.
Konektu ambaŭ direktojn per fluadministrado konscia pri malantaŭa premo, kaj decidu kiel la okazaĵoj end, error kaj close finas la partneron. Konservu la komencan head-bufron kiel parton de la sama posedmodelo; ĝi estas aplikaĵaj datumoj, ne restaj HTTP-kaplinioj por forĵeti.