misunderstood regex location

[B.R.]

On Tue, May 6, 2014 at 5:03 PM, dcaillibaud <nginx-forum at nginx.us> wrote:

> I understand my mistake, thanks to both of you.
>
> May I suggest to insist on this in
> http://nginx.org/en/docs/http/ngx_http_core_module.html#location, with a
> remark on the fact that ^~ is not usable with a regex, for example with
>
> syntax:
> location [ = | ^~ ] uri { ... }
> location ~ | ~*  regexUri { ... }
> location @name { ... }
>
> and adding there Igor advice (repeated many times in this forum like in
> http://forum.nginx.org/read.php?2,247529,247718 or
> http://forum.nginx.org/read.php?2,174517,174534#msg-174534), that it's a
> better practice to have a prefix location list at first level then put
> regex
> location within
>

​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.
A 'best practice/performance enhancement' page could host it though.

That wriktten, I think that yes, the docs could be clearer, by inserting:
"If the longest matching prefix location has the “^~” modifier then regular
expressions are not checked. "
inside the third para​graph, which takes the process step-by-step but is
incomplete (one could understand every request processes regexes).
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.



>
> Reviewing all my server definitions, I'm starting to imagine what a
> nightmare could be, with on the first level a mix of standard prefix
> location, ^~ and ~ ^/ ;-)
>
> I was also wondering wich has precedence for /images/foo.jpeg in these
> case,
>
>
> 1) (I guess D, because ^/ before prefix shortcut regex)
>

> location ^~ /images/ {
>     location ~* \.(gif|jpg|jpeg)$ {
>       [ configuration D ]
>     }
> }
>
> location ~* \.(gif|jpg|jpeg)$ {
>     [ configuration E ]
> }
>

​​Right​. That is however exactly the example provided by the docs.
"If the longest matching prefix location has the “^~” modifier then regular
expressions are not checked."​
The regex is not even checked against the input request string.


> 2) (I guess E but I'm not so sure), this can also be a pitfall example (how
> complicating things can lead to unexpected behaviour)
>
> location /images/ {
>     location ~* \.(gif|jpg|jpeg)$ {
>       [ configuration D ]
>     }
> }
>
> location ~* \.(gif|jpg|jpeg)$ {
>     [ configuration E ]
> }
>

"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."
​The prefix string matches, it is remembered, but then the regex is checked
and also matches.
"The search of regular expressions terminates on the first match, and the
corresponding configuration is used."
The request processing stops on the first matching regex.


> 2bis) this makes 2) understandable (more predictable)
>
> location /images/ {
>     location ~* \.(gif|jpg|jpeg)$ {
>       [ configuration D ]
>     }
>     location ~* \.svg$ {
>       [ configuration D2 ]
>     }
> }
>
> location / {
>   location ~* \.(gif|jpg|jpeg|svg|pdf)$ {
>       // static stuff not in /images/
>       [ configuration E ]
>   }
> }
>

​Right IMHO.
---
*B. R.*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20140506/592246f0/attachment.html>