Falta el nom d'amfitrió del proxy directe a la petició

Una petició HTTP simple a través d'un proxy directe identifica la destinació, així que Host i el hostname d'Express no poden distingir els àlies del propi proxy.

Suposem que east.proxy.example i west.proxy.example resolen al mateix oient HTTP simple del proxy. Un client que faci servir qualsevol dels dos noms pot enviar:

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

La petició identifica el lloc web. No porta l'àlies del proxy que el client ha resolt abans d'obrir TCP. Per tant, el hostname derivat de Host a Express no pot triar una ruta basant-se en aquests subdominis del proxy.

Si controleu el client i el proxy, proporcioneu una entrada d'encaminament explícita. Per a un proxy que implementi una etiqueta X-Route:

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

--proxy-header apunta a la comunicació amb el proxy, incloent-hi CONNECT. Una capçalera -H normal a la petició HTTPS pertany dins de l'intercanvi HTTP xifrat de la destinació.

El servidor ha d'implementar i autoritzar la política d'encaminament, i després consumir l'etiqueta sense reenviar-la al lloc web. Alternativament, feu servir punts finals d'escolta o comptes de proxy configurats per separat com a entrades d'encaminament.

Per a destinacions HTTPS, Node rep la petició inicial del túnel mitjançant l'esdeveniment connect del seu servidor HTTP. El middleware de peticions habitual d'Express no gestiona aquest esdeveniment. El seu objectiu CONNECT continua identificant el servidor de destinació, no l'àlies del proxy.

Articles relacionats