misunderstood regex location

[B.R.]

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

> > > 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 ]
> > > }
>
>
> > The request processing stops on the first matching regex.
>
> Which is ?
>

​Every request is processed through one location block at the same level​.
Said otherwise, every time there is a choice to be made between several
location blocks, only one is picked up and entered. That process is
recursive.

In the provided example, there is only one regex at the root of the tree.
Since the docs I quoted in my last message say that regexes have higher
precedence, then E will be taken over D if both match. The regex inside the
prefix location '/images/' has no impact/use in the current case since it
is on the 2nd level of the tree, not its root, which was being considered.
One step at a time :o)

Since regexes have higher precedence, and since it is prefered to use
prefix locations (because they are more 'natural' and efficient, speaking
about performance), it is then advised either:
- to avoid mixing prefix and regex locations on the same level, thus
encapsulating regex locations inside prefix ones first.
- to use the ^~ operator to force prefix locations being taken over the
regex ones
---
*B. R.*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20140507/47ecda5e/attachment.html>