<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN">
<html><body style='font-size: 10pt; font-family: Verdana,Geneva,sans-serif'>
<p>OK,</p>
<p>regarding the "fallback" location, this one can be used (empty - shortest match):</p>
<p style="padding-left: 30px;"><span style="font-family: courier new,courier;">location "" {<br /> return 444;<br />}<br /></span></p>
<p>Regards,<br />Serg.</p>
<p>24.08.2022 19:38, Sergey Brester via nginx-devel wrote:</p>
<blockquote type="cite" style="padding-left:5px; border-left:#1010ff 2px solid; margin-left:5px"><!-- html ignored --><!-- head ignored --><!-- meta ignored -->
<p>Hi,</p>
<p>it seems that the question of precedence of non-conditional <em>return</em> directive vs nested <em>location</em>s is not really clear,<br />or rather some constellations (like fallback) are impossible or else the configuration may look weird.<br /><br />For instance:</p>
<p style="padding-left: 30px;"><span style="font-family: courier new,courier;">server {</span><br /><span style="font-family: courier new,courier;"> server_name ...;</span><br /><br /><span style="font-family: courier new,courier;"> location ~ ^/(some-uri|other-uri) {</span><br /><span style="font-family: courier new,courier;"> return 200 ...;</span><br /><span style="font-family: courier new,courier;"> }</span><br /><br /><span style="font-family: courier new,courier;"><span style="font-family: courier new,courier;"> </span># fallback for any not matched uri:<br /> return 444;</span><br /><span style="font-family: courier new,courier;">}</span></p>
<p>will ALWAYS return with 444 for that server no matter whether it matches the location(s) or doesn't.<br />Basically the locations are totally superfluous here (despite specified), considering the return is non-conditional.</p>
<p>Sure, the documentation says "Stops processing and returns the specified <code><em>code</em></code> to a client.",<br />but normally the nested locations (if matched) have always higher precedence over anything else<br />in the parent location.</p>
<p>Furthermore the docu of <a href="http://nginx.org/en/docs/http/ngx_http_rewrite_module.html">ngx_http_rewrite_module</a> says at begin:</p>
<ul class="compact">
<li>the directives of this module specified on the <a href="http://nginx.org/en/docs/http/ngx_http_core_module.html#server">server</a> level are executed sequentially;</li>
<li>repeatedly:
<ul class="compact">
<li>a <a href="http://nginx.org/en/docs/http/ngx_http_core_module.html#location">location</a> is searched based on a request URI;</li>
<li>the directives of this module specified inside the found location are executed sequentially;</li>
</ul>
</li>
</ul>
<p>What is a bit ambiguous. But if it is to understand directly - it is clear that a return directive at server level<br />bypasses all other locations (sequence in current level before its locations).<br />Just it makes hardly possible (up to impossible depending on location tree) to use return directive for a fallback case.</p>
<p>To implement the fallback return, one can surely pack this into a location like:</p>
<p style="padding-left: 30px;"><span style="font-family: courier new,courier;">location ~ .* { return 444; } </span></p>
<div>Just it is a bit ugly in my opinion, let alone it would quasi disallow the usage of longest match prefix locations, <br />because they work only if no match with a regular expression is found (then the configuration of the <br />prefix location remembered earlier is used).</div>
<div> </div>
<div>So I assume:<br /><ol>
<li>either it is a lack of documentation (and it must get a hint about the precedence) <br />and/or still better a description how one could achieve such a "fallback" return (location or whatever).<br />(but do we have at all a possibility to specify such proper fallback location matching at end, <br />if nothing else matched?)<br /><br /></li>
<li>or (improbably) this is a flaw and must be "fixed" or enhanced rather for a non-conditional return case<br />(unsure it wouldn't introduce some compat-issue);</li>
</ol>Any thoughts?</div>
<div> </div>
<div>Regards,<br />Sergey.</div>
<!-- html ignored --><br />
<pre>_______________________________________________
nginx-devel mailing list -- <a href="mailto:nginx-devel@nginx.org">nginx-devel@nginx.org</a>
To unsubscribe send an email to <a href="mailto:nginx-devel-leave@nginx.org">nginx-devel-leave@nginx.org</a>
</pre>
</blockquote>
</body></html>