You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modperl@perl.apache.org by Tom Mornini <tm...@infomania.com> on 2000/06/16 06:05:37 UTC
Two Apache::Request issues
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.
The man pages show this:
my $value = $apr->param('foo');
my @values = $apr->param('foo');
my @params = $apr->param;
$apr->param('foo' => [qw(one two three)]);
I certainly read example 3 to mean that it operated as CGI.pm.
Are there any reasons not to handle this as CGI.pm would?
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'
I suspect and hope that Apache::Request is just being a little
over-specific by looking for an exact match on
application/x-www-form-urlencoded. I don't see why it should have
difficulty passing in the straight 8 bit clean UTF-8 code. Then again,
I've been known to be massively optimistic on certain issues. :-)
I understand that there are many possible issues regarding 5.6, etc.
but I'm just looking for straight 8 bit binary characters here.
--
-- Tom Mornini
-- InfoMania Printing and Prepress
Re: Two Apache::Request issues
Posted by Tom Mornini <tm...@infomania.com>.
On Fri, 16 Jun 2000, Jim Winstead wrote:
> > > 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.)
Sorry about that! I learned (from the CGI.pm pod's) to use the param call
in a conditional to determine execution path. This is scalar context, and
was the source of my frustration.
> 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.
And THAT worked fine! Again, thanks a lot for this.
--
-- Tom Mornini
-- InfoMania Printing and Prepress
Re: Two Apache::Request issues
Posted by Jim Winstead <ji...@trainedmonkey.com>.
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
Re: Two Apache::Request issues
Posted by Tom Mornini <tm...@infomania.com>.
On Fri, 16 Jun 2000, Jim Winstead wrote:
> > 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, unfortuneately, does not work. I made this change, rebuilt and
reinstalled the module, and the error DOES go away. Unfortunately, no form
data is available via $ar->param either! :-)
--
-- Tom Mornini
-- InfoMania Printing and Prepress
Re: Two Apache::Request issues
Posted by Tom Mornini <tm...@infomania.com>.
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...
Am I sure? Try this code in a Registry script for yourself.
use strict;
use Apache;
use Apache::Request;
my $r = Apache->request;
my $ar = Apache::Request->new($r);
$ar->send_http_header;
print scalar($ar->param);
The result? Apache::Table=HASH(0x990ae38) (!)
This makes this use:
if ( $ar->param ) {
# Process Form Input
} else {
# First time through!
}
# display page
impossible. This works fine with CGI.pm
> > 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.
--
-- Tom Mornini
-- InfoMania Printing and Prepress
Re: Two Apache::Request issues
Posted by Jim Winstead <ji...@trainedmonkey.com>.
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.
> 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.)
Jim