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.
right. So should we talk about the init phase, and let the reader figure out the rest? Or should we be explicit about it?
(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.
ok, so it's a bit more complex, but the logic is the same.
So we want to tell users to use PerlInitHandler to adjust headers ;)
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?
Not in this case. The hooks registration is done globally, of course we immediately return if there is nothing to do. So there is little overhead.
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.
sounds good. I need to write some tests that fail first ;)
__________________________________________________________________ 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]
