On Sat, 2009-06-06 at 06:03 +0400, Maxim Dounin wrote:
> Hello!
>
> On Fri, Jun 05, 2009 at 02:12:50PM -0700, Cliff Wells wrote:
>
> > On Sat, 2009-06-06 at 00:17 +0400, Maxim Dounin wrote:
> > > It's expected and documented behaviour. All array-type settings
> > > behave like this: they are inherited from upper levels only if
> > > none defined at this particular level.
> >
> > Interesting. I was aware of the limitation Michael mentions, but
> > didn't realize this was the particular mechanism. So I assume that
> > "array-type" is indicated by the variable prefixes, i.e. fastcgi_*,
> > proxy_*, etc?
>
> Yes, it's generic mechanism. No, "array-type" isn't indicated by
> anything. It's just includes any directives that may be repeated
> and effectively append items to some array internally. This
> includes access_log, error_log, fastcgi_param, proxy_set_header,
> ssi_types (and other *_types as well), access rules (allow + deny)
> and so on.
>
> From user-level point of view this behaviour is part of config
> syntax. If it wasn't working this way - some other syntax would be
> required to make it possible to clear inherited values.
>
> From developer point of view - it's just easy. Inheritance
> involve just copy of array pointer from upper level if there are
> no directives defined at particular level.

I guess what I'm looking for (from a user point of view), is how to
describe why (and more importantly when) setting one variable affects
others. If there were an obvious pattern in naming conventions (or
even a simple, externally maintained list in the wiki) of array
variables I think it would make this behavior less surprising. I write
a bit of code myself, so your description makes perfect sense as to how
things work internally, but this doesn't necessarily lend itself (from a
user perspective) to predicting *which* variables might fall into this
category.


Cliff

--
http://www.google.com/search?q=vonage+sucks