Ah... I assumed that $r->subprocess_env in VOID context was an expensive
operation as it populated $ENV (from what I had read) as one should try
to avoid it. I also find it non-intuitive that:
$r->subprocess_env; # void context
my $uri = $r->subprocess_env('REQUEST_URI');
is the same as
$r->subprocess_env;
my $uri = $ENV{REQUEST_URI};
But that's obviously just my lack of intuitiveness.
Yes, $r->uri is about a billion times more useful, thank-you again
David, and thanks for your help Torsten!
Tosh
Torsten Förtsch wrote:
On Friday 15 January 2010 19:41:45 Tosh Cooey wrote:
When the $key argument (string) is passed, it returns the corresponding
value (if such exists, or undef. The following two lines are equivalent:
$val = $r->subprocess_env($key);
$val = $r->subprocess_env->get($key);
Ok... Seems simple enough...
In my module if I do the following:
$r->subprocess_env;
my $uri = $ENV{REQUEST_URI};
The I get the URI.
But if I change the above to:
my $uri = $r->subprocess_env('REQUEST_URI');
I get undef.
Tosh, do you know what VOID context means in perl?
@list=function() # this list context
$scalar=function() # this is scalar context
function() # this is void context: the return value is ignored
Now, in void context and only then subprocess_env() calls
ap_add_common_vars(r);
ap_add_cgi_vars(r);
These 2 functions add such things like REQUEST_URI to the environment.
So, if you do it like this:
$r->subprocess_env; # void context
my $uri = $r->subprocess_env('REQUEST_URI');
it is very likely that you get the REQUEST_URI.
But as David pointed out, $r->uri is the much better way.
Torsten
--
McIntosh Cooey - Twelve Hundred Group LLC - http://www.1200group.com/
