Open Bug 1507090 Opened 7 years ago Updated 3 years ago

Some requests just never complete

Categories

(Core :: Networking: HTTP, defect, P3)

63 Branch
defect

Tracking

()

UNCONFIRMED

People

(Reporter: graefrath, Unassigned)

Details

(Whiteboard: [necko-triaged][no-nag])

Attachments

(1 file)

Attached image Firefox_bug_2.png
User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:63.0) Gecko/20100101 Firefox/63.0 Steps to reproduce: Sometimes, websites (especially PDF downloads) never load. The download window only shows "unknown time remaining" with 0 bytes received. The problem does not appear to affect IE or Chrome. For instance, `http://www.mannekenfrit.be/hauset/Manneken-kopfchen_carte-web.pdf` never loads (cf. screenshot). We use Firefox behind a Proxy with NTLM authentication. I don't know if that has anything to do with it. I have never encountered this problem without a Proxy. Additionally, this also happens with files on our own webserver. The server logs show that an HTTP request was received and responded to normally. Firefox just doesn't seem to get or process the response. But it does not time out either. I have waited about an hour. The download is just stuck at 0 bytes. It also happens with HTTPS sites, not just HTTP. If there is anything I can do to further debug this, please let me know. Actual results: Requests randomly never complete. Expected results: The requests should complete normally.
One more thing that I just discovered: if I set Firefox to open PDFs with Adobe Reader automatically instead of always asking me what to do, then the download shows a progress of 128 KiB before it gets stuck.
Component: Untriaged → Networking: HTTP
Product: Firefox → Core
Can you make a http log: https://developer.mozilla.org/en-US/docs/Mozilla/Debugging/HTTP_logging You can send the log via e-mail as well (e.g. the log may contain cookie)
Flags: needinfo?(graefrath)
I sent the HTTP log via email.
Flags: needinfo?(graefrath)
In the log I see that HttpChannel is suspended: we got all data(the data comes from cache) we have send it to the child process which diverted back. Somewhere in the middle the channel is suspended. The second half of data sits in a queue in HttpChannelParent. I do not know what has suspended the channel. I cannot reproduce the issue. Do you have any webextensions install?
Flags: needinfo?(graefrath)
I have the default plugins that come with Firefox, namely the H264 video codec and the content decryption module, and Adobe Flash Player, but it is set to run only after confirmation and most likely not involved in a PDF download. I am using the default theme and no other extension are installed. One other thing I just noticed: when I close Firefox while a suspended download is still "in progress" and then start Firefox again, the download immediately completes and opens the PDF file, even though the download should have been cancelled!
Flags: needinfo?(graefrath)
I am trying to figure out what suspend the http channel(In the log I only see it is suspended). Is it always downloads?
Flags: needinfo?(graefrath)
We are experiencing problems with websites too, but it seems less frequent. I think it might be the same problem, but I cannot be 100% certain. I can only reliably reproduce it with downloads.
Flags: needinfo?(graefrath)
graefrath, are you using nightly? I think one way to figure this out would be to add more logs to various public api of out http channels to find out where from (what script) those get called.
Assignee: nobody → honzab.moz
Flags: needinfo?(graefrath)
Priority: -- → P3
Whiteboard: [necko-triaged]
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
UNCONFIRMED, this could be an external influence (we would have way more reports like this otherwise, probably)
Status: ASSIGNED → UNCONFIRMED
Ever confirmed: false
Whiteboard: [necko-triaged] → [necko-triaged][no-nag]
I have a patch to add the necessary logging. I will push to try when try is open and link a build to test with here.
So, here [1] is a test build with added logging. Please install it and try to reproduce with logging as before. Please backup you profile first, see [2] for details if you don't know how. Thanks! [1] https://queue.taskcluster.net/v1/task/PGrrNwpzSnSGBxvLO_Ybiw/runs/0/artifacts/public/build/install/sea/target.installer.exe [2] https://support.mozilla.org/en-US/kb/profile-manager-create-and-remove-firefox-profiles
Alright, I have installed the nightly build and reproduced the issue. I sent the log via mail. Just for your information: I also tried with CNTLM to avoid Firefox having to do the proxy authentication (not included in the log), but it didn't change anything.
Flags: needinfo?(graefrath)
Junior, do you think this could be a duplicate of bug 1513135?
Flags: needinfo?(juhsu)

(In reply to Honza Bambas (:mayhemer) from comment #13)

Junior, do you think this could be a duplicate of bug 1513135?

Yes it could be.

Hello Reporter,
If it's a dup of bug 1513135, it's fixed in nightly now.
Could you verified in nightly again to see if it's fixed at your side?

Thanks

Flags: needinfo?(juhsu) → needinfo?(graefrath)

Unfortunately, the bug still exists in Nightly 66.0a1 (2019-01-07) (32-bit).

One thing to note: if I close Firefox while a download is stuck, the UI does not always ask me to confirm cancelling the download. It does delete the 0-byte part file in the downloads folder though. When I start Firefox again, it automatically completes the download successfully. I don't think it actually downloads the file again, because it works even if I cancel the proxy password dialog. This is really dazzling. I wonder where Firefox stores the file's data in the meantime.

Flags: needinfo?(graefrath)

Releasing, I didn't find time to look at this one again in months...

Assignee: honzab.moz → nobody
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: