The location directive

[Maxim Dounin]

Hello!

On Fri, Apr 08, 2011 at 03:08:44PM +0200, Thomas Love wrote:

> On 8 April 2011 04:32, Maxim Dounin <mdounin at mdounin.ru> wrote:
> 
> There were lots of such discussions, and the only expected answer
> > to all proposals to add global/continue/whatever locations which
> > alter configuration is: no.
> >
> > The reason is simple: with large config it's practically
> > impossible to find out how requests will be processed when
> > such "global" locations are present.
> 
> 
> I should have been clear -- global/continue/whatever are not the same thing.
> A "continue" location is tested in the normal order. This means there's a
> possibility it's _not_  processed even if it matches, if it comes after a
> normal match-and-break location in nginx's testing order.
>
> Assuming you meant what I did by "continue", I'm not sure whether you are
> saying simply that it's difficult for users to understand such configs, or

It's mostly impossible to understand and (more importantly) 
correctly modify such configs once they grow large enough.

> whether you're saying the processing actually is undefined.

Obviously you may always define how conflicts like

    location / {
        expires 1d;
    }

    theoretical continue location ~ \.jpg$ {
        expires max;
    }

are resolved, e.g. last one wins.  But it adds another layer of 
complexity.  And one day you'll find yourself trying to set 
"expires epoch;" for your monitoring pages - just to find out that 
it's either not set for generated images if you use something like

    location /monitoring/ {
        expires epoch;
    }

or php scripts isn't executed if you disable "continue locations" 
via explicit stop, i.e.

    location ^~ /monitoring/ {
        ...
    }

(not even talking about that you actually need another explicit 
stop, as you may still want regexp locations to be processed).

> If it's the former, then, is it not the case that:
> 
> a) (likely very many) large configs wouldn't be so large if they used
> "continue" locations

They will become large eventually anyway.  Configs grow over time, 
it's normal and perfectly understandable.  The idea is to encourage 
aproach which is scalable, i.e. will still allow to understand and 
modify config once it has become big enough.

> b) the cheapest alternative is nested locations, which are themselves
> difficult to understand, and

Not really.  You have largely isolated chunk of config which 
fully defines how requests are processed.  This is easy enough and 
scales well.

> c) existing users need not implement it

The problem is that bad written configs is something we all have 
to deal on a regular basis - even if we haven't wrote them.

We've all seen configuration hell happening in Apache configs, and 
Igor tried hard to not allow this in nginx keeping complexity as 
low as possible.  Sometimes this comes with cost (i.e. you have to 
duplicate some configs) - but it's well understood and actually 
reduces costs in long run.

> The idea is to simplify the configs of new and ordinary users, and to
> provide a compact alternative to common nesting motifs.
> 
> If on the other hand you are saying that there are cases where processing
> somehow becomes undefined when using a "continue" location, can you provide
> an example (which does not occur for an equivalent nested directive)?
> 
> Thomas

Maxim Dounin