Closed Bug 1613763 Opened 5 years ago Closed 5 years ago

Firefox is the only browser not decompressing this gzipped .hdr image

Categories

(Core :: Networking: HTTP, defect)

72 Branch
defect
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 1030660

People

(Reporter: domenicobrz, Unassigned)

Details

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/79.0.3945.130 Safari/537.36

Steps to reproduce:

Visit this webpage:
https://draprpubsubtest.firebaseapp.com/bugreport.html

And look at the value printed in the console on Firefox against the result on all the other major browsers

Actual results:

This webpage https://draprpubsubtest.firebaseapp.com/bugreport.html has a very simple test script that downloads with a xhr request an .hdr image:

    var oReq = new XMLHttpRequest();
    oReq.open("GET", "https://draprpubsubtest.firebaseapp.com/env.hdr", true);
    oReq.responseType = "arraybuffer";
    oReq.onload = function (oEvent) {
        var arrayBuffer = oReq.response; // Note: not oReq.responseText
        console.log(arrayBuffer.byteLength);
    };
    oReq.send(null);

And displays on the console the length of the response as an arraybuffer

The image is gzipped, but Firefox is the only major browser that doesn't decompress the received image, the console.log shows:
459959

but the expected result tested in all other browsers is: 1607472 (the correct file size of the un-gzipped .hdr image)

Expected results:

The console log in all other browsers returns the correct response size (1607472) and the actual arraybuffer received is decompressed. Firefox doesn't decompress the received image

Similar to Bug 1597602 and duplication of Bug 1030660

Component: Untriaged → Networking: HTTP
Product: Firefox → Core
Status: UNCONFIRMED → RESOLVED
Closed: 5 years ago
Resolution: --- → DUPLICATE

I should note that this server is in fact buggy: it's changing the Content-Type when the encoding is applied, which is not how encoding is supposed to work! If it just sent the same Content-Type as it does without encoding (application/octet-stream), things would work fine.

And in particular, we should in fact decompress, but once we decompress the resulting data is not gzip data, while the site is claiming it should be.

You need to log in before you can comment on or make changes to this bug.