Skip Menu |

Preferred bug tracker

Please visit the preferred bug tracker to report your issue.

This queue is for tickets about the CGI CPAN distribution.

Report information
The Basics
Id: 57184
Status: resolved
Priority: 0/
Queue: CGI

Owner: Nobody in particular
Requestors: jgoodridge [...]

Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: (no value)

Subject: Bug found and fixed
Date: Mon, 3 May 2010 14:11:28 -0700
To: [...]
From: Jeremy Goodridge <jgoodridge [...]>
Download (untitled) / with headers
text/plain 2.1k
I have found a problem in in which CGI params do not get refreshed on subsequent requests. This didn't happen with every request, but I found that after about 5 minutes or 30 requests or so, suddenly, CGI would start using the same parameters for every request. The problem occurred on mod_perl 1.31 but NOT on mod_perl 1.29. I don't know about mod_perl 1.30. To fix I changed line 360: from: $r->register_cleanup(\&CGI::_reset_globals); to: $r->push_handlers( 'PerlCleanupHandler', \&CGI::_reset_globals); I thought the two snippets of code were identical but apparently not. So, this may really expose a mod_perl problem, or perhaps register_cleanup is now deprecated. Note that adding the cleanup handler explicitly in the httpd conf also works. So, specifically, adding PerlCleanupHandler CGI::_reset_globals to one's httpd conf fixes the problem. I believe this problem is related to the following conversation I found: This conversation mentioned an incompatibility between Apache::SizeLimit and I AM using Apache::SizeLimit and so that might be what exposes the problem. That might be why it takes some time to occur -- perhaps once Apache SizeLimit is engaged, CGI's cleanup handler is destroyed. I don't know. Or perhaps it is something fundamental within mod_perl. My installation includes: Apache: 1.3.41 mod_perl: 1.31 3.49 Apache::SizeLimit 0.91-dev Redhat EL5. As a further note, I noticed the following in the source code: # This used to use $r->post_connection but there's no good way to # test it, since apparently it does not push a handler onto the # PerlCleanupHandler phase. That means that there's no way to use # $r->get_handlers() to check the results of calling this method. $r->push_handlers( 'PerlCleanupHandler', sub { $class->_exit_if_too_big(shift) } ); So, that suggests to me that post_connection (which is supposed to be identical to register_cleanup) doesn't quite do what is expected. And reinforces the need for my fix. Please let me know if you have questions or need more information about my setup. Jeremy Goodridge
Download (untitled) / with headers
text/plain 468b
I'm hesitant to make the proposed change based on feedback from just one person, with no else adding a even one more "me too" comment in the past 3 years. It's a further concern that the issue is not reproducible with a automated test. To be conservative on changes to this widely used module, I'm marking this as "resolved" due to old age. It can be re-opened if we get a second data point. I've given the ticket a clearer subject to make it easier to find.

This service is sponsored and maintained by Best Practical Solutions and runs on infrastructure.

Please report any issues with to