You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@perl.apache.org by Stas Bekman <st...@stason.org> on 2004/02/14 05:55:08 UTC
Re: cvs commit: modperl-2.0/src/modules/perl modperl_env.c
stas@apache.org wrote:
> stas 2004/02/13 20:50:32
>
> Modified: src/modules/perl modperl_env.c
> Log:
> move modperl_env_default_populate to where it was before (after
> modperl_env_table_populate), so that GATEWAY_INTERFACE will be
> CGI-Perl/1.1 and not CGI/1.1.
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.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: cvs commit: modperl-2.0/src/modules/perl modperl_env.c
Posted by Stas Bekman <st...@stason.org>.
Geoffrey Young wrote:
>>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 :)
Well, GATEWAY_INTERFACE wasn't really for CGI env vars, but to test for
mod_perl, before $ENV{MOD_PERL} was introduced. and I believe there is still
some sw that uses the former, instead the latter. It's already a conditional
compile time setting. So I'm fine with your logic. But if we keep it, we need
to update the docs to reflect that change.
May be we should swap MP_COMPAT_1X to be undef by default, and only enabled
explicitly during the build. Or, may be we should do that only when we release
2.0.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: cvs commit: modperl-2.0/src/modules/perl modperl_env.c
Posted by Stefan Traby <st...@hello-penguin.com>.
On Sat, Feb 14, 2004 at 12:15:23AM -0500, Geoffrey Young wrote:
> 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 :)
As long as "-SetupEnv" does not override a "SSLOptions +StdEnvVars"
it's only important at all for people who seriously think that a real
"-SetupEnv speedup" exists.
--
ciao -
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: cvs commit: modperl-2.0/src/modules/perl modperl_env.c
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
> 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: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org