La gastnomo de la antaŭa prokura servilo mankas en la peto

Ordinara HTTP-peto tra antaŭa prokura servilo identigas la celon, do Host kaj la gastnomo de Express ne povas distingi kaŝnomojn de la prokura servilo mem.

Supozu, ke east.proxy.example kaj west.proxy.example solviĝas al la sama ordinara HTTP-prokura aŭskultilo. Kliento uzanta ajnan el la nomoj povas sendi:

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

La peto identigas la retejon. Ĝi ne portas la prokuran kaŝnomon, kiun la kliento solvis antaŭ ol malfermi TCP. Tial la gastnomo de Express derivita de Host ne povas elekti itineron surbaze de tiuj prokuraj subdomajnoj.

Se vi regas la klienton kaj la prokuran servilon, provizu eksplicitan enigon por enkursigado. Por prokura servilo, kiu realigas etikedon X-Route:

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

--proxy-header celas la komunikadon kun la prokura servilo, inkluzive de CONNECT. Ordinara -H-kaplinio en la HTTPS-peto apartenas interne al la ĉifrita HTTP-interŝanĝo de la celo.

La servilo devas realigi kaj rajtigi la enkursigan politikon, kaj poste konsumi la etikedon sen fordoni ĝin al la retejo. Alternative, uzu aparte agorditajn aŭskultajn finpunktojn aŭ prokurajn kontojn kiel enigojn por enkursigado.

Por HTTPS-celoj, Node ricevas la unuan tunelan peton per la connect-okazaĵo de sia HTTP-servilo. Ordinara Express-peta meza programaro ne pritraktas tiun okazaĵon. Ĝia CONNECT-celo ankoraŭ identigas la celan servilon, ne la prokuran kaŝnomon.

Rilataj artikoloj