Hello!
On Mon, Feb 17, 2014 at 09:26:56PM +0000, Brian Hill wrote:
> So there is no precedence given to nested regex locations at
> all? What value does nesting provide then?
Nesting is to do thins like this:
location / {
# something generic stuff here
location ~ \.jpg$ {
expires 1w;
}
}
location /app1/ {
# something special for app1 here, e.g.
# access control
auth_basic ...
access ...
location = /app1/login {
# something special for /app1/login,
# eveything from /app1/ is inherited
proxy_pass ...
}
location ~ \.jpg$ {
expires 1m;
}
}
location /app2/ {
# separate configuration for app2 here,
# changes in /app1/ doesn't affect it
...
location ~ \.jpg$ {
expires 1y;
}
}
That is, it allows to write scalable configurations using prefix
locations. With such approach, you can edit anything under /app1/
without being concerned how it will affect things for /app2/.
It also allows to use inheritance to write shorter configurations,
and allows to isolate regexp locations within prefix ones.
> This seems like it should be a fairly simple thing to do.
> Image/CSS requests to some folders get handled one way, and
> image/CSS requests to all other folders get handled another way.
See above for an example.
(I personally recommend using separate folder for images/css to be
able to use prefix locations instead of regexp ones. But it
should be relatively safe this way as well - as long as they are
isolated in other locations. On of the big problems with regexp
locations is that ofthen they are matched when people don't expect
them to be matched, and isolating regexp locations within prefix
ones minimizes this negative impact.)
> This is an experimental pilot project for a datacenter
> conversion, and the use of regex to specify both the file types
> and folder names is mandatory. The project this pilot is for
> will eventually require more than 50 server blocks with hundreds
> of locations in each block if regex cannot be used. It would be
> an unmaintainable mess without regex.
Your problem is that you are trying to mix regex locations
and prefix locations without understanding how they work, and to
make things even harder you add nested locations to the mix.
Instead, just stop doing things harder. Simplify things.
Most recommended simplification is to avoid regexp location. Note
that many location blocks isn't necessary bad thing. Sometimes
it's much easier to handle hundreds of prefix location blocks than
dozens of regexp locations. Configuration with prefix locations
are much easier to maintain.
If you can't avoid regexp locations for some external reason, it
would be trivial to write a configuration which does what you want
with regexp locations as well:
location / {
...
}
location ~ ^/app1/ {
...
location ~ \.jpg$ {
expires 1m;
}
}
location ~ ^/app2/ {
...
location ~ \.jpg$ {
expires 1y;
}
}
location ~ \.jpg$ {
expires 1w;
}
Though such configurations are usually much harder to maintain in
contrast to ones based on prefix locations.
--
Maxim Dounin
http://nginx.org/
_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx
