Precedence return directive and nested locations

[Dipl. Ing. Sergey Brester]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-devel/attachments/20220824/bce1577c/attachment.htm>