More on configuration parsing

[Rodent of Unusual Size <co...@decus.org>]

    One of the recurrent themese wrt vhosts seems to have been the issue
    of requests going to unexpected places.  What do those of you
    working on a new/improved grammar think of this:

    Modularise/abstract the config parsing stuff enough so that a
    separate utility can be supplied in support/ that will scan the
    config files and point up any errors/occlusions/et cetera?  So far,
    the tendency to discover config errors has been to reload the server
    and have it croak if there's badness; methinks the ability to vet
    the files separately would be a goodness..

    #ken    :-)}

Re: More on configuration parsing

[Dean Gaudet <dg...@arctic.org>]

Both Roy's and my suggestions (they're essentially the same) make it
really explicit which vhost is handling what. 

I wonder if we could just add a "-c" command line option which does the
first parse of the config file and then exits.  This won't detect log
opening errors, but we should make those robust (non-exiting) cases if
they aren't already. 

Dean

On Mon, 16 Jun 1997, Rodent of Unusual Size wrote:

>     One of the recurrent themese wrt vhosts seems to have been the issue
>     of requests going to unexpected places.  What do those of you
>     working on a new/improved grammar think of this:
> 
>     Modularise/abstract the config parsing stuff enough so that a
>     separate utility can be supplied in support/ that will scan the
>     config files and point up any errors/occlusions/et cetera?  So far,
>     the tendency to discover config errors has been to reload the server
>     and have it croak if there's badness; methinks the ability to vet
>     the files separately would be a goodness..
> 
>     #ken    :-)}
> 

Re: More on configuration parsing

[Marc Slemko <ma...@worldgate.com>]

On Mon, 16 Jun 1997, Rodent of Unusual Size wrote:

>     One of the recurrent themese wrt vhosts seems to have been the issue
>     of requests going to unexpected places.  What do those of you
>     working on a new/improved grammar think of this:
> 
>     Modularise/abstract the config parsing stuff enough so that a
>     separate utility can be supplied in support/ that will scan the
>     config files and point up any errors/occlusions/et cetera?  So far,
>     the tendency to discover config errors has been to reload the server
>     and have it croak if there's badness; methinks the ability to vet
>     the files separately would be a goodness..

I am wondering if it isn't a better idea to have a way to signal the
running server to recheck the config files.  That way you avoid the hassle
of running the code from a seperate program and setting up all the things
you need to do so.

Something like ctlinnd checkfile wouldn't hurt.  In fact, adding a
ctlapache that can do things like restart, print stats, nuke Microsoft,
etc. may be a cool idea.  But not a basic one to be worrying about other
than making things so it can fit in.