Brian Becker wrote:
> This issue has been discussed on the MP mailing list and I have
> developed an Apache::Test that shows the problem (probably not the best
> test ever written). The scenario is that a request to one folder (A)
> that does a PerlSetEnv with an AuthenHandler to an html page when
> another request comes in on the same process to a different folder (B)
> the variable set with PerlSetEnv for folder A still exists…see
> diffs/files below
you rock!
> Possible Fix (there may be a better way but this passed all tests):
ah, a patch speaks 1000 words :)
> /* undo changes to %ENV caused by +SetupEnv, perl-script, or
> * $r->subprocess_env, so the values won't persist */
> - if (MpReqSETUP_ENV(rcfg)) {
> + if (MpReqSETUP_ENV(rcfg) || MpReqPERL_SET_ENV_SRV(rcfg) ||
> MpReqPERL_SET_ENV_DIR(rcfg))
ok. I think a better way would be to set MpReqSETUP_ENV_On(rcfg) in
places that twiddle %ENV rather than look here for multiple flags. the
basic idea is that we use SETUP_ENV to mean "mod_perl has messed with
%ENV - please set it back" which is why the unpopulate function checks
for it.
but in either case the fix should be minimal, and with a test case so is
our work :)
I'll try to get around to integrating this all during yapc next week,
including reworking the test a bit. but I'll post a patch in any case
so you can verify that all is well.
thanks for taking the time to really contribute back - we all appreciate it.
--Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
