Problem with inheriting fastcgi params

[Cliff Wells]

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