Hello,
> > 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.
>
> No, thanks.
>
> Discussions about adding the "goto" directive date back to at
> least 2009. Igor's and my position on this are summarized here:
>
> https://mailman.nginx.org/pipermail/nginx-ru/2017-April/059736.html
>
> Hope this helps.
Thank you, I missed these threads while looking through the archives. I'm still
getting used to the vast amount of knowledge that is available only in Russian,
and sometimes forget to retry the search with a translated query.
So, Igor's main point was that a directive like that allows creating
unmaintainable configurations and will be heavily abused? It is a fair point
and it made me hesitate before submitting the patch. But there are already
roundabout ways of achieving the same and providing an official and
well-documented one may be beneficial.
I also wanted to point out that, unlike the previous requests, we're not
looking for a way to reduce duplication in the configuration. There are
genuine cases, where applying several location configs one by one is the most
optimal way to get a desired behavior. E.g., step-up authentication or reuse of
the result of another access module -- the existing methods of implementing
such configurations are complex and may negatively affect max RPS/request
processing time.
---
It doesn't have to be a redirect either; that was just the most direct
approach. The `error_page ...; return` idiom could work for these scenarios, if
we could have a conditional return-like directive processed at POST_ACCESS or
PRECONTENT. Although it would be less obvious and with its own share of
pitfalls.
location /protected {
...
include regular_error_pages.inc;
error_page 418 = @extra_auth;
recursive_error_pages on;
post_auth_require $not_suspicious $var_from_subrequest ...
error=418; # semantics similar to auth_jwt_require
}
If I failed to convince you on the topic of redirect, would you be open to a
patch with that kind of directive?
_______________________________________________
nginx-devel mailing list -- nginx-devel@nginx.org
To unsubscribe send an email to nginx-devel-le...@nginx.org
