Hello!

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

> On 8 April 2011 04:32, Maxim Dounin <mdounin@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

_______________________________________________
nginx mailing list
nginx@nginx.org
http://nginx.org/mailman/listinfo/nginx