> we still have a problem, which existed before the last env handling revamp.
>
> I think modules/cgi should work with this patch:
>
> Index: t/response/TestModules/cgi.pm
> ===================================================================
> RCS file: /home/cvs/modperl-2.0/t/response/TestModules/cgi.pm,v
> retrieving revision 1.11
> diff -u -r1.11 cgi.pm
> --- t/response/TestModules/cgi.pm 22 May 2002 18:53:33 -0000
> 1.11
> +++ t/response/TestModules/cgi.pm 14 Feb 2004 04:51:53 -0000
> @@ -55,4 +55,4 @@
> 1;
> __END__
> SetHandler perl-script
> -
> +PerlOptions -SetupEnv
>
> and it doesn't. $ENV{GATEWAY_INTERFACE} set at the boot time is later
> lost (whereas $ENV{MOD_PERL} survives). I suppose this has to do with
> the code that removes the values from %ENV at the end of the request, so
> they won't persist for the next request. So it should really do
> localizing and not set/unset.
yeah, I think I see what you mean, but I think where it needs to live is
dependent upon if/when we want it populated.
my thought is still that %ENV information like this is only relevant during
content-generation: you're obviously using mod_perl if you're running a
handler for any other phase. furthermore, I think it probably needs to
respect the -SetupEnv speedup: -SetupEnv means that you don't care about
CGI-style things, which by definition means that you don't care what the
GATEWAY_INTERFACE setting is, since you don't have stuff like
$ENV{REMOTE_USER} anyway. after all, GATEWAY_INTERFACE is set up in
ap_add_cgi_vars, and with -SetupEnv we're specifically supressing that call.
so I think it's ok that with -SetupEnv $ENV{MOD_PERL} is the only thing that
survivies. at least this late at night :)
--Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
