Сохранение закодированных путей в существующем маршруте пересылки 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 и требует собственной поддерживаемой обработки.