Vertsnamnet til videresendingsproxya manglar i førespurnaden

Ein vanleg HTTP-videresendingsproxyførespurnad identifiserer destinasjonen, så Host og Express-vertsnamn kan ikkje skilje aliasa til proxya sjølv.

Føreset at east.proxy.example og west.proxy.example peikar på same vanlege HTTP-proxylyttar. Ein klient som brukar eitt av namna, kan senda:

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

Førespurnaden identifiserer nettstaden. Han ber ikkje proxyaliaset som klienten løyste opp før TCP vart opna. Derfor kan ikkje Express-vertsnamnet avleidd frå Host velje ei rute basert på desse proxysubdomena.

Viss du styrer klienten og proxya, gje eit eksplisitt rutinginnput. For ei proxy som implementerer ei X-Route-etikett:

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

--proxy-header rettar seg mot kommunikasjonen med proxya, inkludert CONNECT. Ein vanleg -H-header på HTTPS-førespurnaden høyrer til inne i den krypterte HTTP-utvekslinga til destinasjonen.

Tenaren må implementere og autorisere rutingpolicyen og deretter bruke etiketten utan å videresende han til nettstaden. Alternativt kan du bruke separat konfigurerte lytt endepunkt eller proxykontoar som rutinginnput.

For HTTPS-destinasjonar mottek Node den første tunnelanmodninga via connect-hendinga til HTTP-tenaren. Vanleg Express-førespurnadsmiddleware handterer ikkje den hendinga. CONNECT-målet identifiserer framleis destinasjonstenaren, ikkje proxyaliaset.

Relaterte artiklar