Kodierte Pfade in einer bestehenden NGINX-HTTP-Weiterleitungsroute erhalten
Verwenden Sie request_uri, wenn der Weiterleitungsvertrag den ursprünglichen Pfad und die Abfrage benötigt, und behalten Sie die bestehende Zielvalidierung bei.
Eine aus $uri aufgebaute Route kann einen anderen Pfad senden als den vom Client übergebenen. Bei http://service.example/files/a%2Fb?view=raw ist der maskierte Schrägstrich Teil dieser ursprünglichen Schreibweise.
| Variable | Darstellung |
|---|---|
| $uri | Die aktuelle normalisierte URI, die sich während der internen Verarbeitung ändern kann |
| $request_uri | Die ursprüngliche Anforderungs-URI einschließlich ihrer Abfrageargumente |
In einer bestehenden HTTP-Forward-Proxy-Konfiguration, die die Zielautorität bereits auswählt und validiert, lassen sich der ursprüngliche Pfad und die Abfrage so erhalten:
proxy_pass http://$http_host$request_uri;$http_host liefert die ausgewählte Autorität des Host-Headers in dieser Konfiguration. Behalten Sie die Client-Einschränkungen des Listeners, die Zielrichtlinie und die Namensauflösungskonfiguration bei.
Das Ersetzen von $uri$is_args$args durch diesen Ausdruck ändert die gesendete Darstellung; der frühere Ausdruck verwendet den normalisierten Pfad und die aktuellen Argumente. Wählen Sie nach dem Vertrag des Endpunkts, besonders wenn maskierte Trennzeichen wichtig sind oder eine Signatur das ursprüngliche Ziel abdeckt. Bewusstes Umschreiben des Pfads hat eine andere Anforderung.
Dies gilt für die sichtbare HTTP-Anforderung. Ein HTTPS-CONNECT-Tunnel trägt die spätere Anforderung innerhalb von TLS und erfordert eine eigene unterstützte Behandlung.