1) copy environ to %ENV and detach at the very beginning.
now if a vhost with its own interpreter changes %ENV it won't affect the base server.
Each vhost will be able to have its own <Perl> sections and/or PerlRequire, independent from the main server config, right?
Oops, this is a problem. No, only vhosts with their own perl interpreter can have a different %ENV.
In order to make those things independent per vhost,
Perl(Pass|Set)Env will affect only the right vhost/base, but any manipulation in the perl code will affect them all, since there is only one %ENV.
if you set $ENV{MYFOO} at startup it won't stay around, unless you explicitly asked to post it forward. What I don't like about it is that $ENV{PATH} is set in the perl code (e.g. startup), but needs to be marked in httpd.conf, that's ugly.
Yes, if you assume that setting something in %ENV at startup implies the equivalent of PerlPassEnv, you shouldn't need to explicitly do the PerlPassEnv for it. I think 99% of the time I've touched %ENV in startup code, it was something that needed to be passed along, so it would be nice if that happened automatically. If you needed something in %ENV at startup but did *not* want it passed along, either do it in a localized %ENV, or delete from %ENV after use in your startup code.
right, that's the idea
How about this solution:
[... lots of steps ...]
How does that sound?
Sounds good to me - I think you're basically getting at:
- Startup code %ENV initially contains copy of original environ from shell - %ENV passed along to workers will contain only those keys that are: 1) Specified in PerlPassEnv or PerlSetEnv directives, or 2) Set/modified in unlocalized %ENV by startup code
That's correct.
In fact PerlPassEnv could be emulated from perl by:
$ENV{FOO} = $ENV{FOO};since it performs a set operation.
The only remaining problem that I see is PerlSetEnv, if there is a PerlRequire'd file and PerlSetEnv, and both try to set/modify the same entry, it's not the order in httpd.conf that will determine which is the latest value, but the order of evalution of PerlRequire vs. PerlSetEnv.
Another thing to ensure is that PerlSetEnv is run before PerlRequire, since it's possible that the file will want to refer to the ENV var set by PerlSetEnv.
I don't think that is a problem, if the precedence rule is made clear that all PerlSetEnv are always evaluated first regardless of position. If it worked that way, you would still be able to have a PerlRequire or <Perl> section that relied on the setting of a PerlSetEnv, e.g. these would do the same thing:
PerlSetEnv FOO 1 PerlRequire my::Module (internally uses $ENV{FOO})
or (less obvious)
PerlRequire my::Module (internally uses $ENV{FOO}) PerlSetEnv FOO 1
What you would *not* be able to do is this:
PerlRequire my::Module (internally sets $ENV{FOO}) PerlSetEnv FOO 1 (to override the module setting)
But that is ok because instead you could do:
PerlRequire my::Module (internally sets $ENV{FOO}) <Perl> $ENV{FOO} = 1; (to override the module setting) </Perl>
It is sounding like the rules would be:
1) Evaluate all PerlSetEnv first, in order of occurrence 2) Evaluate all PerlRequire and <Perl> sections in main server config, in order of occurrence 3) Evaluate all PerlRequire and <Perl> sections in each vhost, in order of occurrence (each vhost could have a different %ENV at this point) 4) For each interpreter, clean up %ENV (according to delete list rules you described) before passing to workers
Is this what you mean?
As you have raised the problem of vhosts, this is probably not a way to go. I think what we could do is having PerlSetEnv and PerlPassEnv have no effect at startup phase at all, so if you need to manipulate any env vars at startup, you just do it from Perl. when you are done with all the manipulations in perl and the post_config phase is over, we can now apply
PerlSetEnv and PerlPassEnv, the former will override any settings done from Perl until this moment. And in which case things will work correctly across vhosts. i.e. you will be able to set two different values for the same key in two different hosts (but only for post_config phases). Is there a problem with this approach?
-- __________________________________________________________________ Stas Bekman JAm_pH ------> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
