Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

dws (341)

dws
  (email not shown publicly)
http://www.davewsmith.com/

Journal of dws (341)

Tuesday December 21, 2004
03:31 AM

Bizarre Bugs on a Monday Morning

[ #22393 ]

This morning's expedition into the bizzare involved tracking down an obscure interaction between mod_perl 1.99 and CGI::Simple. Normally, these two get along just fine, though we noticed a while back that file uploads would cause later users of the same Apache process (e.g., some other browser) to lose URI arguments. (Finding this involved some fine detective work and a bit of luck.) The fix at the time was to note that a multipart/form-data post had just been handled, then rflush the request object and exit the process. File uploads were infrequent in our app, so forcing Apache to start a new process was no big deal.

Time passes, and along comes a feature that requires keeping the connection alive. Debugging ensues.

When the dust settled, it appears that there are two problems that manage to avoid each other almost all of the time. The first is that the Apache object hangs on to the request type (which is normally undefined, but will be multipart/form-data when a correctly coded file upload happens), and reports this as the type for subsequent requests, including GETs. An oops, but a mostly benign one.

The complementary problem, in CGI::Simple, is that requests with a type of multipart/form-data get special handling, regardless of the request method. If the request doesn't include arguments, nobody notices. But if there are URI arguments, they get ignored in favor of a non-existent form. An oops, and one that would occassional cause our app to squawk.

I suggested a fix in the bug report: only do the multipart/form-data handling if the request method is POST.

Debugging Apache processes isn't fun, but it beats late holiday shopping.

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • Both components should be fixed, though. It is wrong for Apache to report the MIME type of an earlier request for a later one. The bug in CGI::Simple is less obviously wrong behaviour.

    The fact that fixing the smaller bug in CGI::Simple hides the problem should not result in complacency about the problem in mod_perl; components other than CGI::Simple in different circumstances might still be confused by that behaviour.

    • It is wrong for Apache to report the MIME type of an earlier request for a later one. The bug in CGI::Simple is less obviously wrong behaviour.

      We're back a few levels on Apache; I'll verify if it's still a problem with current code before reporting a bug. As for CGI::Simple's behavior being less obviously wrong, I invite you to provide a scenario where a multipart/form-data GET that makes sense.

      • That's not supposed to happen. :-)

        My point is along the lines that Apache will exhibit a bug even on correct input, while CGI::Simple does not sufficiently validate the correctness of its input.

        Thinking about it, the most correct is probably for CGI::Simple to raise an error of some form when it encounters that combination.