Upravljalniki CONNECT v Node.js morajo ohraniti buffer head
Upravljajte vtičnico CONNECT in buffer head v Node na meji med HTTP in tunelom ter ohranite bajte, ki so bili že prebrani za glavami.
Strežnik HTTP Node obdela običajno zahtevo proxy prek svojega povratnega klica zahteve. CONNECT ubira drugo pot: strežnik odda connect skupaj z zahtevo, odjemalčevo vtičnico in bufferjem head.
Ta dogodek je predaja med razčlenjevanjem HTTP in tunelom. Ni običajnega predmeta ServerResponse, ki bi ga bilo mogoče še naprej uporabljati za tunelirani promet.
| Argument | Kaj prenaša |
|---|---|
req | Zahteva CONNECT, vključno z njeno ciljno avtoriteto in glavami |
clientSocket | Povezava nazaj do odjemalca |
head | Podatki tunela, ki jih je Node že prebral za glavami HTTP, morda prazni |
Dokončajte odločitev HTTP, preden posredujete bajte
Preverite zahtevani gostitelj in vrata, uporabite politiko dostopa in preverjanja pristnosti proxyja ter vzpostavite povezavo navzgor. CONNECT prepozna avtoriteto, kot je service.example:443; to obliko razčlenite z upoštevanjem avtoritet IPv6, namesto da bi slepo delili na vsaki dvopičji.
Ko je tunel sprejet, pošljite uspešen odgovor HTTP, ki mu sledi zaključna prazna vrstica. Nato posredujte vse bajte head navzgor, preden nadaljujete z poznejšimi bajti iz odjemalčeve vtičnice. S pripenjanjem novega poslušalca podatkov ni mogoče obnoviti bufferja, ki je bil upravljalniku že ločeno dostavljen.
Uradni primer tuneliranja v Node izvede to predajo s serverSocket.write(head), preden poveže obe smeri toka. Njegov majhen primer ponazarja prehod; nameščeni proxy potrebuje tudi omejene poskuse povezave, nadzor dostopa in upravljanje življenjskega cikla.
Po uspehu bajti pripadajo protokolu storitve
Uspešen odgovor CONNECT spremeni povezavo v bajtni tok. Če je cilj spletno mesto HTTPS, njegova izmenjava TLS poteka znotraj tega toka. Samo tuneliranje ne zahteva, da proxy izda nadomestno potrdilo spletnega mesta.
Pred sprejemom CONNECT lahko napaka HTTP pojasni razlog zavrnitve. Po sprejemu bi pisanje HTTP 500 v tok vbrizgalo bajte v tunelirani protokol. Namesto tega ob poznejših napakah končajte ali uničite ustrezne povezave.
Povežite obe smeri z upravljanje toka z zavestjo o povratnem pritisku in odločite, kako dogodki end, error in close končajo partnerja. Ohranite začetni buffer head kot del istega modela lastništva; to so podatki aplikacije, ne odvečne glave HTTP za zavreči.