httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <>
Subject config handling (was: Re: cvs commit: httpd-2.0/server core.c)
Date Mon, 20 May 2002 21:47:33 GMT
On Sat, May 18, 2002 at 12:32:20PM -0500, William A. Rowe, Jr. wrote:
> Ok, segfault  is gone.  So is some validation that ServerRoot occured in a 
> global
> context.  Actually, that means that LoadModule and others are not tested to be
> in the global context either.

(see further below)

> I'm just getting my head wrapped around cfg parsing, so anyone with a whole
> lot more background here might be able to provide pointers.  Notice that we
> can't defer ServerRoot processing unless we defer LoadModule processing.

EXEC_ON_READ is *ONLY* intended to be used for things like LoadModule.
Essentially, LoadModule needs to be executed right away so that we can
properly *parse* the rest of the file.

Outside of the initial parse into the configuration tree, and whatever is
needed to build that tree, NOTHING should ever be EXEC_ON_READ. I know that
some things have gotten a bit sloppy with that, but I've never had the time
or inclination to go and do a review.

Once you get the tree loaded, then you should be able to simply scan it for
the validation. You should be able to detect an improperly positioned
ServerRoot just by looking at the tree.

Note that the ideal config parse/load looks like:

1) process the config, constructing the tree. invoke any EXEC_ON_READ
   directives, as these are required to complete this step

2) process the tree to find logging directives and execute them
   [ these might be EXEC_ON_READ today, which would be abdness ]

3) process the tree for all the directives, now that logging is available

Note that we really only need to hit the file once to parse the tree. The
logic was never completed for this, however, so we actually read/parse the
tree twice.

> If we REALLY get a better handle on this, I see no reason to maintain the
> test-load then re-load configuration logic.  If we can pre-process what we must
> with EXEC_ON_READ, then open logs and the like, we should be able to
> directly proceed to run_mpm, without dumping it all and reloading.


> On Win32, we load-unload-reload the parent, then load-unload-reload the child
> config.  Losing both redundant unload-load sequences will be a huge win at
> startup.

Yup. If we process the tree in a much smarter fashion, then nothing should
need to be unloaded.


Regarding the first question, about validating ServerRoot. As I mentioned
above, you can go do the validation during the second pass. Of course, that
means that it was a bit "late". It may be possible to build in some flags
that say "this directive can only occur at the top level". When the parser
sees a directive with that flag set, and it isn't at the top level, then it
would simply barf it up.

[ I think the "only at top level" makes a lot more sense than the flags we
  have nowadays. the current flags are a confusing much of where a directive
  can or can't appear; the names are bad, the combinations aren't clear, and
  even the symbols aren't properly namespace (e.g. OR_LIMIT) ]


Greg Stein,

View raw message