> Can you please remind me what was the mp1 behavior on that? We need to
> match it. Things are complicated in mp2, because the C environ struct is
> detached from perl's %ENV, so there is a lot of extra work to do to
> think %ENV and $r->subprocess_env
as I said in another response, IIRC in mp1 %ENV was not tied to the
subprocess_env table - you could populate $r->subprocess_env all day, but it
wouldn't make it to %ENV until ap_add_cgi_vars was called. and
ap_add_cgi_vars was only called 1) once per-request, or 2) if
$r->subprocess_env was called in a void context.
the once per-request appears to happen on the first entry into a directory
if(r->per_dir_config)
perl_per_request_init(r);
which is different than mp2:
case MP_HANDLER_TYPE_PER_DIR:
case MP_HANDLER_TYPE_PER_SRV:
...
/* only happens once per-request */
if (MpDirSETUP_ENV(dcfg)) {
modperl_env_request_populate(aTHX_ r);
}
>> {
>> if (GIMME_V == G_VOID) {
>> + MP_dRCFG;
>> + MpReqSETUP_ENV_Off(rcfg);
>> modperl_env_request_populate(aTHX_ r);
>> }
this is rquired to maintain mp1 compat, if we're intersted in that.
>> + # make sure that registry scripts can see all of subprocess_env
>> in %ENV
>> + $r->subprocess_env;
>> +
>
>
> This is ain't right, as it ignores the user's setting of whether to load
> env vars or not via:
>
> PerlOptions [+-]SetupEnv and SetHandler (modperl|perl-script)
yes, you're right.
not sure what to do about this, then. looks like both mp1 and mp2 suffer
from the same problem - add to $r->subprocess_env after the call to
ap_add_cgi_vars and Registry doesn't see stuff in %ENV. it's just that the
call is happening at different times between the two.
--Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
