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:[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]
