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:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
