We have tested using a remote browser with a user sitting at a browser to repro the issue (hours of hitting the enter key, holy cow), and we have also used scripts that make LWP POST requests on the same netblock, as well as running the LWP POST from localhost - all versions saw about a 1% occurrence of POST data being dropped at the Perl/CGI runtime (except for the user testing with browser, which took about 40-50 thousand reloads to get a repro, no joke). It's obvious that Apache is consuming the POST data at some point prior to getting to the Perl/CGI level, but I'm a Perl-head and not an Apache-head, so I don't know how to debug Apache to find a trace of where it's being consumed and removed prior to getting to Perl/CGI. Our virtualhost configuration is very minimal and simple for a basic web apps server with some static/SSI content. There's a cgi-bin and a handful of mod_perl2 handlers, but the scripts having the issues are the ones in the cgi-bin path and just use plain Perl with CGI GET/POST parameter parsing. Here's a list of the modules we have enabled on the server, all of them are default config (from Ubuntu's stable packages), nothing custom: /etc/apache2/mods-enabled/alias.load /etc/apache2/mods-enabled/auth_basic.load /etc/apache2/mods-enabled/authn_file.load /etc/apache2/mods-enabled/authz_default.load /etc/apache2/mods-enabled/authz_groupfile.load /etc/apache2/mods-enabled/authz_host.load /etc/apache2/mods-enabled/authz_user.load /etc/apache2/mods-enabled/autoindex.load /etc/apache2/mods-enabled/cgi.load /etc/apache2/mods-enabled/dir.load /etc/apache2/mods-enabled/env.load /etc/apache2/mods-enabled/include.load /etc/apache2/mods-enabled/mime.load /etc/apache2/mods-enabled/mod-wsgi.load /etc/apache2/mods-enabled/negotiation.load /etc/apache2/mods-enabled/perl.load /etc/apache2/mods-enabled/php5.load /etc/apache2/mods-enabled/rewrite.load /etc/apache2/mods-enabled/setenvif.load /etc/apache2/mods-enabled/status.load Hopefully that helps give more details and insight as well. I'm totally at a loss with this issue, but it's really bothering myself and my users something fierce. =/ I'm hoping not to be forced to move to nginx, but the lack of support from Apache folks is discouraging (not to mention the AWFUL documentation for mod_perl2)... On Wed, Feb 23, 2011 at 1:46 PM, Jeff Trawick <trawick@xxxxxxxxx> wrote: > On Wed, Feb 23, 2011 at 4:01 PM, Ursa Polaris <polaris.ursa@xxxxxxxxx> wrote: >> I guess I forgot to mention that we have verified using WireShark >> that Chrome, Firefox and IE are all correctly sending the POST data >> over the network in these cases. It's not a browser issue. > > that's great info > (note that you have to be a little bit careful when looking at the > packet trace; you may see a TCP connection with the entire request > header and POST body sent yet it receives no response; then the > browser opens a new TCP connection, sends the request header without > body, and after Timeout seconds gets an error response) > > unless you have any single sign-on modules loaded (always a good > target to blame) or other third-party modules which can process the > request body, no other ideas here; possibly the timing of the body > being sent vs. error being triggered would narrow down the > possibilities > > --------------------------------------------------------------------- > The official User-To-User support forum of the Apache HTTP Server Project. > See <URL:http://httpd.apache.org/userslist.html> for more info. > To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx > " from the digest: users-digest-unsubscribe@xxxxxxxxxxxxxxxx > For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx > > --------------------------------------------------------------------- The official User-To-User support forum of the Apache HTTP Server Project. See <URL:http://httpd.apache.org/userslist.html> for more info. To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx " from the digest: users-digest-unsubscribe@xxxxxxxxxxxxxxxx For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
|