Forward-proxyens værtsnavn mangler i anmodningen

Antag, at east.proxy.example og west.proxy.example opløses til den samme almindelige HTTP-proxylytter. En klient, der bruger et af navnene, kan sende:

GET http://www.example.org/report HTTP/1.1
Host: www.example.org

Anmodningen identificerer webstedet. Den bærer ikke det proxy-alias, som klienten opløste, før TCP blev åbnet. Værtsnavnet, som Express udleder af Host, kan derfor ikke vælge en rute ud fra de proxy-underdomæner.

Hvis du kontrollerer klienten og proxyen, skal du levere et eksplicit routing-input. For en proxy, der implementerer et X-Route-mærke:

curl --proxy http://east.proxy.example:8080 \
  --proxy-header 'X-Route: east' \
  https://www.example.org/

--proxy-header retter sig mod kommunikationen med proxyen, inklusive CONNECT. En almindelig -H-header på HTTPS-anmodningen hører hjemme inde i destinationens krypterede HTTP-udveksling.

Serveren skal implementere og godkende routingpolitikken og derefter forbruge mærket uden at videresende det til webstedet. Alternativt kan du bruge særskilt konfigurerede lytteendepunkter eller proxykonti som routing-input.

For HTTPS-destinationer modtager Node den indledende tunnelanmodning gennem sin HTTP-servers connect-begivenhed. Almindelig Express-anmodningsmiddleware håndterer ikke den begivenhed. Dets CONNECT-mål identificerer stadig destinationsserveren, ikke proxy-aliaset.