httpd-apreq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Schaefer <joe+apa...@sunstarsys.com>
Subject Re: Apache::Request patch request (fwd)
Date Thu, 08 Mar 2001 21:43:19 GMT
Jody Biggs <jody@codegrok.com> writes:

> anyhow, I think the problem was just that Request.pm holds:
> 
> sub param {
>     #...
>     if (defined $value) {
>         $tab->set($name, $value);
>     }
>     #...
> }
> 
> however, $tab, which if I'm correct in assuming is an Apache::Table
> object, only accepts string values to set, which means you get your array
> ref converted to a string when it gets set.

Yes- which is why I feel this is more of an Apache::Table issue than 
an Apache::Request one.  You are correct that libapreq holds the
parameter data in an apache table, which can be multi-valued.  Hence

  $table->add($name, [qw(a b c d)]);

performs some behind-the-scenes DWIMery (it creates multiple table
entries, one for each value in the anonymous array, rather than a 
single key with a perl arrayref) that neither

  $table->set($name, [qw(a b c d)]);

nor

  $$table{$name} = [qw(a b c d)];

possess.  IMHO they should be fixed, but that's best left to the 
mod_perl developers.  Perhaps you should post to the modperl
users (or developer) list instead?


> sub param {
>     #...
>     if (defined $value) {
>         $tab->unset($name);
>         $tab->add($name, $value);
>     }
>     #...
> }

The fix you suggest seems OK, in case the mod_perl folks can't/won't 
change Apache::Table. Maybe we should include a similar work-around in 
libapreq-0.32?

> anyhow, I hope that all made sense, and that I'm not missing some obvious
> point in all of this.  If it does make sense, I'd certainly like to see
> the fix incorporated in the next version of libapreq (or however it
> makes sense to release it).

It did, and thanks for posting it.

-- 
Joe Schaefer


Mime
View raw message