Closed Bug 130301 Opened 22 years ago Closed 22 years ago

Cannot submit large POST requests since Mozilla 0.9.9

Categories

(Core :: Networking, defect, P1)

x86
All
defect

Tracking

()

VERIFIED FIXED
mozilla0.9.9

People

(Reporter: shred, Assigned: darin.moz)

References

()

Details

(Keywords: dataloss, regression, Whiteboard: [adt2])

Attachments

(2 files, 1 obsolete file)

Mozilla 0.9.9 cannot send large POST requests. They don't need to be HUGE, just
about 10KB is already large enough. For example, try to submit this PHP page:

<html>
<body>
<?php if(isset($text)) print("Got it. Length ". strlen($text) ."<br>"); ?>
<form action="posttest.php" method="post">
  <textarea name="text" rows="10" cols="80"><?php
    for($i=0; $i<11352; $i++) {
      if(($i % 70) == 69)
        print "\n";
      else
        print "A";
    }
  ?></textarea><br>
<input type="submit">
</form>
</body>
</html>

If this form is submitted on Mozilla 0.9.9, no POST request is sent to the
server and Mozilla waits for a server response forever... If you decrement the
for limit to 11351, the POST will be successful, though.

Everything is working fine as soon as I switch back to Mozilla 0.9.8.

I am sure this is no PHP related bug because we also have this problem with
other servers running Perl CGIs. Also, there will be no POST request in the
server logfile when the critical size has been reached, so the problem must be
on client side.

There seems to be other POST related problems with Mozilla 0.9.9. At least, I
was unable to login to bugzilla.mozilla.org with 0.9.9.
Summary: Cannot submit large POST requests → Cannot submit large POST requests since Mozilla 0.9.9
ccing the form sub crew
Added an URL for a test page.

Note that I had to increase the amount of data a little, in order to let it fail
on RedHat 7.2 too (my first report was about several SuSE 7 systems). The test
page also provides a link to see its source code. You may want to verify it on
your own server.
Attached file Testcase (obsolete) —
This uses JavaScript to populate the textarea, and submits to a form that shows
the value.  It is working for me, can y'all try it out?
Sorry, still doesn't work for me. Mozilla 0.9.9 is waiting for a server response
forever. Other browsers are doing fine.

I want to point out that besides me, all my coworkers experienced this problem
on different SuSE 7 systems. At home (different network), I can reproduce it
with RedHat 7.2. When going back to Mozilla 0.9.8, everything is working fine
again for everyone. It is Mozilla 0.9.9 Build ID 2002031008.
Attached file Testcase
Hmm, now it's happening for me too.  Since I wrote the testcase anyway, here's
one that will submit to either place.
Attachment #73744 - Attachment is obsolete: true
This could be related to Bug 130430.

