Der Hostname des Forward-Proxys fehlt in der Anfrage

Eine gewöhnliche HTTP-Anfrage über einen Forward-Proxy benennt das Ziel, daher können Host und der Hostname von Express keine Aliase des Proxys selbst unterscheiden.

Angenommen, east.proxy.example und west.proxy.example lösen auf denselben gewöhnlichen HTTP-Proxy-Listener auf. Ein Client, der einen der beiden Namen verwendet, kann senden:

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

Die Anfrage benennt die Website. Sie trägt nicht den Proxy-Alias, den der Client vor dem Öffnen von TCP aufgelöst hat. Der von Host abgeleitete Hostname in Express kann daher keine Route anhand dieser Proxy-Subdomains auswählen.

Wenn Sie Client und Proxy kontrollieren, stellen Sie eine ausdrückliche Routing-Eingabe bereit. Für einen Proxy, der eine X-Route-Kennung implementiert:

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

--proxy-header richtet sich an die Kommunikation mit dem Proxy, einschließlich CONNECT. Ein gewöhnlicher -H-Header der HTTPS-Anfrage gehört in den verschlüsselten HTTP-Austausch mit dem Ziel.

Der Server muss die Routing-Richtlinie umsetzen und autorisieren und die Kennung dann verwenden, ohne sie an die Website weiterzugeben. Alternativ können getrennt konfigurierte Listening-Endpunkte oder Proxy-Konten als Routing-Eingaben dienen.

Für HTTPS-Ziele erhält Node die erste Tunnelanfrage über das connect-Ereignis seines HTTP-Servers. Gewöhnliche Express-Anfrage-Middleware verarbeitet dieses Ereignis nicht. Ihr CONNECT-Ziel benennt weiterhin den Zielserver, nicht den Proxy-Alias.

Ähnliche Artikel