On Jun 16, Tom Mornini wrote:
> On Fri, 16 Jun 2000, Jim Winstead wrote:
> 
> > On Jun 15, Tom Mornini wrote:
> > > I have recently noticed two issues with Apache::Request and thought I'd
> > > run them by the list before I began hacking and diffing for Doug.
> > > 
> > > 1) $ar->param without parameters has different behaviour than CGI.pm
> > > 
> > >   Apache::Request returns a reference, CGI.pm returns a list of
> > >   parameters.
> > 
> > Are you sure about this? I do this all over the place and it
> > works as documented for me.
> 
> As documented? As I pointed out before, the documentation is not clear. It
> never shows $ar->param being called with no arguments in scalar context...

Ah. You didn't mention the "in a scalar context" bit or I read past
it. It's returning an Apache::Table object. The documentation should
probably get fixed to clarify that, or maybe that feature should
be removed. (Since you can get the Apache::Table using the undocumented
parms() method.)

You could force the test if the if statement to a list context by
doing something like "if (my (@args) = $ar->param))". You could also
make the test check "keys %{$ar->param}", but that won't work with
CGI.pm, obviously.

> > > 2) [Thu Jun 15 21:09:49 2000] [error] [client 10.50.2.57] [libapreq]
> > >    unknown content-type: `application/x-www-form-urlencoded;
> > >    charset=utf-8'
> > 
> > This could probably be fixed by changing the strEQ(ct, DEFAULT_ENCTYPE)
> > to ststr(ct, DEFAULT_ENCTYPE) in c/apache_request.c on line 204. (The
> > test for multipart/form-data does this. Don't know why this one is more
> > strict.)
> 
> This is great! I'll give it a try.

Saw that didn't work. There's another test at line 300 that you
need to fix in the same way.

Jim

Reply via email to