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-leave@nginx.org