Closed
Bug 501653
Opened 15 years ago
Closed 15 years ago
Problems sending large POST on https to mod_ssl, depending on size and order
Categories
(NSS :: Libraries, defect)
Tracking
(Not tracked)
RESOLVED
WORKSFORME
People
(Reporter: jmdesp, Unassigned)
References
()
Details
Bug as described by Bart Cassady in bug 490442#4, based on the associated URL that unfortunately is not accessible right now. The test case though is apparently just a very basic POST form :
[...]
Try this:
copy this line 10 times, then copy all 10 lines (including final newline):
1234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890
Paste three of these (ie. ~3000 bytes) into the test case and submit it - it
should work.
Paste a total of four of these (ie. ~4000 bytes) into the test case and submit
- it should not work.
Paste a total of five of these (ie. ~5000 bytes) into the test case and submit
- it should not work if you did it immediately after the 4000 byte test, but
will work immediately after the 3000 byte test.
[...]
it exists for me when using apache/mod_ssl,
using Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.11)
Gecko/2009060215 Firefox/3.0.11 (.NET CLR 3.5.30729).
It does, however, work properly with Mozilla/5.0 (Windows; U; WinNT4.0; en-US;
rv:1.8.0.9) Gecko/20061206 Firefox/1.5.0.9, which is the only other environment
I have convenient access to.
I also notice that the test case works/breaks not just depending on the size,
but on the actual value and the order the submits are done.
[...]
-- bug 490442#5
the test case works on:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.20) Gecko/20081217
Firefox/2.0.0.20
and fails on:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9) Gecko/2008052906
Firefox/3.0
Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.0.1) Gecko/2008070208
Firefox/3.0.1
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.2) Gecko/2008091620
Firefox/3.0.2
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.3) Gecko/2008092417
Firefox/3.0.3
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.4) Gecko/2008102920
Firefox/3.0.4
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.5) Gecko/2008120122
Firefox/3.0.5
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.6) Gecko/2009011913
Firefox/3.0.6
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.7) Gecko/2009021910
Firefox/3.0.7
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.8) Gecko/2009032609
Firefox/3.0.8
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.9) Gecko/2009040821
Firefox/3.0.9
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.10) Gecko/2009042316
Firefox/3.0.10
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.11) Gecko/2009060215
Firefox/3.0.11
Reporter | ||
Comment 1•15 years ago
|
||
I'd like to have a network trace of the problem, or a currently working url, before I confirm this bug.
Comment 2•15 years ago
|
||
This is very reminiscent of
Bug 356470: HTTPS File Upload results in partial and/or corrupted files on server
which was a server bug, and
Bug 378629: SSL file uploads settle into oscillating pattern with very small packets
which was a bug in the browser's internal flow control (PSM and above, not NSS).
I simply won't tolerate another 6 month episode of "NSS is guilty until proven innocent" (as happened in bug 356470). So, I suggest you first look to see
if this is merely a duplicate of bug 356470, and/or bug 378629. Perhaps
bug 378629 has regressed. I also suggest you turn this into a PSM bug.
Comment 3•15 years ago
|
||
See also Bug 369414 - Uploads to mod_perl 1.3 truncated
which proved to be a server error.
Reporter | ||
Comment 4•15 years ago
|
||
Thanks Nelson, but still those problems were with apache 1.3 which is very probably not used here.
Let's try to get a usable repro procedure, which will give the definitive answer if there's something new here.
Bart, the test site below is currently on line using mod_ssl, but I was not able to repro on it with Gecko/20090623. Do you have more success ? :
https://www.legroom.net/gnutls_test.php
Comment 5•15 years ago
|
||
Sorry, I also was unable to reproduce it (Gecko/2009060215).
Some additional information:
For the internal reproduceable test (ie. the submission of the http POST) I get the following in the Apache 2.2.11 error_log:
[error] Re-negotiation handshake failed: Not accepted by client!?
Unfortunately this test case is in a secure web app that is not available on the Internet. We are working on trying to get an Internet web server set up that will reproduce this problem.
Comment 6•15 years ago
|
||
We have been trying to get a test environment working with Ubuntu/Apache, but have been unable to reproduce the problem.
Also, I can no longer reproduce the problem in my environment with Gecko/20090729. I am updating my user base to this version and I am considering the bug fixed.
Thanks.
Updated•15 years ago
|
Status: UNCONFIRMED → RESOLVED
Closed: 15 years ago
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•