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