Welcome! Log In Create A New Profile

Advanced

Precedence return directive and nested locations

Dipl. Ing. Sergey Brester via nginx-devel
August 24, 2022 01:40PM
Hi,

it seems that the question of precedence of non-conditional _return_
directive vs nested _location_s is not really clear,
or rather some constellations (like fallback) are impossible or else the
configuration may look weird.

For instance:

server {
server_name ...;

location ~ ^/(some-uri|other-uri) {
return 200 ...;
}

# fallback for any not matched uri:
return 444;
}

will ALWAYS return with 444 for that server no matter whether it matches
the location(s) or doesn't.
Basically the locations are totally superfluous here (despite
specified), considering the return is non-conditional.

Sure, the documentation says "Stops processing and returns the specified
_code_ to a client.",
but normally the nested locations (if matched) have always higher
precedence over anything else
in the parent location.

Furthermore the docu of ngx_http_rewrite_module [1] says at begin:

* the directives of this module specified on the server [2] level are
executed sequentially;

* repeatedly:

* a location [3] is searched based on a request URI;
* the directives of this module specified inside the found location
are executed sequentially;

What is a bit ambiguous. But if it is to understand directly - it is
clear that a return directive at server level
bypasses all other locations (sequence in current level before its
locations).
Just it makes hardly possible (up to impossible depending on location
tree) to use return directive for a fallback case.

To implement the fallback return, one can surely pack this into a
location like:

location ~ .* { return 444; }
Just it is a bit ugly in my opinion, let alone it would quasi disallow
the usage of longest match prefix locations,
because they work only if no match with a regular expression is found
(then the configuration of the
prefix location remembered earlier is used).

So I assume:

* either it is a lack of documentation (and it must get a hint about
the precedence)
and/or still better a description how one could achieve such a
"fallback" return (location or whatever).
(but do we have at all a possibility to specify such proper fallback
location matching at end,
if nothing else matched?)

* or (improbably) this is a flaw and must be "fixed" or enhanced rather
for a non-conditional return case
(unsure it wouldn't introduce some compat-issue);

Any thoughts?

Regards,
Sergey.

Links:
------
[1] http://nginx.org/en/docs/http/ngx_http_rewrite_module.html
[2] http://nginx.org/en/docs/http/ngx_http_core_module.html#server
[3] http://nginx.org/en/docs/http/ngx_http_core_module.html#location
_______________________________________________
nginx-devel mailing list -- nginx-devel@nginx.org
To unsubscribe send an email to nginx-devel-leave@nginx.org
Subject Author Views Posted

Precedence return directive and nested locations

Dipl. Ing. Sergey Brester via nginx-devel 173 August 24, 2022 01:40PM

Re: Precedence return directive and nested locations

Dipl. Ing. Sergey Brester via nginx-devel 67 August 24, 2022 02:00PM

Re: Precedence return directive and nested locations

Maxim Dounin 56 August 24, 2022 04:38PM



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

Online Users

Guests: 87
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