Збереження закодованих шляхів у наявному маршруті пересилання 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 і потребує власної підтримуваної обробки.