1597602 - XHR and document requests to gzip'd content return gzipped binary blob / offer to save as archive, instead of displaying as text (content-encoding: gzip and content-type: application/x-gzip)

Status: RESOLVED DUPLICATE of bug 1030660

(Core :: Networking: HTTP, defect)

Description

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

Steps to reproduce:

I am the developer of a website "https://www.friedfiction.com/" that is having a problem with the Firefox Browser. The website retrieves UI files, such as html templates, css, js files from the hosting service Firebase. It is having problems with retrieving files of type .mst that are downloaded via a XHR request. (.mst files are html fragments that are handled by the mustache.js javascript library) These mst files are stored unencrypted on the hosting site, similar to the css and js files, so I am not clear why they are being treated differently.

Previously, you could see this by visiting the website, the content returned for these .mst files was encrypted and cannot be parsed.

If you open this site up in either Chrome or Edge, you should be able to see the expected result.

You can view a single .mst file using this extension:
https://friedfiction.com/fragments/welcome.mst

Firefix will download this as an encrypted .gz file, while Chrome will download and show the plain text version of the file.

The site was changed to return content-type: text/plain, which has worked around the Firefox issue.

Actual results:

The content returned by the GET *.mst requests are being returned encrypted when using the Firefox browser. This is not the case for Chrome or Edge.

Expected results:

The .mst files should have been retrieved as clear text and displayed normally as in Firefox or Edge.

Comment 1

[Gingerbread Man]

Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:72.0) Gecko/20100101 Firefox/72.0
20191117213438

GET https://friedfiction.com/fragments/welcome.mst
200 OK
    content-encoding: gzip
    content-type: application/x-gzip
    …

Firefox saves a compressed — not encrypted — archive named welcome.mst.gz while Vivaldi saves a plain text file named welcome.mst

Comment 2

[David]

I was able to fix this bug by changing the content-type header to "text/plain" for the mst file types on my hosting provider.

Comment 3

[David]

Sorry the explanation should be changed to say "compression".

Comment 4

[Gingerbread Man]

(In reply to David from comment #2)

I was able to fix this bug by changing the content-type header to "text/plain" for the mst file types on my hosting provider.

Thank you for the update. I'll leave this open since behavior differs in Chromium-based browsers and it might be a duplicate of an existing bug report (I can't tell if that's the case and someone else will have a look at this).

Comment 5

[David]

Is it possible to edit the description, since the provided example no longer produces the exception, and to change the confusion over encryption/compression?

Comment 6

[:Gijs (he/him)]

I've adjusted the description.

This looks similar to bug 1560525 to me. Hopefully the networking folks can take a look?

Comment 7

[Kershaw Chang [:kershaw]]

Hi David,

Could you provide another example that can reproduce this issue?
It seems https://friedfiction.com/fragments/welcome.mst is not working anymore.

Thanks.

Comment 8

[David]

I added a test.mss file that will demonstrate:

https://fried-fiction-firebase.firebaseapp.com/fragments/test.mss

I don't understand why, but unknown file extensions are being sent as "content-type: application/x-gzip", although Chrome and Edge seem to have no problem with this.

Comment 9

[:Gijs (he/him)]

Re-surfacing this for :kershaw. :-)

Comment 10

[Kershaw Chang [:kershaw]]

I think the problem is about this function. According to bug 1030660, I think we should remove this quirk.

Comment 11

[Dragana Damjanovic [:dragana]]

(In reply to Kershaw Chang [:kershaw] from comment #10)

I think the problem is about this function. According to bug 1030660, I think we should remove this quirk.

Kershaw, have you tested this?
I am not sure if we will do the right think if we remove ClearBogusContentEncodingIfNeeded?

Comment 12

[Dragana Damjanovic [:dragana]]

(In reply to Dragana Damjanovic [:dragana] from comment #11)

(In reply to Kershaw Chang [:kershaw] from comment #10)

I think the problem is about this function. According to bug 1030660, I think we should remove this quirk.

Kershaw, have you tested this?
I am not sure if we will do the right think if we remove ClearBogusContentEncodingIfNeeded?

Sorry this is xhr, this will work.

but this responses have:
content-encoding: gzip
content-type: application/x-gzip

this is wrong. There were/probable still are server that are sending this wrong.
I am wondering if we should remove ClearBogusContentEncodingIfNeeded only for fetch and xhr?

Comment 13

[Kershaw Chang [:kershaw]]

(In reply to Dragana Damjanovic [:dragana] from comment #11)

(In reply to Kershaw Chang [:kershaw] from comment #10)

I think the problem is about this function. According to bug 1030660, I think we should remove this quirk.

Kershaw, have you tested this?
I am not sure if we will do the right think if we remove ClearBogusContentEncodingIfNeeded?

Yes, I've tested removing ClearBogusContentEncodingIfNeeded() with this link. The result is that test.mss can be saved as a plain text file, not a gziped file.

Comment 14

[Honza Bambas (:mayhemer)]

So, I'll duplicate this to bug 1030660 and raise a priority on that one, because this seems to be hit lately more often.