Re: [MP2] Problem in retrieving additional environment variables

[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

[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