Carl Brewer wrote: [...]
print $r->args;
Perfect.
I found that just after I posted the email too .. *doh*
prints "a=4", you can also do:
$r->args("a=5");
Is that what you are after?
Yes. Out of curiosity, why would setting the argument be of any use? It's come in from the URL supplied by the browser, you'd change it for some filter maybe?
For example if you want to implement mod_rewrite in one of the handlers prior to the response handler. In mod_perl 2.0, if you want to use a filter, you don't need to use $r->args, since you can write a filter that directly manipulates the GET request line, e.g. see:
http://perl.apache.org/docs/2.0/user/handlers/filters.html#Connection_Input_Filters
I've set PerlSwitches -T in httpd.conf, which I thought would taint the value of $r->args, but I can merrily print it out without any parsing, which seems wrong to me, any clues?
tainting has nothing to do with printing. Tainting is only important when you use externally acquired data inside system calls. See 'perldoc perltaint'.
Also see the guts of Apache/compat.pm for how it provides the backcompat functionality of doing:
my %args = $r->args;
The doco says that's evil, or at least it is in an array context, not a hash?
hash is an array context
Usage Context ------------------------- $r->args VOID $args = $r->args SCALAR @args = $r->args ARRAY %args = $r->args ARRAY
it's not evil, it's just far from trivial to do the parsing right, therefore the job is delegated to the modules that excel at this job.
don't expect this to ever be part of the mp2 API, it's CGI.pm or Apache::Request that (will) do that job.
*nod*
I'm also trying to get my head around retrieving data from a POST form, which I don't think I can get with $r->args? In the absence of Apache::Request and CGI.pm what's the most appropriate mp2-pure way to get form data submitted by a POST form?
no, args gets you the QUERY_STRING
Something using APR::Table ?
Bucket Brigades.
any examples? :)
sure:
There is 'sub content' in Apache::compat, but currently it uses a buggy get_client_block.
There is 'sub ModPerl::Test::read_post' in t/conf/modperl_extra.pl that does it right.
make sure to look in the cvs version, as I rewrote ModPerl::Test::read_post recently, after discovering that get_client_block is broken in certain situations when working with input filters.
__________________________________________________________________ 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
