既存の NGINX HTTP 転送ルートでエンコードされたパスを保持する
転送契約が元のパスとクエリを必要とする場合は 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 内で運ぶため、独自のサポートされた処理が必要です。