Welcome! Log In Create A New Profile


RE: [PATCH] HTTP: add internal_redirect directive.

Aleksei Bavshin via nginx-devel
November 30, 2022 06:36PM

> > 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
Subject Author Views Posted

[PATCH] HTTP: add internal_redirect directive. Attachments

Aleksei Bavshin via nginx-devel 304 November 17, 2022 06:26PM

Re: [PATCH] HTTP: add internal_redirect directive.

Maxim Dounin 45 November 17, 2022 11:24PM

RE: [PATCH] HTTP: add internal_redirect directive.

Aleksei Bavshin via nginx-devel 39 November 30, 2022 06:36PM

Sorry, you do not have permission to post/reply in this forum.

Online Users

Guests: 85
Record Number of Users: 6 on February 13, 2018
Record Number of Guests: 421 on December 02, 2018
Powered by nginx      Powered by FreeBSD      PHP Powered      Powered by MariaDB      ipv6 ready