You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@perl.apache.org by Enrico Sorcinelli <e....@pisa.iol.it> on 2004/01/28 15:13:16 UTC
[MP2] Problem in retrieving additional environment variables
Hi all,
I've this strange (for me) behaviour (Apache 2.0.48/mod_perl 1.9912).
In MP2 (Registry scripts and handlers) I cannot retrieve, directly from %ENV,
the additional environvment variables that I pushed with $r->subprocess_env
method (for example in a Translation or HeaderParser phase).
In details, I can see these additional variables only by calling:
Apache->request->subprocess_env('MY_VAR')
but not with:
$ENV{'MY_VAR'}
This is not a big problem with MP handers, but with CGI scripts that run under
ModPerl::Registry: I have to port many CGI scripts that use %ENV and that
currently work fine under MP1 Apache::Registry (yes I know, I could substitute
each occurrence of $ENV{'MY_VAR'} with a code like:
MP ? Apache->request->subprocess_env('MY_VAR') : $ENV{'MY_VAR'};
However, I correctly see this additional variable in CGI/mod_cgi scripts with
$ENV{'MY_VAR'}, in SSI pages with <!--#echo var="MY_VAR"--> (and also in PHP),
so I'm a little bit confused... :-)
I configured Apache 2 with:
...
Alias /registry/ "/path/to/subprocess_env/cgi-bin/"
<Directory "/path/to/subprocess_env/cgi-bin/">
SetHandler perl-script
PerlResponseHandler ModPerl::Registry
Options +ExecCGI
# redundant with 'perl-script'...
PerlOptions +SetupEnv
</Directory>
...
I read docs, 'horse' book but I haven't found any relevant info. I'm missing
something in my configuration in order to populate and retrieve values from
%ENV?
I attached a little tar.gz package with complete scripts, MP handlers, and
Apache conf (MP 1 & 2) files I used in order to easily reproduce my tests.
Thanks in advance for any suggestion :-)
by
- Enrico
Re: [MP2] Problem in retrieving additional environment variables
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
terribly sorry about that - there was nothing in that last email. my finger
slipped...
--Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [MP2] Problem in retrieving additional environment variables
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
Stas Bekman wrote:
> Geoffrey Young wrote:
>
>>> But, let's forget for a moment mp1. What's the most intuitive way to
>>> handle:
>>>
>>> $r->subprocess_env(foo => $bar)
>>>
>>> won't you sort of expect that %ENV will get that entry too?
>>
>>
>>
>> well, knowing how apache works it was definitely a surprise when I
>> looked at
>> subenv.t :)
>
>
> Are you referring to the line:
>
> $env = $r->subprocess_env; #table may have been overlayed
>
> where it says "may have been"?
>
>> so, no, I wouldn't expect it to work that way. CGI-style scripts should
>> expect only documented things within %ENV - REMOTE_USER, HTTPS, etc.
>> handlers should be using $r->subprocess_env to access additional
>> parameters
>> that only they know about - why would a handler populate
>> $r->subprocess_env
>> with some random variable in one phase, then check %ENV in another
>> phase for
>> it? it's inefficient to populate %ENV that way when you have access
>> to both
>> methods.
>
>
> OK. You know, as you explain things you should really put them down to
> the docs. So we don't have to explain it again.
>
>>> may be we
>>> should adjust subprocess_env to set %ENV as well. %ENV gets reset at the
>>> end of the request.
>>
>>
>>
>> per-request scoping is _definitely_ the desired behavior here.
>
>
> No questions about that.
>
>>> Hmm, I wonder what happens if you use an interpreter scope == handler
>>> and get a different interpreter for different phases. Looks like that
>>> %ENV setting won't be seen by the other interpreter.
>>
>>
>>
>> yup, but that's true about a few things, right?
>
>
> I'm not sure there are any, we don't have any tests to prove and
> disaprove that.
>
>>> Your above patch is fine Geoff, but it just looks like a big waste to
>>> me, if someone just wants to add a single pair to %ENV. Otherwise it's
>>> not needed, I think (it should be enough to call it once per request).
>>> May be we need a different API, like I suggest below, just for that
>>> purpose?
>>
>>
>>
>> I don't see that as the point. now, calling $r->subprocess_env in a void
>> context has two effects: it adds standard CGI variables _and_
>> subprocess_env
>> variables to %ENV. but whoever calls it first blocks later
>> subprocess_env
>> entries from making it to %ENV, even if a later handler wants to force
>> the
>> issue with a void call.
>>
>> so, really what we have is that a void call is _guaranteed_ to
>> populate CGI
>> variables, and will _sometimes_ pass on subprocess_env entries. to
>> me, the
>> inconsistency warrants being able to call subprocess_env in a void
>> context
>> more than once, letting several modular handlers control what data
>> they want
>> in %ENV.
>
>
> Sure, I'm convinced now. Gor for it, Geoff.
>
>> the more that I think about it, the more I think we ought to postpone
>> %ENV
>> population until just before the content handler callback is run - since
>> handlers have access to $r->subprocess_env and you can't hook normal perl
>> into any other phases, setting things up just prior to content generation
>> should be quite sufficient. I think this was the general
>> understanding of
>> the old PerlSetupEnv anyway - that it was for setting up %ENV for
>> Registry
>> scripts.
>
>
> That sounds reasonable to me. So you suggest to move this into the
> response handler? (twice once perl-script and the other modperl)
>
> __________________________________________________________________
> 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: [MP2] Problem in retrieving additional environment variables
Posted by Stas Bekman <st...@stason.org>.
some corrections to my last post
Stas Bekman wrote:
> Here it's the opposite, %ENV affects $r->subprocess_env, but not the
> other way around.
>
>> $ENV{FOO} = 2;
>> ok $ENV{FOO} == 2;
>> ok $r->subprocess_env->get('FOO') == 2;
>>
>> so, I suppose it's only with perl-script or +SetupEnv (or some
>> combination
>> of them).
>
>
> It's unrelated to the configuration, since it just calls
> modperl_table_get_set.
The right answer is 'only with perl-script' ;)
> BTW, It happens only during the response phase, only for 'perl-script',
> and not for 'modperl' (see modperl_env_request_tie /
> modperl_env_request_untie in mod_perl.c).
And it's undocumented at the moment. I think it belongs here:
http://perl.apache.org/docs/2.0/user/config/config.html#C_perl_script_
__________________________________________________________________
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: [MP2] Problem in retrieving additional environment variables
Posted by Stas Bekman <st...@stason.org>.
Geoffrey Young wrote:
[..]
> so, all is cool with me. sorry it took up so much bandwidth to get things
> straight in my head.
we just need to document it clearly, so the issue doesn't raise again and
again. I certainly don't remember all special env handling cases and I prefer
docs to the source code ;)
__________________________________________________________________
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: [MP2] Problem in retrieving additional environment variables
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
> that's a different test ;) and that's not what you said. You said:
>
>>>well, knowing how apache works it was definitely a surprise when I
>>>>> looked at
>>>>> subenv.t
>> ...
>> no, that $r->subprocess_env(MYFOO => 1) magically set $ENV{FOO}. I
> wasn't
>> expecting that.
yes, yes, I was getting all confused :)
>
> Here it's the opposite, %ENV affects $r->subprocess_env, but not the
> other way around.
> It's not "tied" per se. It just affects subprocess_env. I think it's a
> good thing. Consider a CGI script setting %ENV wants to affect a log
> handler (but can't use modperl api), which can now always get the env
> var via $s->subprocess_env (whether the previous phase was using %ENV or
> subprocess_env to set it).
ok, when I saw it happen in one direction, I assumed they were officially tied.
and I see your point wrt loggers.
> BTW, It happens only during the response phase, only for 'perl-script',
> and not for 'modperl' (see modperl_env_request_tie /
> modperl_env_request_untie in mod_perl.c).
that's even better. actually, letting %ENV population drizzle down to
subprocess_env only during content-generation is a rather nice feature.
so, all is cool with me. sorry it took up so much bandwidth to get things
straight in my head.
--Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [MP2] Problem in retrieving additional environment variables
Posted by Stas Bekman <st...@stason.org>.
Geoffrey Young wrote:
> bah, I knew I wasn't dreaming: it's there in env.t
that's a different test ;) and that's not what you said. You said:
>>well, knowing how apache works it was definitely a surprise when I
>>>> looked at
>>>> subenv.t
> ...
> no, that $r->subprocess_env(MYFOO => 1) magically set $ENV{FOO}. I wasn't
> expecting that.
Here it's the opposite, %ENV affects $r->subprocess_env, but not the other way
around.
> $ENV{FOO} = 2;
> ok $ENV{FOO} == 2;
> ok $r->subprocess_env->get('FOO') == 2;
>
> so, I suppose it's only with perl-script or +SetupEnv (or some combination
> of them).
It's unrelated to the configuration, since it just calls modperl_table_get_set.
> as I said before, I'm surprised by this - in mp1 they weren't tied, so we've
> added a feature.
It's not "tied" per se. It just affects subprocess_env. I think it's a good
thing. Consider a CGI script setting %ENV wants to affect a log handler (but
can't use modperl api), which can now always get the env var via
$s->subprocess_env (whether the previous phase was using %ENV or
subprocess_env to set it).
> it seems to me that not only is this a lot of overhead,
what is 'a lot of overhead'? setting one key/val pair in the table?
> but I don't see the
> need to tie them together if we move SetupEnv logic to the actual
> perl-script/modperl handler and document that SetupEnv is really for
> populating %ENV for mod_cgi-like emulation (which was always my
> understanding anyway).
Again. It's the other way around. I fail to see what is the problem that you
see here. So we move it to the response phase. But all we are moving is the
setup of the mod_cgi variables. the subprocess_env table can be used unrelated
to these vars. What do I miss?
BTW, It happens only during the response phase, only for 'perl-script', and
not for 'modperl' (see modperl_env_request_tie / modperl_env_request_untie in
mod_perl.c).
> do you remember why they were tied in the first place?
Doug implemented it in first place, I haven't touched it.
The relevant changes seem to be these:
http://cvs.apache.org/viewcvs.cgi/modperl-2.0/src/modules/perl/modperl_env.c?r1=1.18&r2=1.19&diff_format=h
http://cvs.apache.org/viewcvs.cgi/modperl-2.0/src/modules/perl/modperl_env.c?r1=1.10&r2=1.11&diff_format=h
http://cvs.apache.org/viewcvs.cgi/*checkout*/modperl-2.0/src/modules/perl/modperl_env.c?content-type=text%2Fplain&rev=1.1
__________________________________________________________________
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: [MP2] Problem in retrieving additional environment variables
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
Stas Bekman wrote:
> Geoffrey Young wrote:
>
>>> Grr, it actually doesn't do that at all. Where did you see it doing
>>> that?
>>
>>
>>
>> whoops...
>>
>> I was trying to write subenv.t tests yesterday for the patch I
>> proposed and
>> saw that behavior. but now I can't reproduce it. so, false alarm,
>> and many
>> appologies. and whew, I'm glad I'm wrong - one less thing to argue about
>> changing ;)
>
>
> ;)
>
> I was only suggesting that as a possible idea. Anyway, now the test
> tests that it does the right thing(tm).
bah, I knew I wasn't dreaming: it's there in env.t
my $env = $r->subprocess_env;
...
$ENV{FOO} = 2;
ok $ENV{FOO} == 2;
ok $env->get('FOO') == 2;
so, I suppose it's only with perl-script or +SetupEnv (or some combination
of them).
as I said before, I'm surprised by this - in mp1 they weren't tied, so we've
added a feature.
it seems to me that not only is this a lot of overhead, but I don't see the
need to tie them together if we move SetupEnv logic to the actual
perl-script/modperl handler and document that SetupEnv is really for
populating %ENV for mod_cgi-like emulation (which was always my
understanding anyway).
do you remember why they were tied in the first place?
--Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [MP2] Problem in retrieving additional environment variables
Posted by Stas Bekman <st...@stason.org>.
Geoffrey Young wrote:
>>Grr, it actually doesn't do that at all. Where did you see it doing that?
>
>
> whoops...
>
> I was trying to write subenv.t tests yesterday for the patch I proposed and
> saw that behavior. but now I can't reproduce it. so, false alarm, and many
> appologies. and whew, I'm glad I'm wrong - one less thing to argue about
> changing ;)
;)
I was only suggesting that as a possible idea. Anyway, now the test tests that
it does the right thing(tm).
__________________________________________________________________
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: [MP2] Problem in retrieving additional environment variables
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
> Grr, it actually doesn't do that at all. Where did you see it doing that?
whoops...
I was trying to write subenv.t tests yesterday for the patch I proposed and
saw that behavior. but now I can't reproduce it. so, false alarm, and many
appologies. and whew, I'm glad I'm wrong - one less thing to argue about
changing ;)
--Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [MP2] Problem in retrieving additional environment variables
Posted by Stas Bekman <st...@stason.org>.
Stas Bekman wrote:
> Geoffrey Young wrote:
>
>>>> well, knowing how apache works it was definitely a surprise when I
>>>> looked at
>>>> subenv.t :)
>>>
>>>
>>>
>>> Are you referring to the line:
>>>
>>> $env = $r->subprocess_env; #table may have been overlayed
>>>
>>> where it says "may have been"?
>>
>>
>>
>> no, that $r->subprocess_env(MYFOO => 1) magically set $ENV{FOO}. I
>> wasn't
>> expecting that.
>
>
> It does so only if -SetupEnv and subprocess_env wasn't called yet during
> this request in the void context. What's wrong about it? I'll adjust the
> test to explicitly test for %ENV.
Grr, it actually doesn't do that at all. Where did you see it doing that?
__________________________________________________________________
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: [MP2] Problem in retrieving additional environment variables
Posted by Stas Bekman <st...@stason.org>.
Geoffrey Young wrote:
>>>well, knowing how apache works it was definitely a surprise when I
>>>looked at
>>>subenv.t :)
>>
>>
>>Are you referring to the line:
>>
>> $env = $r->subprocess_env; #table may have been overlayed
>>
>>where it says "may have been"?
>
>
> no, that $r->subprocess_env(MYFOO => 1) magically set $ENV{FOO}. I wasn't
> expecting that.
It does so only if -SetupEnv and subprocess_env wasn't called yet during this
request in the void context. What's wrong about it? I'll adjust the test to
explicitly test for %ENV.
__________________________________________________________________
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: [MP2] Problem in retrieving additional environment variables
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
>> well, knowing how apache works it was definitely a surprise when I
>> looked at
>> subenv.t :)
>
>
> Are you referring to the line:
>
> $env = $r->subprocess_env; #table may have been overlayed
>
> where it says "may have been"?
no, that $r->subprocess_env(MYFOO => 1) magically set $ENV{FOO}. I wasn't
expecting that.
> OK. You know, as you explain things you should really put them down to
> the docs. So we don't have to explain it again.
:)
> Sure, I'm convinced now. Gor for it, Geoff.
ok, will do
>
>> the more that I think about it, the more I think we ought to postpone
>> %ENV
>> population until just before the content handler callback is run - since
>> handlers have access to $r->subprocess_env and you can't hook normal perl
>> into any other phases, setting things up just prior to content generation
>> should be quite sufficient. I think this was the general
>> understanding of
>> the old PerlSetupEnv anyway - that it was for setting up %ENV for
>> Registry
>> scripts.
>
>
> That sounds reasonable to me. So you suggest to move this into the
> response handler? (twice once perl-script and the other modperl)
yes. this is the way mod_cgi does it, IIRC, and it makes sense to me to
follow suit. I'll post a patch for this.
--Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [MP2] Problem in retrieving additional environment variables
Posted by Stas Bekman <st...@stason.org>.
Geoffrey Young wrote:
>>But, let's forget for a moment mp1. What's the most intuitive way to
>>handle:
>>
>> $r->subprocess_env(foo => $bar)
>>
>>won't you sort of expect that %ENV will get that entry too?
>
>
> well, knowing how apache works it was definitely a surprise when I looked at
> subenv.t :)
Are you referring to the line:
$env = $r->subprocess_env; #table may have been overlayed
where it says "may have been"?
> so, no, I wouldn't expect it to work that way. CGI-style scripts should
> expect only documented things within %ENV - REMOTE_USER, HTTPS, etc.
> handlers should be using $r->subprocess_env to access additional parameters
> that only they know about - why would a handler populate $r->subprocess_env
> with some random variable in one phase, then check %ENV in another phase for
> it? it's inefficient to populate %ENV that way when you have access to both
> methods.
OK. You know, as you explain things you should really put them down to the
docs. So we don't have to explain it again.
>>may be we
>>should adjust subprocess_env to set %ENV as well. %ENV gets reset at the
>>end of the request.
>
>
> per-request scoping is _definitely_ the desired behavior here.
No questions about that.
>>Hmm, I wonder what happens if you use an interpreter scope == handler
>>and get a different interpreter for different phases. Looks like that
>>%ENV setting won't be seen by the other interpreter.
>
>
> yup, but that's true about a few things, right?
I'm not sure there are any, we don't have any tests to prove and disaprove that.
>>Your above patch is fine Geoff, but it just looks like a big waste to
>>me, if someone just wants to add a single pair to %ENV. Otherwise it's
>>not needed, I think (it should be enough to call it once per request).
>>May be we need a different API, like I suggest below, just for that
>>purpose?
>
>
> I don't see that as the point. now, calling $r->subprocess_env in a void
> context has two effects: it adds standard CGI variables _and_ subprocess_env
> variables to %ENV. but whoever calls it first blocks later subprocess_env
> entries from making it to %ENV, even if a later handler wants to force the
> issue with a void call.
>
> so, really what we have is that a void call is _guaranteed_ to populate CGI
> variables, and will _sometimes_ pass on subprocess_env entries. to me, the
> inconsistency warrants being able to call subprocess_env in a void context
> more than once, letting several modular handlers control what data they want
> in %ENV.
Sure, I'm convinced now. Gor for it, Geoff.
> the more that I think about it, the more I think we ought to postpone %ENV
> population until just before the content handler callback is run - since
> handlers have access to $r->subprocess_env and you can't hook normal perl
> into any other phases, setting things up just prior to content generation
> should be quite sufficient. I think this was the general understanding of
> the old PerlSetupEnv anyway - that it was for setting up %ENV for Registry
> scripts.
That sounds reasonable to me. So you suggest to move this into the response
handler? (twice once perl-script and the other modperl)
__________________________________________________________________
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: [MP2] Problem in retrieving additional environment variables
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
> Yes and no, Geoff.
heh :)
>
> But, let's forget for a moment mp1. What's the most intuitive way to
> handle:
>
> $r->subprocess_env(foo => $bar)
>
> won't you sort of expect that %ENV will get that entry too?
well, knowing how apache works it was definitely a surprise when I looked at
subenv.t :)
so, no, I wouldn't expect it to work that way. CGI-style scripts should
expect only documented things within %ENV - REMOTE_USER, HTTPS, etc.
handlers should be using $r->subprocess_env to access additional parameters
that only they know about - why would a handler populate $r->subprocess_env
with some random variable in one phase, then check %ENV in another phase for
it? it's inefficient to populate %ENV that way when you have access to both
methods.
> may be we
> should adjust subprocess_env to set %ENV as well. %ENV gets reset at the
> end of the request.
per-request scoping is _definitely_ the desired behavior here.
>
> Hmm, I wonder what happens if you use an interpreter scope == handler
> and get a different interpreter for different phases. Looks like that
> %ENV setting won't be seen by the other interpreter.
yup, but that's true about a few things, right?
>
> Your above patch is fine Geoff, but it just looks like a big waste to
> me, if someone just wants to add a single pair to %ENV. Otherwise it's
> not needed, I think (it should be enough to call it once per request).
> May be we need a different API, like I suggest below, just for that
> purpose?
I don't see that as the point. now, calling $r->subprocess_env in a void
context has two effects: it adds standard CGI variables _and_ subprocess_env
variables to %ENV. but whoever calls it first blocks later subprocess_env
entries from making it to %ENV, even if a later handler wants to force the
issue with a void call.
so, really what we have is that a void call is _guaranteed_ to populate CGI
variables, and will _sometimes_ pass on subprocess_env entries. to me, the
inconsistency warrants being able to call subprocess_env in a void context
more than once, letting several modular handlers control what data they want
in %ENV.
>> not sure what to do about this, then. looks like both mp1 and mp2 suffer
>> from the same problem - add to $r->subprocess_env after the call to
>> ap_add_cgi_vars and Registry doesn't see stuff in %ENV. it's just
>> that the
>> call is happening at different times between the two.
>
>
> Enrico, with the first half of Geoff's patch (minus registry), you will
> be able to achieve what you want, by adding an explicit call to
> $r->subprocess_env(), but it's horribly inefficient, especially if you
> call it more than once. Of course that 'horrible' part could be just
> fine, if you aren't after msecs.
again, yes, it's inefficient. but if the API is to do what it says then we
have to allow for it. of course, we could also change the expectation of
the API and document that it is only guaranteed to do CGI variables, but I
think there is an understanding on how it handles other subprocess_env
entries (based on mp1) that will make this troublesome for some users.
>
> Until we figure it out, I think your best bet is to write a wrapper that
> does what you need:
the more that I think about it, the more I think we ought to postpone %ENV
population until just before the content handler callback is run - since
handlers have access to $r->subprocess_env and you can't hook normal perl
into any other phases, setting things up just prior to content generation
should be quite sufficient. I think this was the general understanding of
the old PerlSetupEnv anyway - that it was for setting up %ENV for Registry
scripts.
--Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [MP2] Problem in retrieving additional environment variables
Posted by Stas Bekman <st...@stason.org>.
Geoffrey Young wrote:
>>Can you please remind me what was the mp1 behavior on that? We need to
>>match it. Things are complicated in mp2, because the C environ struct is
>>detached from perl's %ENV, so there is a lot of extra work to do to
>>think %ENV and $r->subprocess_env
>
>
> as I said in another response, IIRC in mp1 %ENV was not tied to the
> subprocess_env table - you could populate $r->subprocess_env all day, but it
> wouldn't make it to %ENV until ap_add_cgi_vars was called. and
> ap_add_cgi_vars was only called 1) once per-request, or 2) if
> $r->subprocess_env was called in a void context.
>
> the once per-request appears to happen on the first entry into a directory
>
> if(r->per_dir_config)
> perl_per_request_init(r);
>
> which is different than mp2:
>
> case MP_HANDLER_TYPE_PER_DIR:
> case MP_HANDLER_TYPE_PER_SRV:
> ...
>
> /* only happens once per-request */
> if (MpDirSETUP_ENV(dcfg)) {
> modperl_env_request_populate(aTHX_ r);
> }
>
>
>>> {
>>> if (GIMME_V == G_VOID) {
>>>+ MP_dRCFG;
>>>+ MpReqSETUP_ENV_Off(rcfg);
>>>modperl_env_request_populate(aTHX_ r);
>>> }
>
>
> this is rquired to maintain mp1 compat, if we're intersted in that.
Yes and no, Geoff.
But, let's forget for a moment mp1. What's the most intuitive way to handle:
$r->subprocess_env(foo => $bar)
won't you sort of expect that %ENV will get that entry too? may be we should
adjust subprocess_env to set %ENV as well. %ENV gets reset at the end of the
request.
Hmm, I wonder what happens if you use an interpreter scope == handler and get
a different interpreter for different phases. Looks like that %ENV setting
won't be seen by the other interpreter.
Your above patch is fine Geoff, but it just looks like a big waste to me, if
someone just wants to add a single pair to %ENV. Otherwise it's not needed, I
think (it should be enough to call it once per request). May be we need a
different API, like I suggest below, just for that purpose?
>>>+ # make sure that registry scripts can see all of subprocess_env
>>>in %ENV
>>>+ $r->subprocess_env;
>>>+
>>
>>
>>This is ain't right, as it ignores the user's setting of whether to load
>>env vars or not via:
>>
>>PerlOptions [+-]SetupEnv and SetHandler (modperl|perl-script)
>
>
> yes, you're right.
>
> not sure what to do about this, then. looks like both mp1 and mp2 suffer
> from the same problem - add to $r->subprocess_env after the call to
> ap_add_cgi_vars and Registry doesn't see stuff in %ENV. it's just that the
> call is happening at different times between the two.
Enrico, with the first half of Geoff's patch (minus registry), you will be
able to achieve what you want, by adding an explicit call to
$r->subprocess_env(), but it's horribly inefficient, especially if you call it
more than once. Of course that 'horrible' part could be just fine, if you
aren't after msecs.
Until we figure it out, I think your best bet is to write a wrapper that does
what you need:
sub Apache::RequestRec::enrico_set_env {
$r->subprocess_env(@_);
$ENV{$_[0]} = $_[1];
}
and now you can call:
$r->enrico_set_env(foo => $bar);
This will affect only request handlers and work as long as you don't set perl
interpreter scope to 'handler'.
http://perl.apache.org/docs/2.0/user/config/config.html#C_PerlInterpScope_
__________________________________________________________________
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: [MP2] Problem in retrieving additional environment variables
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
> Can you please remind me what was the mp1 behavior on that? We need to
> match it. Things are complicated in mp2, because the C environ struct is
> detached from perl's %ENV, so there is a lot of extra work to do to
> think %ENV and $r->subprocess_env
as I said in another response, IIRC in mp1 %ENV was not tied to the
subprocess_env table - you could populate $r->subprocess_env all day, but it
wouldn't make it to %ENV until ap_add_cgi_vars was called. and
ap_add_cgi_vars was only called 1) once per-request, or 2) if
$r->subprocess_env was called in a void context.
the once per-request appears to happen on the first entry into a directory
if(r->per_dir_config)
perl_per_request_init(r);
which is different than mp2:
case MP_HANDLER_TYPE_PER_DIR:
case MP_HANDLER_TYPE_PER_SRV:
...
/* only happens once per-request */
if (MpDirSETUP_ENV(dcfg)) {
modperl_env_request_populate(aTHX_ r);
}
>> {
>> if (GIMME_V == G_VOID) {
>> + MP_dRCFG;
>> + MpReqSETUP_ENV_Off(rcfg);
>> modperl_env_request_populate(aTHX_ r);
>> }
this is rquired to maintain mp1 compat, if we're intersted in that.
>> + # make sure that registry scripts can see all of subprocess_env
>> in %ENV
>> + $r->subprocess_env;
>> +
>
>
> This is ain't right, as it ignores the user's setting of whether to load
> env vars or not via:
>
> PerlOptions [+-]SetupEnv and SetHandler (modperl|perl-script)
yes, you're right.
not sure what to do about this, then. looks like both mp1 and mp2 suffer
from the same problem - add to $r->subprocess_env after the call to
ap_add_cgi_vars and Registry doesn't see stuff in %ENV. it's just that the
call is happening at different times between the two.
--Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [MP2] Problem in retrieving additional environment variables
Posted by Stas Bekman <st...@stason.org>.
Geoffrey Young wrote:
>
> Enrico Sorcinelli wrote:
>
>>Hi all,
>>
>>I've this strange (for me) behaviour (Apache 2.0.48/mod_perl 1.9912).
>>
>>In MP2 (Registry scripts and handlers) I cannot retrieve, directly from %ENV,
>>the additional environvment variables that I pushed with $r->subprocess_env
>>method (for example in a Translation or HeaderParser phase).
Can you please remind me what was the mp1 behavior on that? We need to match
it. Things are complicated in mp2, because the C environ struct is detached
from perl's %ENV, so there is a lot of extra work to do to think %ENV and
$r->subprocess_env
> Index: xs/Apache/RequestRec/Apache__RequestRec.h
> ===================================================================
> RCS file: /home/cvspublic/modperl-2.0/xs/Apache/RequestRec/Apache__RequestRec.h,v
> retrieving revision 1.8
> diff -u -r1.8 Apache__RequestRec.h
> --- xs/Apache/RequestRec/Apache__RequestRec.h 14 Jan 2004 21:27:41 -0000 1.8
> +++ xs/Apache/RequestRec/Apache__RequestRec.h 28 Jan 2004 14:43:34 -0000
> @@ -47,6 +47,8 @@
> char *key, SV *val)
> {
> if (GIMME_V == G_VOID) {
> + MP_dRCFG;
> + MpReqSETUP_ENV_Off(rcfg);
> modperl_env_request_populate(aTHX_ r);
> }
>
> Index: ModPerl-Registry/lib/ModPerl/RegistryCooker.pm
> ===================================================================
> RCS file: /home/cvspublic/modperl-2.0/ModPerl-Registry/lib/ModPerl/RegistryCooker.pm,v
> retrieving revision 1.41
> diff -u -r1.41 RegistryCooker.pm
> --- ModPerl-Registry/lib/ModPerl/RegistryCooker.pm 25 Jan 2004 01:04:16 -0000 1.41
> +++ ModPerl-Registry/lib/ModPerl/RegistryCooker.pm 28 Jan 2004 14:43:34 -0000
> @@ -180,6 +180,9 @@
> %orig_inc = %INC;
> }
>
> + # make sure that registry scripts can see all of subprocess_env in %ENV
> + $r->subprocess_env;
> +
This is ain't right, as it ignores the user's setting of whether to load env
vars or not via:
PerlOptions [+-]SetupEnv and SetHandler (modperl|perl-script)
http://perl.apache.org/docs/2.0/user/config/config.html#C_SetupEnv_
http://perl.apache.org/docs/2.0/user/config/config.html#C_SetHandler_
__________________________________________________________________
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: [MP2] Problem in retrieving additional environment variables
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
> %ENV is not tied to $r->subprocess_env such that %ENV
> and $r->subprocess_env always look the same.
actually, I take that back. it looks like they are (at least for perl-script).
this is probably a bad idea - we should probably rely on ap_add_cgi_vars
(etc) for populating %ENV, and not join the two by default. it wasn't this
way in mp1, btw.
--Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [MP2] Problem in retrieving additional environment variables
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
> Thanks, I've applied this patch and it seems to solve Registry problems: it
> populates %ENV with additional vars.
> Moreover CGI/mod_cgi, SSI (and so on) work fine... :-)
cool.
>
> However, handler still doesn't have access to %ENV's additional vars (but this
> isn't a really problem for me).
well, they shouldn't. %ENV is not tied to $r->subprocess_env such that %ENV
and $r->subprocess_env always look the same. for handlers, you have access
to $r->subprocess_env, or you have the ability to call $r->subprocess_env in
a void context to forcefully populate %ENV (or at least you do now with the
patch - previously you could only force population once).
> Really, I didn't know the existence of this skeleton... :-(
> My future report will be a package :-)
excellent :)
--Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [MP2] Problem in retrieving additional environment variables
Posted by Enrico Sorcinelli <e....@pisa.iol.it>.
On Wed, 28 Jan 2004 09:47:35 -0500
Geoffrey Young <ge...@modperlcookbook.org> wrote:
Hi Geoff,
> the exchange between the subprocess_env table and %ENV only happens once
> per-request. to me, it looks like this once is on the first Perl*Handler
> callback. for the most part, I think this is ok, since handlers always have
> access to $r->subprocess_env anyway. but for Registry I guess it's problematic.
>
> so, try this (untested) patch and see if it helps.
Thanks, I've applied this patch and it seems to solve Registry problems: it
populates %ENV with additional vars.
Moreover CGI/mod_cgi, SSI (and so on) work fine... :-)
However, handler still doesn't have access to %ENV's additional vars (but this
isn't a really problem for me).
> >
> > I attached a little tar.gz package with complete scripts, MP handlers, and
> > Apache conf (MP 1 & 2) files I used in order to easily reproduce my tests.
>
> this is great! however, I'd suggest you use the bug skeletons we provde so
> that all we need to do is run 'make test'
>
> http://perl.apache.org/~geoff/bug-reporting-skeleton-mp2.tar.gz
> http://perl.apache.org/~geoff/bug-reporting-skeleton-mp1.tar.gz
> http://perl.apache.org/docs/2.0/user/help/help.html#Problem_Description
>
My apologies!
Really, I didn't know the existence of this skeleton... :-(
My future report will be a package :-)
by
- Enrico
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [MP2] Problem in retrieving additional environment variables
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
Enrico Sorcinelli wrote:
> Hi all,
>
> I've this strange (for me) behaviour (Apache 2.0.48/mod_perl 1.9912).
>
> In MP2 (Registry scripts and handlers) I cannot retrieve, directly from %ENV,
> the additional environvment variables that I pushed with $r->subprocess_env
> method (for example in a Translation or HeaderParser phase).
I know stas was working on this for a while and had a few issues with how it
was handled...
the exchange between the subprocess_env table and %ENV only happens once
per-request. to me, it looks like this once is on the first Perl*Handler
callback. for the most part, I think this is ok, since handlers always have
access to $r->subprocess_env anyway. but for Registry I guess it's problematic.
so, try this (untested) patch and see if it helps.
>
> I attached a little tar.gz package with complete scripts, MP handlers, and
> Apache conf (MP 1 & 2) files I used in order to easily reproduce my tests.
this is great! however, I'd suggest you use the bug skeletons we provde so
that all we need to do is run 'make test'
http://perl.apache.org/~geoff/bug-reporting-skeleton-mp2.tar.gz
http://perl.apache.org/~geoff/bug-reporting-skeleton-mp1.tar.gz
http://perl.apache.org/docs/2.0/user/help/help.html#Problem_Description
but you're definitely going in the right direction :)
--Geoff