Vertsnavnet til videresendingsproxyen mangler i forespørselen

En vanlig HTTP-videresendingsproxyforespørsel identifiserer destinasjonen, så Host og Express-vertsnavn kan ikke skille aliasene til proxyen selv.

Anta at east.proxy.example og west.proxy.example peker på samme vanlige HTTP-proxylytter. En klient som bruker ett av navnene, kan sende:

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

Forespørselen identifiserer nettstedet. Den bærer ikke proxyaliaset som klienten løste opp før TCP ble åpnet. Derfor kan ikke Express' vertsnavn avledet fra Host velge en rute basert på disse proxysubdomenene.

Hvis du kontrollerer klienten og proxyen, gi et eksplisitt rutinginnput. For en proxy som implementerer en X-Route-etikett:

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

--proxy-header retter seg mot kommunikasjonen med proxyen, inkludert CONNECT. En vanlig -H-header på HTTPS-forespørselen hører til inne i destinasjonens krypterte HTTP-utveksling.

Serveren må implementere og autorisere rutingpolicyen, og deretter bruke etiketten uten å videresende den til nettstedet. Alternativt kan du bruke separat konfigurerte lytt endepunkter eller proxykontoer som rutinginnput.

For HTTPS-destinasjoner mottar Node den første tunnelanmodningen via connect-hendelsen til HTTP-serveren. Vanlig Express-forespørselsmiddleware håndterer ikke den hendelsen. CONNECT-målet identifiserer fortsatt destinasjonsserveren, ikke proxyaliaset.

Relaterte artikler