1686574 - Firefox doesn't do correct binary detection on mislabeled (text/plain) resources if they're compressed (gzipped)

Status: NEW

(Core :: Networking, defect, P3)

Description

[Łukasz Śliwiński]

Attachment: Print screen2021-01-13 215432.png

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:84.0) Gecko/20100101 Firefox/84.0

Steps to reproduce:

Try download .msp (Windows Installer Patch) file. And save as .msp file, not a text, not open it as .txt file.

https://knowledge.autodesk.com/support/3ds-max/downloads/caas/downloads/content/autodesk-3ds-max-2016-service-pack-2.html

Actual results:

When I click on link with .msp file to download, instead of download popup, I get the file open in tab. It looks like you try open .exe file in text editor. A lot of text and weird signs, and it once crashes Firefox too :)
When I right-click and choose, save target as... it works, but it suggests that this is txt file and save them as "name.msp.txt" and 300mb .txt . Changing name do not help after download, cause Windows Explorer crashes with this big .txt file :)

Expected results:

It should get this file as .msp (Windows Installer Patch) and ask where to download them, or just download them .exe or .msi file.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Comment 2

[Marco Bonardo [:mak]]

The server is handing the file as Content-Type: text/plain

Comment 3

[Marco Bonardo [:mak]]

Moving to Web Compatibility, hopefully we can ask Autodesk to fix the misconfiguration. We'll evaluate whether we should workaround these errors on Firefox side.

Comment 4

[:Gijs (out for now; he/him)]

Basti, do you know if/how we implement the text/plain sniffing for binary as described in https://mimesniff.spec.whatwg.org/#sniffing-a-mislabeled-binary-resource , and why it's not kicking in here (and/or, why Chrome does download rather than display)?

Comment 5

[Sebastian Streich [:sstreich]]

We do have this and it should also kick in for text/plain, in general.
The problem here is that the content is encoded. In this case the sniffed buffer is gzipped. So sniffing for characters is pointless and we abort, which means we value text/plain. We would need to stop and decompress it first.
https://searchfox.org/mozilla-central/source/netwerk/streamconv/converters/nsUnknownDecoder.cpp#877 here is where we're stopping the sniffing. :)

Comment 6

[Anne (:annevk)]

The network layer always handles decompression, right? If so, we should probably change the order of these operations. Somewhat surprised this hasn't come up before.

Comment 7

[:Gijs (out for now; he/him)]

This is still a website misconfiguration (given it is served as text/plain), but Chrome handles it so we should probably improve how we follow the spec so that this works in Firefox, too.