On Mon, 20 Oct 2008 19:19:58 +0200
Graham Leggett <[EMAIL PROTECTED]> wrote:
> 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.
Indeedie. Not IMHO a good thing, but to change it now would be worse.
> What isn't possible however, is this:
>
> SetEnv WEBAPP app1
> <Location /${WEBAPP}>
> ServerAdmin [EMAIL PROTECTED]
> ... other cool template style stuff ...
> </Location>
Your argument here appears to point towards the functionality
of mod_macro.
> 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.
We have a start on enabling this with the expression parser, which
enables configuration sections to be applied conditionally on an
expression evaluated at runtime. That's work-in-progress and needs
revisiting, but it can use env vars in its expression evaluation,
and templating with them should be a natural future direction.
(and of course, you can always use mod_rewrite).
--
Nick Kew
