1510390 - Downloads of application/x-msdownload create 0 byte file and no TCP connection

Status: RESOLVED DUPLICATE of bug 1513135

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

Description

[David]

Attachment: Screen Shot 2018-11-27 at 11.43.39 AM.png

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.110 Safari/537.36

Steps to reproduce:

Try downloading file from Cloudfront (http://d3gcli72yxqn2z.cloudfront.net/connect/v4/bin/IBMAsperaConnect-ML-3.8.1.161274.msi). 

We tested that using an anchor to download or just pasting the address in the URL bar fails after a few downloads (usually second and beyond). New windows will allow another, but not new tabs.

Using version: 63.0.3 on Windows ONLY (tested on Windows 7 SP1) (not reproducable on Mac)


Actual results:

Usually it works the first time (not always) and then it just created a 0 byte file and sits on Unknown time left.  Can click this link in a web page or just go to it. Failed on HTTP or HTTPS.

Using Wireshark we verified that it never actually makes a TCP connection when it gets into this state.


Expected results:

File should download.

Comment 1

[David]

Attachment: Windows 10 error

Verified that bug exists on Windows 10 (build 17134-sr4).  However, it took more successful attempts before bug was shown (around 6)

Comment 2

[David]

Attachment: VScode with same issue

After further research we have seen it only happens on MSI and executables (binary files with .exe downloaded fine and did not reproduce).

Comment 3

[David]

Seems to only show issue when the content-type is application/x-msdownload.  EXE files that show as octet stream do not have the issue. For our server our workaround may be to not report as application/x-msdownload.

Comment 4

[Matthias Versen [:Matti]]

Works for me with the URL from comment#0.
I have tested Firefox63 and Firefox 65 nightly on windows10

Did you assign a helper application for that content-type under preferences/general/applications ?

Comment 5

[David]

Attachment: Visual Studio Download

Clean install on new Windows 10.  We did not adjust any settings. I attached my settings.

Going to download Visual Studios:

https://code.visualstudio.com/docs/?dv=win

Clicking `direct download link` made the bug appear after the second try. Updated screenshot added as well.


Visual studio download is an EXE file not an MSI file in this case; but we checked headers and it was x-msdownload.

Comment 6

[David]

Attachment: Firefox Application Settings

Comment 7

[Matthias Versen [:Matti]]

I always get a full download in 10 of 10 tries with Firefox 65 nightly on windows10.

Do you have third party Antivirus/security software installed ?

Comment 8

[David]

On Windows 7 we tried disabling Microsoft Defender and still had same issue.  

We got a VM from Modern IE and are using new Firefox download.

https://developer.microsoft.com/en-us/microsoft-edge/tools/vms/

(MSEdge on Win10).

Our QA team originally found this on a Windows 7 machine in VSphere and we have been trying to replicate the issue and were able to in Win10 and Win7 image from Modern IE.

So maybe a VM only issue? Which seems weird...

Comment 9

[alex.korchemniy]

I reproduce this issue with other URLs.

https://d3gcli72yxqn2z.cloudfront.net/connect/v4/bin/IBMAsperaConnectInstaller-3.8.1.161274.dmg
https://d3gcli72yxqn2z.cloudfront.net/connect/v4/bin/ibm-aspera-connect-3.8.1.161274-linux-g2.12-64.tar.gz

Maybe some kind of TLS bug.

Comment 10

[alex.korchemniy]

Attachment: FirefoxDlHange2.procmon.zip

Comment 11

[alex.korchemniy]

Attachment: firefox-log-1.log

I captured the download failure under Process Monitor and used symbols to poke around Firefox source code to find logging flags. 

NSPR_LOG_MODULES=timestamp,BackgroundFileSaver:5,nsThread:5,NetworkPredictor:5,nsIOService:5,nsJarProtocol:5,nsPrefetch:5,nsStreamCopier:5,nsStreamPump:5

Comment 12

[Matthias Versen [:Matti]]

Again, this is only happening on your systems and not on my native Windows10 system or on the billions of Firefox installations on native systems.

application/x-msdownload in Firefox should have the same handling as application/octet-stream and if only application/x-msdownload doesn't work right and other content-types are working I think it can be only caused by a bug in the VM or external software.

External Software can be active Antivirus Software as example or something that modifies the Firefox profile or something that corrupts the Firefox networking cache.

Comment 13

[Ivan Vanyushkin]

I confirm this bug. Network Monitor shows "No headers for this request". Download manager: "Unknown time left — 0 bytes (0 bytes/sec)". File of size 0 is created on disk.

I've tested on fresh profile, no antivirus or firewall. It happens on 1 of 10 downloads, on different Content-Types, http/1.1 and http/2, different sites. Maybe it is somehow related to CDN or https.

I've added Fiddler as a proxy, problem request successfully finishes in Fiddler, as usual. So, file is really downloaded by proxy. But Firefox doesn't start saving this file.

Comment 14

[Masatoshi Kimura [:emk]]

Dup of bug 1513135?

Comment 15

[Ivan Vanyushkin]

(In reply to Masatoshi Kimura [:emk] from comment #14)

Dup of bug 1513135?

Yes, the same bug, and it is fixed in Firefox 65. Thank you.