> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
