Node.js CONNECT-handlere skal bevare head-bufferen
Håndtér Nodes CONNECT-socket og head-buffer ved grænsen mellem HTTP og tunnel, og bevar de bytes, der allerede er læst ud over headere.
En Node HTTP-server håndterer en almindelig proxyanmodning gennem sit request-callback. CONNECT følger en anden vej: serveren udsender connect med anmodningen, klientsocketten og en head-buffer.
Den hændelse er overdragelsen mellem HTTP-parsing og en tunnel. Der er ikke noget almindeligt ServerResponse-objekt at fortsætte med for den tunnellerede trafik.
| Argument | Hvad den bærer |
|---|---|
req | CONNECT-anmodningen, inklusive dens destinationsautoritet og headere |
clientSocket | Forbindelsen tilbage til klienten |
head | Tunneldata, som Node allerede har læst ud over HTTP-headerne, muligvis tomme |
Afslut HTTP-beslutningen, før bytes videresendes
Validér den ønskede vært og port, anvend proxyens adgangs- og godkendelsespolitik, og opret forbindelsen opstrøms. CONNECT identificerer en autoritet som service.example:443; parse den form med IPv6-autoriteter i tankerne i stedet for at splitte blindt ved hvert kolon.
Når tunnelen accepteres, send det vellykkede HTTP-svar efterfulgt af dets afsluttende tomme linje. Send derefter eventuelle head-bytes opstrøms, før der fortsættes med senere bytes fra klientsocketten. Ved at tilknytte en ny data-listener kan man ikke gendanne en buffer, der allerede er leveret separat til handleren.
Nodes officielle tunneleringseksempel udfører den overdragelse med serverSocket.write(head), før de to strømretninger forbindes. Dets lille eksempel illustrerer overgangen; en udrullet proxy har også brug for begrænsede forbindelsesforsøg, adgangskontroller og livscyklushåndtering.
Efter succes tilhører bytesene tjenesteprotokollen
Et vellykket CONNECT-svar ændrer forbindelsen til en bytestrøm. Hvis målet er et HTTPS-websted, foregår dets TLS-udveksling inde i den strøm. Blot at tunnellere det kræver ikke, at proxyen udsteder et erstatningscertifikat til webstedet.
Før CONNECT accepteres, kan en HTTP-fejl forklare, hvorfor det blev afvist. Efter accept ville skrivning af en HTTP 500 i strømmen injicere bytes i den tunnellerede protokol. Afslut eller ødelæg i stedet de relevante forbindelser ved senere fejl.
Forbind begge retninger med strømhåndtering med bagtryksbevidsthed, og beslut, hvordan end-, error- og close-hændelser afslutter modparten. Bevar den oprindelige head-buffer som en del af samme ejerskabsmodel; det er applikationsdata, ikke overskydende HTTP-headere, der skal kasseres.