Захаванне закадзіраваных шляхоў у існуючым маршруце перанакіравання HTTP у NGINX
Выкарыстоўвайце request_uri, калі дамова перанакіравання патрабуе зыходны шлях і запыт, захоўваючы існуючую праверку прызначэння.
Маршрут, пабудаваны з $uri, можа адправіць іншы шлях, чым той, які падаў кліент. Для http://service.example/files/a%2Fb?view=raw экранаваная касая рыска з'яўляецца часткай таго зыходнага напісання.
| Зменная | Прадстаўленне |
|---|---|
| $uri | Бягучы нармалізаваны URI, які можа змяняцца падчас унутранай апрацоўкі |
| $request_uri | Зыходны URI запыту, уключаючы яго аргументы запыту |
У існуючай схеме праксі-перанакіравання HTTP, якая ўжо выбірае і правярае паўнамоцтвы прызначэння, зыходны шлях і запыт можна захаваць наступным чынам:
proxy_pass http://$http_host$request_uri;$http_host падае абраныя паўнамоцтвы загалоўка Host у гэтай схеме. Захавайце абмежаванні кліентаў слухача, палітыку прызначэння і канфігурацыю развязання імёнаў.
Замяшчэнне $uri$is_args$args гэтым выразам змяняе прадстаўленне, якое адпраўляецца; папярэдні выраз выкарыстоўвае нармалізаваны шлях і бягучыя аргументы. Выбірайце згодна з дамовай канчатковай кропкі, асабліва калі экранаваныя раздзяляльнікі маюць значэнне або подпіс ахоплівае зыходную мэту. Наўмыснае перапісванне шляху мае іншае патрабаванне.
Гэта тычыцца бачнага HTTP-запыту. Тунель HTTPS CONNECT пераносіць наступны запыт унутры TLS і патрабуе ўласнай падтрыманай апрацоўкі.