Proxy pass location inheritance

Maxim Dounin mdounin at mdounin.ru
Tue Feb 18 12:12:55 UTC 2014


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/



More information about the nginx mailing list