Closed Bug 130301 Opened 23 years ago Closed 23 years ago

Cannot submit large POST requests since Mozilla 0.9.9

Categories

(Core :: Networking, defect, P1)

Product:
Core
Component:
Networking
Platform:
x86
All
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla0.9.9

People

(Reporter: shred, Assigned: darin.moz)

References

(
URL
)

Details

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

Attachments

(2 files, 1 obsolete file)

Testcase
(deleted), text/html
Details
v1 patch
(deleted), patch
Brade
: review+
rpotts
: superreview+
asa
: approval+
Details | Diff | Splinter Review
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.
URL: http://www.shredzone.de/posttest.php
Attached file Testcase (obsolete) (deleted) —
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 (deleted) —
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: nsbeta1 → nsbeta1+
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
Keywords: mozilla1.0+, regression
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 patch (deleted) — — Splinter 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: 23 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.9 → edt0.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: 23 years ago → 23 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

Creator:
Created:
Updated:
Size: