On Oct 20, 2008, at 1:19 PM, Graham Leggett wrote:
Hi all,
I have just been picking apart the way that environment variables
are handled at config time within httpd, and there seems to be some
overloading on concepts that has caused some confusion.
There are two environments within httpd, the first is the read only
system environment that is read using getenv(), the second is the
server->vars table that is read/write using mod_env and friends.
A recent addition was made (it's on trunk and 2.2) that allows httpd
to include system variables in config directives, like this:
DocumentRoot ${DOCUMENT_ROOT}
The system environment variable DOCUMENT_ROOT is parsed and placed
in the config line, so far so good.
What isn't possible however, is this:
SetEnv WEBAPP app1
<Location /${WEBAPP}>
ServerAdmin [EMAIL PROTECTED]
... other cool template style stuff ...
</Location>
In this case, SetEnv sets a variable within mod_env's server->vars,
but this is ignored by ap_resolve_env, and so doesn't work as the
user might expect it to.
Zooming in some more on the way mod_env's environment works.
The mod_env environment in server->vars starts off empty, and then
is populated by explicit allocation (SetEnv), or by copying the
value from a system environment variable to a mod_env environment
variable (PassEnv).
Would it make sense when parsing the config to try and insert
mod_env's server->vars variables first, and then if not present,
fall back to (the current behaviour of) looking at the system
environment?
This will make some interesting templating options possible, and
will probably make lives easier for people doing mass hosting.
But isn't that 2 different things? Do we really want WEBAPP to be in
the running process env space and contaminate that? If people want
macros
I tend to point them to mod_macro, which I like quite a bit...