On Solaris, it seems to be sending the POST, but with no parameters :-(
*** Bug 130512 has been marked as a duplicate of this bug. ***
Much as I hate to add more to my nsbeta1 plate, this is worse than crashers.
Assignee: alexsavulov → jkeiser
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: nsbeta1
I've got another testcase (from bug 130512) at:
 
    http://www.suspectclass.com/~sgifford/moztest/bigform-test.html
 
Load this page (it takes a long time to render (bug 39573) but will 
eventually), then scroll to near the bottom and press "Save
work so far and continue editing".

This test case isn't nearly as refined, but I thought I'd mention it.  
 
tcpdump indicates that Mozilla sends part of the request (about the first
20%), then just sits there...

*** Bug 128544 has been marked as a duplicate of this bug. ***
I reported what looks like this bug against 2002030108 as bug 128544, although
I'd noticed it with an earlier build.  My tests were on a relatively slow Debian
"unstable" system, against
<http://www.wikipedia.com/wiki/Wikipedia%3ASandbox&action=edit>, and I can't
duplicate it under Windows 2000.

Wikipedia is running PHP too, for another data point.
*** Bug 130526 has been marked as a duplicate of this bug. ***
I noticed this with 0.9.9 on Red Hat 7.2. Small submissions work; larger submissions do not.

As soon as I went back to 0.9.8, I could submit what I needed to submit.

I tried the nightly build from 13 March 2002, and it still displays the same problem.
Yes, this isn't just a PHP thing. I can reproduce the error with perl-based CGI
scripts. Sending a large amount of data through a POST request causes the
browser to hang. Going back to 0.9.5 works just fine. Redhat 7.2.
WFM using 2002031104, will update now to see if it still works.
Priority: -- → P2
Maybe it's a little hint for bug chasing... Accidentally I found out that this
was already broken on Mozilla nightly 2002022608.
What would be *really* interesting to know is if the build from the 2/14/2002
exhibits the problem.  I'm betting it doesn't.  Bug 120682 is the assumed
culprit at the moment, and that was checked in on the 15th (actually the build
from the morning of the 15th should work too; the 16th and on should be broken).
I've noticed this bug is more likely to occur when the http server is remote
rather than local.  For example in one case running the same version of a wiki
remotely and locally, posting the same page content, the post only fails with
the remote server.
nsbeta1+
Keywords: nsbeta1nsbeta1+
Target Milestone: --- → mozilla1.0
jkeiser: sadly the build from 15th of february can't be downloaded anymore from
the ftp-server :-(   
The oldest are the builds from the 20th.
adt1 per adt triage
Whiteboard: [adt1]
This bug is also triggered by mailman, which is a python app: The "approve
pending postings form" (admindb) sends large POSTs.

BTW the beginning of the POST does go through, as far as I can tell. If I hit
the stop button, 2880 more bytes of input arrive, and then mailman does process
the beginning of the form, but this is of course dependent on the cgi behavior
on EOF.
************************
this is a linux only bug
************************

I debugged the streams down to nsMIMEInputStream::ReadSegCb on linux and
everything looks ok from the form submission perspective. Suspecting some necko
issues.

Please also check the dependency of bug 133436 and reassign or dup if necessary.
Assignee: jkeiser → new-network-bugs
Blocks: 133436
Component: Form Submission → Networking
QA Contact: vladimire → benc
Adding dataloss keyword.
Keywords: dataloss
mozilla1.0+, regression, ->darin.
Assignee: new-network-bugs → darin
Severity: major → critical
Status: NEW → ASSIGNED
Priority: P2 → P1
ok, the problem is with the impl of nsMultiplexInputStream::ReadSegments.  it
does not properly handle |read < aCount| after the call to |stream->ReadSegments|.

working on a fix...
Attached patch v1 patchSplinter Review
fixes nsMultiplexInputStream::ReadSegments
Comment on attachment 76634 [details] [diff] [review]
v1 patch

r=brade
Attachment #76634 - Flags: review+
Good catch! Though i don't really understand how we could ever run into this 
situation? Doesn't it mean that the string-stream is doing bad things?

The first part of the patch seems like a performance issue if we ever want to 
use this stream other then in form-submission. Is it really needed?
*** Bug 134051 has been marked as a duplicate of this bug. ***
sicking: nope.. the string stream code is correct.  the |writer| passed into
ReadSegments does not need to consume all of the data you give it.  in this
case, nsMultiplexInputStream was making the assumption that the |writer| would
consume all of the data passed to it (or at least empty the input stream). 
neither is a requirement.  with this particular bug, the |writer| is a socket
output stream.  it may only be able to write part of the post data at a given
time (in this case it was not able to write the full 16075 in one go).
Comment on attachment 76634 [details] [diff] [review]
v1 patch

a=asa (on behalf of drivers) for checkin to the 1.0 trunk
Attachment #76634 - Flags: approval+
*** Bug 134112 has been marked as a duplicate of this bug. ***
*** Bug 134285 has been marked as a duplicate of this bug. ***
Changing to ADT2 per ADT triage. This is Linux only, and the URLs submitted
don't look all that interesting.
Whiteboard: [adt1] → [adt2]
actually, this bug is not linux only, and there is nothing special about the
sites on which this bug has been demonstrated.  this is an cross-platform bug
that could strike whenever the user tries to submit a large form or whenever the
network is sufficiently slow or congested.  i'd expect modem users to hit this
bug frequently.
OS: Linux → All
I agree with Darin. This is a very important issue and it affects a lot the form
submission.
Not to pile on, but this is a very important bug.  I think the term "large" is
throwing you off here.  I personally know 5 people running pre 0.9.9 builds
because this bug keeps them from using their webmail.  I personlly can't use it
because of my web base content managment system.  Large is about 4 normal
paragraphs in a textarea, about 4 times the size of the post.  BTW, don't know
why network speed would have anything to do with it, I see this problem over a
local 100mbit network on Linux.
Here's another testpage which may be convenient: http://hoppa.com/post.pl
My RH7.2/0.9.9 hangs with > 11500 bytes, Windows OK.
http://bugzilla.mozilla.org is another site which sees this bug.  Uploading
moderately large comments during attachments I have hung forever.
Greg: by "slow or congested," i really meant a socket that can only accept data
in small increments.  this may be the case for a variety of reasons (e.g., small
maximum-segment-size due to the limitations of some router).  for whatever
reason the connection to shredzone.de is very fast and wide... i was able to
write nearly 12k to it in one shot.  that's why it appeared to require a "large"
form-value to repro the bug.
The URL I submitted is just a test case. It is reduced to a very minimum, in
order to show that the bug already hits on extremely simple forms.

We found this bug at the company I work for. We do most of our development work
by a web based SDK. With Mozilla 0.9.9 we were unable to do our work because of
this bug, so we had to downgrade to 0.9.8. This was the trigger why I wrote the
bug report. I am just unable to grant everyone access to our SDK, so I reduced
the problem to a simple test HTML form.

I think this bug is really critical! This is the reason why I kept running
0.9.8, and I will definitely abandon Mozilla if it is still an issue in 1.0,
because it renders this browser unusable for me.
richard: no worries... we already have a fix that is ready to land.  i'm just
waiting for the tree to open... we had some really nasty checkins Thursday night
which prevented me from checking in the fix yesterday (and the tree is still
closed today!).  at any rate, i don't think jaime realized how close this bug
was to being fixed (or even how significant this bug is) when he downgraded its
importance.  this bug will be fixed in mozilla 1.0 :-)
fixed-on-trunk
Status: ASSIGNED → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
*** Bug 134718 has been marked as a duplicate of this bug. ***
*** Bug 134983 has been marked as a duplicate of this bug. ***
reopening this for possible checkin on the 0.9.9 branch.  this is a very nasty
bug that embedders of the mozilla 0.9.9 branch would most likely appreciate
having fixed.
Status: RESOLVED → REOPENED
Keywords: edt0.9.9
Resolution: FIXED → ---
Target Milestone: mozilla1.0 → mozilla0.9.9
actually minusing for 0.9.9 as most embeddors that I'm aware of will be
transitioning to 1.0 soon enough.
Keywords: edt0.9.9edt0.9.9-
*** Bug 135362 has been marked as a duplicate of this bug. ***
hi,

i think i am experiencing this problem or one very similar. 

i have constructed a http proxy routine in perl which works with HTTP GET but
not HTTP POST.  

when i trigger the form.submit with javascript link i get a log entry on the
perl proxy but no Content and a Content length Zero ( WRONG!! i have 3 form inputs).

when i trigger the form.submit with a mouse click submit button i get no action
at all. literally =)  

the form has no action attribute and is located at www.timecircle.com/timers 
the perl code is available on request.   

hope this helps.. 
please file that as a separate bug
I am moving back as resoved fixed. But if any embeddors live onthe branch very
long it might need to be pushed to 099.
Status: REOPENED → RESOLVED
Closed: 22 years ago22 years ago
Resolution: --- → FIXED
I just checked the nightly build ID 2002040908. My test URL, as well as our
company's SDK, is working fine again. :-) Thanks for the great job!

If somebody still needs my test page, please tell me, or I will remove it on Friday.
qa to tever (this is HTTP right?)
QA Contact: benc → tever
*** Bug 139700 has been marked as a duplicate of this bug. ***
marking verified per reporters comments
Status: RESOLVED → VERIFIED
*** Bug 143648 has been marked as a duplicate of this bug. ***
*** Bug 133436 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: