You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modperl@perl.apache.org by Scott Beuker <sc...@sjrb.ca> on 2003/10/30 18:46:47 UTC
[mp2] CGI.pm param's always empty from only some clients (bug or
mistake on my part?)
Hi,
Appologies if this is to the wrong list, I thought I'd start here
to see if I'm doing something wrong first, and then move to the
dev list if I can't resolve my problem. None the less, a bug report
is attached below.
After porting one of my mod_perl apps from 1 to 2, I thought that I
had it working but then later found that for some users, POST form
data was not available. In other words, when they would submit the
form data all of the CGI.pm param()'s were empty even though in my
Apache access_log I could see that they had made a POST request. About
50% of users were affected and I still have not found a pattern amongst
them that distinguishes them from those who are unaffected. GET
requests with form data from these same people seem to work fine
(although this app needs to POST it's data unfortunately).
I tried many different things in my troubleshooting but to no avail,
the only thing that I can do to make my app work is remove it from
mod_perl configuration so that it is being handled by the regular
perl interpreter. Then, it works fine. Unfortunately my application
is quite large (996 lines) so I'm refrain from posting it here yet.
There are no errors in the error_log when the user submits; it looks
like just another request from the server side.
The relivent portion of my httpd.conf is as follows:
----- httpd.conf -----
<VirtualHost *>
DocumentRoot /www
ServerName krunk.soc.shaw.ca
<Location /trend.soc.shaw.ca/trend*.pl>
SetHandler perl-script
PerlResponseHandler ModPerl::Registry
Options +ExecCGI
PerlOptions +ParseHeaders
allow from all
</Location>
</VirtualHost>
PerlModule ModPerl::Registry
PerlModule GD
PerlModule GD::Graph::lines
PerlModule CGI
PerlModule Apache::DBI
PerlModule DBI
PerlModule Spreadsheet::WriteExcel
<Perl>
$ENV{SYBASE} = "/opt/sybase";
$ENV{LANG} = "en";
use ModPerl::RegistryLoader;
ModPerl::RegistryLoader->new->handler("/trend.soc.shaw.ca/trendgraph.pl",
"/www/trend.soc.shaw.ca/trendgraph.pl");
ModPerl::RegistryLoader->new->handler("/trend.soc.shaw.ca/trend_fe.pl",
"/www/trend.soc.shaw.ca/trend_fe.pl");
</Perl>
----------------------
Thank you in advance for any help. I realize that this is probably
not enough information to resolve an issue (unless it is a known
issue), but with some guidance I can provide some more information
or even the afformentioned source code if desired.
Cheers,
Scott Beuker
-------------8<---------- Start Bug Report ------------8<----------
1. Problem Description:
See above.
2. Used Components and their Configuration:
*** mod_perl version 1.9910
*** using lib/Apache/BuildConfig.pm
*** Makefile.PL options:
MP_APR_CONFIG => /usr/local/apache-2.0.48/bin/apr-config
MP_COMPAT_1X => 1
MP_GENERATE_XS => 1
MP_LIBNAME => mod_perl
MP_USE_DSO => 1
MP_USE_STATIC => 1
*** The httpd binary was not found
*** /usr/bin/perl -V
Summary of my perl5 (revision 5.0 version 8 subversion 0) configuration:
Platform:
osname=linux, osvers=2.4.21-1.1931.2.382.entsmp,
archname=i386-linux-thread-multi
uname='linux str'
config_args='-des -Doptimize=-O2 -g -pipe -march=i386 -mcpu=i686
-Dmyhostname=localhost -Dperladmin=root@localhost -Dcc=gcc -Dcf_by=Red Hat,
Inc. -Dinstallprefix=/usr -Dprefix=/usr -Darchname=i386-linux
-Dvendorprefix=/usr -Dsiteprefix=/usr -Dotherlibdirs=/usr/lib/perl5/5.8.0
-Duseshrplib -Dusethreads -Duseithreads -Duselargefiles -Dd_dosuid
-Dd_semctl_semun -Di_db -Ui_ndbm -Di_gdbm -Di_shadow -Di_syslog
-Dman3ext=3pm -Duseperlio -Dinstallusrbinperl -Ubincompat5005 -Uversiononly
-Dpager=/usr/bin/less -isr'
hint=recommended, useposix=true, d_sigaction=define
usethreads=define use5005threads=undef'
useithreads=define usemultiplicity=
useperlio= d_sfio=undef uselargefiles=define usesocks=undef
use64bitint=undef use64bitall=un uselongdouble=
usemymalloc=, bincompat5005=undef
Compiler:
cc='gcc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS
-DDEBUGGING -fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE
-D_FILE_OFFSET_BITS=64 -I/usr/include/gdbm',
optimize='',
cppflags='-D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS -DDEBUGGING
-fno-strict-aliasing -I/usr/local/include -I/usr/include/gdbm'
ccversion='', gccversion='3.2.2 20030222 (Red Hat Linux 3.2.2-5)',
gccosandvers=''
gccversion='3.2.2 200302'
intsize=r, longsize=r, ptrsize=5, doublesize=8, byteorder=1234
d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
ivtype='long'
k', ivsize=4'
ivtype='l, nvtype='double'
o_nonbl', nvsize=, Off_t='', lseeksize=8
alignbytes=4, prototype=define
Linker and Libraries:
ld='gcc'
l', ldflags =' -L/u'
libpth=/usr/local/lib /lib /usr/lib
libs=-lnsl -lgdbm -ldb -ldl -lm -lpthread -lc -lcrypt -lutil
perllibs=
libc=/lib/libc-2.3.2.so, so=so, useshrplib=true, libperl=libper
gnulibc_version='2.3.2'
Dynamic Linking:
dlsrc=dl_dlopen.xs, dlext=so', d_dlsymun=undef, ccdlflags='-rdynamic
-Wl,-rpath,/usr/lib/perl5/5.8.0/i386-linux-thread-multi/CORE'
cccdlflags='-fPIC'
ccdlflags='-rdynamic -Wl,-rpath,/usr/lib/perl5', lddlflags='s
Unicode/Normalize XS/A'
Characteristics of this binary (from libperl):
Compile-time options: DEBUGGING MULTIPLICITY USE_ITHREADS USE_LARGE_FILES
PERL_IMPLICIT_CONTEXT
Locally applied patches:
MAINT18379
Built under linux
Compiled at Aug 13 2003 11:47:58
%ENV:
PERL_LWP_USE_HTTP_10="1"
@INC:
/usr/lib/perl5/5.8.0/i386-linux-thread-multi
/usr/lib/perl5/5.8.0
/usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi
/usr/lib/perl5/site_perl/5.8.0
/usr/lib/perl5/site_perl
/usr/lib/perl5/vendor_perl/5.8.0/i386-linux-thread-multi
/usr/lib/perl5/vendor_perl/5.8.0
/usr/lib/perl5/vendor_perl
/usr/lib/perl5/5.8.0/i386-linux-thread-multi
/usr/lib/perl5/5.8.0
.
3. This is the core dump trace: (if you get a core dump):
[CORE TRACE COMES HERE]
This report was generated by t/REPORT on Thu Oct 30 17:26:14 2003 GMT.
-------------8<---------- End Bug Report --------------8<----------
Re: [mp2] CGI.pm param's always empty from only some clients (bug
or mistake on my part?)
Posted by Stas Bekman <st...@stason.org>.
Scott Beuker wrote:
> Hi,
>
> Appologies if this is to the wrong list, I thought I'd start here
> to see if I'm doing something wrong first, and then move to the
> dev list if I can't resolve my problem. None the less, a bug report
> is attached below.
This list is just as good as the dev list. So you are in the right place.
> After porting one of my mod_perl apps from 1 to 2, I thought that I
> had it working but then later found that for some users, POST form
> data was not available. In other words, when they would submit the
> form data all of the CGI.pm param()'s were empty even though in my
> Apache access_log I could see that they had made a POST request. About
What CGI.pm version are you using? Make sure you use the latest one.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [mp2] CGI.pm param's always empty from only some clients (bug
or mistake on my part?)
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
Stas Bekman wrote:
> There are two things I'd suggest to try:
>
> 1) pass $r to CGI->new($r), in which case it won't rely on the global
> Apache->request. And you can switch then to 'PerlHandler modperl'.
>
> 2) use the IO trace to debug what's going on:
>
> you need to rebuild mp with MP_TRACE=1 and then add to httpd.conf:
>
> PerlTrace o
>
> http://perl.apache.org/docs/2.0/user/config/config.html#C_PerlTrace_
>
> compare the traces you get on the good and the bad machines.
kyle's post got me thinking. it would be interesting to see the output of
this along with those traces. this is against CGI.pm 3.00. untested, but
you get the idea :)
--- 5.8.1/CGI.pm 2003-09-25 09:44:01.000000000 -0400
+++ ~CGI.pm 2003-10-30 19:24:53.000000000 -0500
@@ -834,6 +834,13 @@
my($self, $fh, $buff, $len, $offset) = @_;
local $^W=0; # prevent a warning
return undef unless defined($fh);
+ if ($MOD_PERL) {
+ warn '*** reading POST data: ', caller;
+ warn '*** yikes! read from POST twice!'
+ if $self->r->notes('CGIPOSTREAD');
+
+ $self->r->notes(CGIPOSTREAD => 1);
+ }
return read($fh, $$buff, $len, $offset);
}
Re: [mp2] CGI.pm param's always empty from only some clients (bug
or mistake on my part?)
Posted by Stas Bekman <st...@stason.org>.
There are two things I'd suggest to try:
1) pass $r to CGI->new($r), in which case it won't rely on the global
Apache->request. And you can switch then to 'PerlHandler modperl'.
2) use the IO trace to debug what's going on:
you need to rebuild mp with MP_TRACE=1 and then add to httpd.conf:
PerlTrace o
http://perl.apache.org/docs/2.0/user/config/config.html#C_PerlTrace_
compare the traces you get on the good and the bad machines.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [mp2] CGI.pm param's always empty from only some clients (bug
or mistake on my part?)
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
> Cool... exactly the same thing happened to me, except that it wasn't
> when I switched
> from mp1 to mp2 (which I haven't done), it was when I upgraded from
> Jaguar to
> Panther, which comes with 5.8.1RC3 and a pre-built Apache/mod_perl.
eeck, a release candidate on a major os? unbelievable.
> So
> I'm still
> using mp1, yet the exact same thing happens to me; all the POST values
> are lost.
that's not good. mp1 and CGI.pm have been friends for a long time, so I
wouldn't have expected this.
>
> I sniffed around and it seems to be that something is funky with the way
> that CGI.pm is initialising itself under mod_perl;
any chance you can go back to 5.8.0 or the official 5.8.1, recompile, and
see if that makes a difference?
> remember that when a
> mod_perl process accesses $r->args, all future calls to that will return
> nothing.
well, not $r->args, since that's for the query string. but for POST data
($r->content) you're right.
> It seems to me that this is happening too early in the case of
> a POST, but it's not in my code anywhere... so I suspect it's buried
> somewhere in the bowels of Apache and CGI and their interactions with
> each other.
mod_perl doesn't do it, neither does apache. so it must be CGI.pm. one way
to try and debug this would be to read from STDIN directly (you know, the
way we all used to do it way back when :) during a fixup handler and see if
the POST data is there. then remove CGI.pm entirely and do the same thing
from a registry script.
>
> Seems I was luckier than Scott though since I had wrapped all calls to
> get parameters from CGI.pm with a few methods of my own. To get around
> the weirdness, I just replaced the instance of CGI.pm with an instance
> of Apache::Request, and everything started working again.
cool. Apache::Request is nice, isn't it :)
--Geoff
Re: [mp2] CGI.pm param's always empty from only some clients (bug or mistake on my part?)
Posted by Kyle Dawkins <ky...@centralparksoftware.com>.
Scott et al.
> After porting one of my mod_perl apps from 1 to 2, I thought that I
> had it working but then later found that for some users, POST form
> data was not available. In other words, when they would submit the
> form data all of the CGI.pm param()'s were empty even though in my
> Apache access_log I could see that they had made a POST request. About
> 50% of users were affected and I still have not found a pattern amongst
> them that distinguishes them from those who are unaffected. GET
> requests with form data from these same people seem to work fine
> (although this app needs to POST it's data unfortunately).
Cool... exactly the same thing happened to me, except that it wasn't
when I switched
from mp1 to mp2 (which I haven't done), it was when I upgraded from
Jaguar to
Panther, which comes with 5.8.1RC3 and a pre-built Apache/mod_perl. So
I'm still
using mp1, yet the exact same thing happens to me; all the POST values
are lost.
I sniffed around and it seems to be that something is funky with the
way that CGI.pm is initialising itself under mod_perl; remember that
when a mod_perl process accesses $r->args, all future calls to that
will return nothing. It seems to me that this is happening too early
in the case of a POST, but it's not in my code anywhere... so I suspect
it's buried somewhere in the bowels of Apache and CGI and their
interactions with each other.
Seems I was luckier than Scott though since I had wrapped all calls to
get parameters from CGI.pm with a few methods of my own. To get around
the weirdness, I just replaced the instance of CGI.pm with an instance
of Apache::Request, and everything started working again.
Not sure if this helps, but maybe it'll get you on the right track.
Cheers
Kyle Dawkins
Central Park Software
Re: [mp2] CGI.pm param's always empty from only some clients (bug
or mistake on my part?)
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
> After porting one of my mod_perl apps from 1 to 2, I thought that I
> had it working but then later found that for some users, POST form
> data was not available.
thanks for the report.
can you let us know specifically the version of CGI.pm you were using. also,
please try with the latest CGI.pm from CPAN and see if that helps you.
I'm going to write a POST test or two and add it to the Registry test suite,
though it might not help since you say you don't see the issue all the time.
at any rate, if you could post a snippet that shows pretty much how you use
CGI.pm to get the POST data, I'll use that approach for the tests to help
reduce it some (the import statement, calls to $q->param, etc).
thanks
--Geoff