CONNECT-behandlere i Node.js må bevare head-bufferen
Håndter Nodes CONNECT-socket og head-buffer ved grensen mellom HTTP og tunnel, og bevar bytene som allerede er lest utover headerne.
En Node HTTP-server håndterer en vanlig proxyforespørsel gjennom request-callbacken sin. CONNECT følger en annen vei: serveren sender ut connect med forespørselen, klientsocketen og en head-buffer.
Den hendelsen er overleveringen mellom HTTP-parsing og en tunnel. Det finnes ikke noe vanlig ServerResponse-objekt å fortsette å bruke for den tunnelerte trafikken.
| Argument | Hva den bærer |
|---|---|
req | CONNECT-forespørselen, inkludert dens destinasjonsautoritet og headere |
clientSocket | Forbindelsen tilbake til klienten |
head | Tunneldata som Node allerede har lest utover HTTP-headerne, muligens tomme |
Fullfør HTTP-beslutningen før byte videresendes
Valider ønsket vert og port, bruk proxyens tilgangs- og autentiseringspolicy, og opprett oppstrømsforbindelsen. CONNECT identifiserer en autoritet som service.example:443; parse den formen med IPv6-autoriteter i tankene i stedet for å dele blindt ved hvert kolon.
Når tunnelen godtas, send det vellykkede HTTP-svaret etterfulgt av den avsluttende tomme linjen. Videresend deretter eventuelle head-byte oppstrøms før du fortsetter med senere byte fra klientsocketen. Å koble til en ny data-lytter kan ikke gjenopprette en buffer som allerede er levert separat til behandleren.
Nodes offisielle tunneleringseksempel utfører den overleveringen med serverSocket.write(head) før de to strømretningene kobles sammen. Det lille eksempelet illustrerer overgangen; en utrullet proxy trenger også begrensede tilkoblingsforsøk, tilgangskontroller og livssyklushåndtering.
Etter suksess tilhører bytene tjenesteprotokollen
Et vellykket CONNECT-svar gjør forbindelsen om til en bytestrøm. Hvis målet er et HTTPS-nettsted, foregår TLS-utvekslingen inne i den strømmen. Bare å tunnelere den krever ikke at proxyen utsteder et erstatningssertifikat for nettstedet.
Før CONNECT godtas, kan en HTTP-feil forklare hvorfor det ble avvist. Etter godtakelse vil skriving av en HTTP 500 i strømmen injisere byte i den tunnelerte protokollen. Avslutt eller ødelegg i stedet de relevante forbindelsene ved senere feil.
Koble begge retninger med strømhåndtering med mottrykksbevissthet, og avgjør hvordan end-, error- og close-hendelser avslutter motparten. Bevar den opprinnelige head-bufferen som en del av samme eierskapsmodell; det er applikasjonsdata, ikke overflødige HTTP-headere som skal forkastes.