Stas Bekman wrote:
Anybody? This was first posted 6 months ago. I'm reposting with an updated patch.
The current modperl-2.0 cvs has two problems with setting %ENV:
1. If PerlOptions +SetupEnv is not set, it sets the env too late (only for the 'perl-script' response handlers). pre-response handlers don't get the environment. So things like cookie based auth don't work out of box (need mangling with $r->subprocess_env).
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.
(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. If env vars are wanted earlier $r->subprocess_env is to be called explicitly.
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?
Though it will always add a phase to the mod_perl cycle, even if mod_perl is not used at all.
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.
__________________________________________________________________ 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]
