IIRC, this is the same as mp1 behavior. mp/apache 1 require a call to set_cgi_env_vars to do this, which both mod_perl and mod_cgi do. calling $r->subprocess_env early was the solution, which made standard variables available early. just going by memory at this point, though :)
I think the real problem is that:
SetHandler perl-script
and:
SetHandler perl-script PerlOptions +SetupEnv
aren't the same, even though the docs advertise them as such. We should probably ammend to doc to say, that:
SetHandler perl-script
sets the env vars, but only before the response phase. Adding an explicit
PerlOptions +SetupEnv
will set them during the very first mod_perl phase whatever it is. So only if there is only a response phase handled by mod_perl, the two are equivalent.
sounds good to me, if by whatever it is you mean header-parser or post-read-request, depending on whether +SetupEnv is inside or outside of a container.
(the next item deals with the fine definition of 'during').
2. If 'PerlOptions +SetupEnv' is set, the %ENV setting happens too early, without giving header_parser handlers to modify the headers.
header-parser was a misnomer in apache 1.3 - the headers are already parsed before the phase runs. has that changed in 2.0? I know you can get to everything early now, especially with input filters, but I thought the request phases stayed the same.
Yup, headers are parsed in one of the core filters. Though this phase is normally where you manipulate $r->headers_in, no?
So we should probably nominate this phase as special with regards to +SetupEnv. For example:
PerlOptions +SetupEnv
sets the env variables at the end of the headerparser phase, so they become available only during the access phase and up.
I'm thinking this is the way to go. except that it has to be the post-read-request phase if +SetupEnv is seen within a container directive.
If env vars are wanted earlier $r->subprocess_env is to be called explicitly.
yup.
but what exactly is the complaint? you want to manipulate the Cookie header before it gets to %ENV via a header-parser handler? instead of HOOK_LAST, we could always register two hooks - the PerlHeaderParserHandler hook as HOOK_REALLY_FIRST and then add modperl_env_request_populate logic as a separate HOOK_FIRST handler :)
Since PerlHeaderParserHandler is RUN_ALL, this should work, but why HOOK_FIRST and not HOOK_REALLY_LAST for modperl_env_request_populate logic?
well, HOOK_REALLY_FIRST and HOOK_FIRST was just a thought (and it was late :). keeping header-parser/post-read-request as HOOK_FIRST and making SetupEnv HOOK_LAST is probably better.
Though it will always add a phase to the mod_perl cycle, even if mod_perl is not used at all.
I thought there was some optimizations that kept phases from running where no perl hook was registered. couldn't we do the same - don't run the new hook unless +SetupEnv is found?
Currently the trick is done by doing this one from the modperl_callback:
case MP_HANDLER_TYPE_PER_DIR: case MP_HANDLER_TYPE_PER_SRV: modperl_handler_make_args(aTHX_ &av_args, "Apache::RequestRec", r, NULL);
/* only happens once per-request */ if (MpDirSETUP_ENV(dcfg)) { modperl_env_request_populate(aTHX_ r); } break;
So it always run before the very first mod_perl handler whatever it's.
If my suggestion above applies, we could rewrite this code to do the same thing if the phase is access or higher. But add the same code after the handler is executed, and only if the phase is 'headerparser' run this code. In pseudo code this will look as:
set_env if phase > header_parser run_handler set_env if phase == header_parser
So a custom header_parser will be able to adjust the headers before they are converted into %ENV.
I think we need separate per-dir and per-server logic to cover whether the directive is inside or outside of a container, but yeah, something like that.
--Geoff
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
