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