Імя хоста прамога проксі адсутнічае ў запыце

Звычайны HTTP-запыт прамога проксі вызначае пункт прызначэння, таму Host і hostname Express не могуць адрозніць псеўданімы самога проксі.

Выкажам здагадку, што east.proxy.example і west.proxy.example указваюць на адзін і той жа звычайны HTTP-слухач проксі. Кліент, які выкарыстоўвае любое з гэтых імёнаў, можа адправіць:

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

Запыт вызначае вэб-сайт. Ён не перадае псеўданім проксі, які кліент вырашыў перад адкрыццём TCP. Таму hostname Express, атрыманы з Host, не можа выбраць маршрут на аснове гэтых паддамёнаў проксі.

Калі вы кантралюеце кліента і проксі, забяспечце явны ўвод для маршрутызацыі. Для проксі, які рэалізуе метку X-Route:

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

--proxy-header накіраваны на сувязь з проксі, уключаючы CONNECT. Звычайны загаловак -H у HTTPS-запыце знаходзіцца ўнутры зашыфраванага HTTP-абмену з пунктам прызначэння.

Сервер павінен рэалізаваць і аўтарызаваць палітыку маршрутызацыі, а затым выкарыстаць метку, не перадаючы яе вэб-сайту. Акрамя таго, можна выкарыстоўваць асобна наладжаныя канчатковыя пункты праслухоўвання або ўліковыя запісы проксі як увод для маршрутызацыі.

Для HTTPS-прызначэнняў Node атрымлівае першапачатковы запыт тунеля праз падзею connect свайго HTTP-сервера. Звычайнае прамежкавае ПЗ запытаў Express не апрацоўвае гэтую падзею. Яго мэта CONNECT па-ранейшаму вызначае сервер прызначэння, а не псеўданім проксі.

Падобныя артыкулы