Precedence return directive and nested locations

[Dipl. Ing. Sergey Brester]

OK, 

regarding the "fallback" location, this one can be used (empty -
shortest match): 

location "" {
 return 444;
}

Regards,
Serg. 

24.08.2022 19:38, Sergey Brester via nginx-devel wrote: 

> 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. 
> 
> _______________________________________________
> nginx-devel mailing list -- nginx-devel at nginx.org
> To unsubscribe send an email to nginx-devel-leave at nginx.org
 

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/8b596371/attachment.htm>