The directive in question provides direct access to the ngx_http_internal_redirect/ngx_http_named_location APIs, allowing to simplify and optimize several real-life configurations where the modules should be executed multiple times/in a different order/with a different configuration/etc, sometimes based on a condition evaluated during the request processing. Common examples include passing artifacts of one access module to another (auth_request -> auth_jwt) or deferring the enforcement of pre-access checks (limit_req/limit_conn) after the request is authorized.
Most of that was already achievable with the existing tools, so here is a list of reasons for implementing a dedicated internal_redirect directive: * It offers a small, single purpose utility which is easier to document or find in the documentation. We often see configurations using double proxying instead of a redirect, just because the authors weren't aware of the simpler solution and weren't able to find it in the reference; it's not obvious that `try_files` can be used this way, and that's not the main purpose of the directive. The necessary clues are documented, but without highlighting the scenarios in question. It also may look like an abuse of the directive with some more workarounds on top. * There is a certain overhead in comparable configurations with the try_files directive: blocking filesystem access, which may introduce noticeable delays[^1], a few allocations and more code in general. * An ability of conditional execution[^2]. It is common enough with other configuration directives that an empty value means no operation. We can use that to implement the conditions that allow skipping the redirect and proceeding to the content phase handlers. * We already offer an access to the internal redirect through the njs or perl APIs. The directive allows expressing similar logic as a static configuration. * The existing directive has some unexpected configuration pitfalls. Case in point, `alias` directive in the same location may result in a prefix being stripped from the redirect target, but only if the parameter contains variables. The behavior may catch some users unaware (#97 and all the duplicates). [^1]: Which could be partially mitigated with `open_file_cache`. You'll need to read the source or have above average knowledge of the configuration to know that. [^2]: This can be added to the `try_files` as well, but it will further complicate the code and make already overloaded documentation even worse. With best regards, Aleksei
nginx.patch
Description: nginx.patch
_______________________________________________ nginx-devel mailing list -- nginx-devel@nginx.org To unsubscribe send an email to nginx-devel-le...@nginx.org
