Closed Bug 739617 Opened 9 years ago Closed 9 years ago
"Connection was reset" when uploading a large file
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120326 Firefox/13.0a2 Build ID: 20120326042011 Steps to reproduce: 0.) Post with a large file (>1MB) in a 4chan forum. Actual results: "the connection was reset" standard message is displayed and the post fails. Note: The problem appeared a few days ago. Tracing sys.4chan.org identifies 220.127.116.11 as always getting a Destination net unreachable. This may or may not be related and using ie on the same machine obtains a successful post.
I think the bug summary is incorrect for this report. The real bug is that connection to server is getting reset when submitting a form that takes some time to upload the form data, such as >1MB files. The fact that the IP is getting a Destination net unreachable result is irrelevant to Firefox/Nightly, and probably irrelevant to the bug as routers could be blocking or dropping ICMP packets to cause this, and, as stated, posting with IE works as expected. I am also experiencing this bug, Firefox 11 and IE both post fine but Nightly will throw a Connection reset 90% of the time. I have also tried resetting Nightly in about:support and increasing the timeout values in about:config but to no effect.
Thanks for reporting this! Can you reproduce in http://support.mozilla.org/en-US/kb/Safe%20Mode ? If it's indeed a regression from the current release, it would be most helpful if someone found the regression window: https://quality.mozilla.org/docs/bugzilla/guide-to-triaging-bugs-for-firefox/finding-a-regression-window/ Can this be reproduced by someone without a 4chan account? Could you provide the detailed steps to reproduce?
Summary: Tracing sys.4chan.org identifies IP as always getting a Destination net unreachable. → "Connection was reset" when posting a large file in a 4chan forum
It still occurs in Safe Mode, I will try and find the regression window later. No account is needed to post on 4chan.org, the best way to test would probably be to go to a "safe" board like the Technology board (known as /g/) and try to post a new thread with an image larger than 3MB, because that is the image size limit for the board, if the bug is reproduced you will get a connection reset page, if you do not then you will get a post response saying the image was too large.
I experienced this bug on - dropbox - tineye and various "upload" site. I checked both HTTPS and HTTP connection. I tested on Firefox Nightly, Firefox Aurora, Firefox Release on a Fedora x86_64, over two different internet connections, with three different profiles, and in safe mode as well. Messing in about:config with network.http.pipelining and related values; with network.http.keep-alive.timeout and related values; with network.http.max-connections and related values I obtained to "raise" the "upload limit" before the "Connection was reset" message (actually, I can get it doubled, but it won't solve the issue). If this can be confirmed the bug could be renamed to “"Connection was reset" when uploading large files”
I believe I found the build when the regression window for this bug, 2012-03-24-03-11-00-mozilla-central is the first earliest build that I tested that displayed the bug. Though this is the first time I have looked for a regression window so I am not sure if I am checking the right builds, I was downloading the firefox-14.0a1.en-US.win32.zip files to test if it makes any difference.
(In reply to yesyoucanspamme from comment #4) > I tested on Firefox Nightly, Firefox Aurora, Firefox Release Errata corrige: this bug is not actually present in Firefox Release (11), nor in Firefox Beta (12). I've tested again with new blank profiles (and clean "about:config") , this issue shows up e.g. uploading to Dropbox with Firefox Aurora (13) and Firefox Nightly (14). Always reproducible.
Ah, I believe I found the revision itself. http://hg.mozilla.org/mozilla-central/rev/52efc30fbfec Increasing the value of network.http.pipelining.read-timeout in about:config affects this. Basically, the default value of 10000 is causing the connection to reset after 10 seconds. Reading the patch summary it would suggest that the connections are getting mistakenly detected as stalled.
But even if you turn off the pipelining the same error will occur.
(In reply to bitcores from comment #5) > I believe I found the build when the regression window for this bug, > 2012-03-24-03-11-00-mozilla-central is the first earliest build that I > tested that displayed the bug. I can confirm that 2012-03-24 shows the bug and 2012-03-23 does not show the bug, Linux x86_64 builds. So, it's there. http://forums.mozillazine.org/viewtopic.php?f=23&t=2447831
(In reply to bitcores from comment #7) > Ah, I believe I found the revision itself. > > http://hg.mozilla.org/mozilla-central/rev/52efc30fbfec > > Increasing the value of network.http.pipelining.read-timeout in about:config > affects this. Yes, I noticed that but still did not fix. NS_ERROR_NET_RESET is mentioned in https://bugzilla.mozilla.org/attachment.cgi?id=597531&action=diff for bugfix #739617 first introduced in 20120324 builds, but many similar bufixes were delivered with that build; Patrick McManus seems the one who can help here
I'll take a look at this next week and ensure the timeout timer is kicked during upload
Component: Untriaged → Networking: HTTP
Product: Firefox → Core
QA Contact: untriaged → networking.http
I personally cannot reproduce the issue on Aurora. See bug 741310 for more clear STR.
reproducible on mediafire as well.
see bug 741106 comment 5 for some analysis
* nsHttpPipeline::PipelinePosition() returning of a constant 2 with an empty response list reflects a misunderstanding that the pipeline object is not always used in an active pipeline (but rather exists so that a pipeline can be extended from it). Instead it should derive the depth from the request queue in that case, or return 0 (no pipelining) if both queues are empty. That is the source of this bug, because it casues the PUT/POST to be pereceived as a pipelined request subject to the timer when in fact it is not pipelined (nor should it be). * Honza's intuition is right, that timer ought to be higher to start with. I tripled it to 30sec. * The timeout can now be configured to 0 to mean don't timeout in the usual way * added a missing space in a related log
Assignee: nobody → mcmanus
Status: NEW → ASSIGNED
Attachment #611493 - Flags: review?(honzab.moz)
(In reply to Patrick McManus [:mcmanus] from comment #18) > Created attachment 611493 [details] [diff] [review] > patch 0 > > * nsHttpPipeline::PipelinePosition() returning of a constant 2 Looks like this got in even though the patch had been r- and questions to the review comments were never answered: https://bugzilla.mozilla.org/show_bug.cgi?id=665094#c1 > @@ +160,5 @@ > > + nsAHttpTransaction *trans = Response(0); > > + if (trans) > > + return trans->PipelineUsed(); > > + return 2; > > +} > > As well here... > > Can you please explain why this method should return 2 if there is not any > transaction response pending? >
(In reply to Honza Bambas (:mayhemer) from comment #19) > (In reply to Patrick McManus [:mcmanus] from comment #18) > > Created attachment 611493 [details] [diff] [review] > > patch 0 > > > > * nsHttpPipeline::PipelinePosition() returning of a constant 2 > > Looks like this got in even though the patch had been r- and questions to > the review comments were never answered: No, it got r+ as part of a different patch: Bug 597684. What a mess.. :)
Comment on attachment 611493 [details] [diff] [review] patch 0 Review of attachment 611493 [details] [diff] [review]: ----------------------------------------------------------------- r=honzab
Attachment #611493 - Flags: review?(honzab.moz) → review+
Thanks honza.. I'll check it in after try approves of it assuming that goes ok. Anyone that wants to use a try build: https://tbpl.mozilla.org/?tree=Try&rev=2dcf8cea285d
yesyoucanspamme: if you still see this on Aurora (13), please file a separate bug.
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla14
(In reply to Nickolay_Ponomarev from comment #23) > yesyoucanspamme: if you still see this on Aurora (13), please file a > separate bug. While I experienced the bug on Aurora (13.0a2) as well (as outlined in Comment #1), I'm not able to reproduce it on Aurora any more. (In reply to Nickolay_Ponomarev from comment #12) > It's a bit strange that the problem was introduced in 2012-03-24 on > mozilla-central (14) (per comment 5), yet this is also happening on Aurora > (13) (comment 6), which was branched earlier. Setting tracking-firefox13? > just in case there was another regression earlier. It seemed strange to me as well, given that regression window. Anyway, I'm not able to reproduce any more in Aurora, as Comment #14 exposed. I'm posting in this RESOLVED FIXED bug again just to confirm this. Many thanks to McManus.
You need to log in before you can comment on or make changes to this bug.