FWIW I sometimes found that if an error occured somewhere, even an incorrect use of an undefined value, it screwed up mod perl's subroutine wrapper caching and caused the handler to run again. So you could be seeing the results of the second or third time the handler was hit. If you have warnings and strict on, hunt them all down, explicitly set empty string where it might be undefined etc, and see if it still happens.
Mark On Fri, 11 Aug 2006, Mon-Chaio Lo wrote: > From: Mon-Chaio Lo <[EMAIL PROTECTED]> > To: Perrin Harkins <[EMAIL PROTECTED]> > Cc: modperl@perl.apache.org > Date: Fri, 11 Aug 2006 15:19:56 -0700 > Subject: RE: Odd Apache mod_perl behavior > > Hmm, that seems to make sense, except for that the handler method of the > code sample I provided is the first piece of code that gets run and is > the first handler in the handler stack. Also, it doesn't happen on > every POST, just on some posts, which is odd ... :( > > M. > > On Thu, 2006-08-10 at 10:14 -0700, Mon-Chaio Lo wrote: > > What we're finding is that the request will fail at the > > $request->param() line. It doesn't seem to die, given that we don't > > get a 500 back, but if we put Log4perl warnings before and after that > > line we see that it doesn't progress past that line. > > That usually means you are trying to read POST data that has already > been read. Maybe you already called Apache::Request elsewhere? You can > usually use the instance() method to deal with this, or stash the data > in pnotes(). > > - Perrin > > >
