De hostnaam van de forward-proxy ontbreekt in het verzoek

Een gewoon HTTP-forward-proxyverzoek identificeert de bestemming, dus Host en de Express-hostnaam kunnen de aliassen van de proxy zelf niet onderscheiden.

Stel dat east.proxy.example en west.proxy.example naar dezelfde eenvoudige HTTP-proxylistener verwijzen. Een client die een van beide namen gebruikt, kan sturen:

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

Het verzoek identificeert de website. Het draagt niet de proxyalias die de client heeft opgelost voordat TCP werd geopend. De van Host afgeleide hostnaam van Express kan daarom geen route kiezen op basis van die proxysubdomeinen.

Als u de client en de proxy beheert, zorg dan voor een expliciete routeringsinvoer. Voor een proxy die een X-Route-label implementeert:

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

--proxy-header richt zich op communicatie met de proxy, inclusief CONNECT. Een gewone -H-header op het HTTPS-verzoek hoort binnen de versleutelde HTTP-uitwisseling van de bestemming.

De server moet het routeringsbeleid implementeren en autoriseren en vervolgens het label gebruiken zonder het door te sturen naar de website. Als alternatief kunt u apart geconfigureerde luistereindpunten of proxyaccounts als routeringsinvoer gebruiken.

Voor HTTPS-bestemmingen ontvangt Node het eerste tunnelverzoek via de connect-gebeurtenis van zijn HTTP-server. Gewone Express-verzoekmiddleware verwerkt die gebeurtenis niet. Het CONNECT-doel identificeert nog steeds de bestemmingsserver, niet de proxyalias.

Gerelateerde artikelen