<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, May 6, 2014 at 5:03 PM, dcaillibaud <span dir="ltr"><<a href="mailto:nginx-forum@nginx.us" target="_blank">nginx-forum@nginx.us</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I understand my mistake, thanks to both of you.<br>
<br>
May I suggest to insist on this in<br>
<a href="http://nginx.org/en/docs/http/ngx_http_core_module.html#location" target="_blank">http://nginx.org/en/docs/http/ngx_http_core_module.html#location</a>, with a<br>
remark on the fact that ^~ is not usable with a regex, for example with<br>
<br>
syntax:<br>
location [ = | ^~ ] uri { ... }<br>
location ~ | ~* regexUri { ... }<br>
location @name { ... }<br>
<br>
and adding there Igor advice (repeated many times in this forum like in<br>
<a href="http://forum.nginx.org/read.php?2,247529,247718" target="_blank">http://forum.nginx.org/read.php?2,247529,247718</a> or<br>
<a href="http://forum.nginx.org/read.php?2,174517,174534#msg-174534" target="_blank">http://forum.nginx.org/read.php?2,174517,174534#msg-174534</a>), that it's a<br>
better practice to have a prefix location list at first level then put regex<br>
location within<br></blockquote><div><br><div class="gmail_default" style="font-size:small;color:rgb(51,51,153)">The $docs must stay as concise as possible, so I do not think Igorf advice should be there, even irf it is very interesting information, should be there.<br>
</div><div class="gmail_default" style="font-size:small;color:rgb(51,51,153)">A 'best practice/performance enhancement' page could host it though.<br></div><div class="gmail_default" style="font-size:small;color:rgb(51,51,153)">
<br></div><div class="gmail_default" style="font-size:small;color:rgb(51,51,153)">That wriktten, I think that yes, the docs could be clearer, by inserting:<br>"If the longest matching prefix location has the “<code>^~</code>” modifier
then regular expressions are not checked.
"<br></div><div class="gmail_default" style="font-size:small;color:rgb(51,51,153)">inside the third paragraph, which takes the process step-by-step but is incomplete (one could understand every request processes regexes).<br>
</div><div class="gmail_default" style="font-size:small;color:rgb(51,51,153)">This sentence, isolated at the end of the section, produces a leap backward in the reasoning flow and loses the reader in his attempt to understand how things work. Definitely not user-friendly.<br>
</div><br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Reviewing all my server definitions, I'm starting to imagine what a<br>
nightmare could be, with on the first level a mix of standard prefix<br>
location, ^~ and ~ ^/ ;-)<br>
<br>
I was also wondering wich has precedence for /images/foo.jpeg in these case,<br>
<br>
<br>
1) (I guess D, because ^/ before prefix shortcut regex)<br></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
location ^~ /images/ {<br>
location ~* \.(gif|jpg|jpeg)$ {<br>
[ configuration D ]<br>
}<br>
}<br>
<br>
location ~* \.(gif|jpg|jpeg)$ {<br>
[ configuration E ]<br>
}<br></blockquote><div><div class="gmail_default" style="font-size:small;color:rgb(51,51,153)"><br>Right. That is however exactly the example provided by the docs.<br>"If the longest matching prefix location has the “<code>^~</code>” modifier
then regular expressions are not checked."<br></div><div class="gmail_default" style="font-size:small;color:rgb(51,51,153)">The regex is not even checked against the input request string.<br></div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
2) (I guess E but I'm not so sure), this can also be a pitfall example (how<br>
complicating things can lead to unexpected behaviour)<br>
<br>
location /images/ {<br>
location ~* \.(gif|jpg|jpeg)$ {<br>
[ configuration D ]<br>
}<br>
}<br>
<br>
location ~* \.(gif|jpg|jpeg)$ {<br>
[ configuration E ]<br>
}<br></blockquote><div><br><div class="gmail_default" style="font-size:small;color:rgb(51,51,153)">"Among [prefix locations], the location with the longest matching
prefix is selected and remembered.
Then regular expressions are checked, in the order of their appearance
in the configuration file."<br>The prefix string matches, it is remembered, but then the regex is checked and also matches.<br>"The search of regular expressions terminates on the first match,
and the corresponding configuration is used."</div><div class="gmail_default" style="font-size:small;color:rgb(51,51,153)">The request processing stops on the first matching regex.</div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
2bis) this makes 2) understandable (more predictable)<br>
<br>
location /images/ {<br>
location ~* \.(gif|jpg|jpeg)$ {<br>
[ configuration D ]<br>
}<br>
location ~* \.svg$ {<br>
[ configuration D2 ]<br>
}<br>
}<br>
<br>
location / {<br>
location ~* \.(gif|jpg|jpeg|svg|pdf)$ {<br>
// static stuff not in /images/<br>
[ configuration E ]<br>
}<br>
}<br></blockquote><div><br><div class="gmail_default" style="font-size:small;color:rgb(51,51,153);display:inline">Right IMHO.<br></div></div></div><font size="1"><span style="color:rgb(102,102,102)">---<br></span><b><span style="color:rgb(102,102,102)">B. R.</span></b><span style="color:rgb(102,102,102)"></span></font>
</div></div>