httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bill Stoddard" <>
Subject Re: related config directives
Date Thu, 20 Dec 2001 21:01:05 GMT

> On Thursday 20 December 2001 12:22 pm, Greg Ames wrote:
> > ...are more painful to deal with than you might think, if the user is
> > allowed to code them in any order.  
> > 
> > I'd like the comparisons between MaxClients and ServerLimit and the
> > equivalent thread directives to be coding order insensitive.  So I
> > created a post-config hook to do the comparing & adjusting.  The code
> > was very simple, but the log messages went to the error log file twice,
> > rather than to the console once which is what people are accustomed to
> > for config errors.
> > 
> > worker already has the same situation with MaxClients and
> > ThreadsPerChild.  It has a clever but kind of scary solution:  a
> > pre-config hook which swaps nodes in the config tree if it doesn't like
> > the order.  Then the comparisons, adjusting, and logging are done when
> > the second directive is parsed.  
> >
> > While I think it's a very cool hack, mucking with the innards of the
> > config tree bothers me some.  config.c could provide an API to do order
> > checking and swapping, but I can't see this as a general solution. 
> > Think about cases where one directive is in container X and the other
> > isn't - yuck!
> This is the point of the config tree, it allows you to modify the config before
> we actually run the configuration, so that you can find these dependancies
> and fix them quickly.  Putting the logic in the directive handlers doesn't
> really work, because you still have an order dependancy.
> Think of it this way, these are good configs:
> MaxClients 500
> ServerLimit 525
> ServerLimit 20
> MaxClients 5
> This is a bad config:
> MaxClients 525
> ServerLimit 500
> Where do you catch it though?  In ServerLimit, then you
> will also catch the second good config above, which is a good config
> If you try to catch it in MaxClients, you will catch the first config above,
> which is a good config.
> The only solution is to choose default values that are invalid, so that you
> can make sure that you always check in the last directive handler, but that
> is incredibly ugly.  We can easily create a function to do the swapping,
> which is more generic, but the swapping is the only 100% correct way
> to do this.
> Ryan

I'm inclined to agree with Ryan. Let's just make a function to do the swapping.


View raw message