Le nom d'hôte du proxy sortant manque dans la requête

Une requête HTTP ordinaire via un proxy sortant désigne la destination, donc Host et le nom d'hôte d'Express ne peuvent pas distinguer les alias du proxy lui-même.

Supposons que east.proxy.example et west.proxy.example se résolvent vers le même écouteur HTTP ordinaire du proxy. Un client qui utilise l'un ou l'autre nom peut envoyer :

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

La requête désigne le site web. Elle ne porte pas l'alias du proxy que le client a résolu avant d'ouvrir TCP. Le nom d'hôte dérivé de Host dans Express ne peut donc pas choisir une route d'après ces sous-domaines du proxy.

Si vous contrôlez le client et le proxy, fournissez une entrée de routage explicite. Pour un proxy qui met en œuvre une étiquette X-Route :

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

--proxy-header cible la communication avec le proxy, y compris CONNECT. Un en-tête -H ordinaire sur la requête HTTPS appartient à l'échange HTTP chiffré de la destination.

Le serveur doit mettre en œuvre et autoriser la politique de routage, puis consommer l'étiquette sans la transmettre au site web. Sinon, utilisez des points d'écoute ou des comptes de proxy configurés séparément comme entrées de routage.

Pour les destinations HTTPS, Node reçoit la requête de tunnel initiale via l'événement connect de son serveur HTTP. Le middleware de requête Express ordinaire ne traite pas cet événement. Sa cible CONNECT désigne toujours le serveur de destination, pas l'alias du proxy.

Articles similaires