[Bug]: Firefox Won't Open WACZ from Remote Server because the Size of the File is Not Accessible about replayweb.page HOT 2 OPEN

Is the web server not returning a header or something that replayweb.page is expecting?

@edsu recently wrote a good forum post on exactly this problem for another user experiencing the same thing. I can partially replicate this behavior by trying to download the file in the browser, it will not be able to display a progress bar or time remaining estimate (in either Firefox or Chrome)!

... However, using curl --head returns this, which includes Content-Length so that's curious.

➜  ~ curl --head https://digital.lib.utk.edu/demo/abolition_now_test.wacz
HTTP/1.1 200 OK
Date: Mon, 29 Apr 2024 20:13:18 GMT
Server: Apache
Last-Modified: Wed, 24 Apr 2024 13:39:28 GMT
ETag: "88e8f59-616d7ccb8d565"
Accept-Ranges: bytes
Content-Length: 143560537
Vary: Accept-Encoding
Access-Control-Allow-Origin: *

Either way, if the file works fine locally it's probably not that, most likely a server config issue?? Can replicate it working in Chrome though.

from replayweb.page.

The issue is unfortunately due to a bug/incorrect handling in Firefox. Chrome and Safari correct add Accept-Encoding: identity (the default) header when a range request is sent, allowing the server to return content-length. Unfortunately, Firefox always sends Accept-Encoding: gzip, deflate, br, zstd, which causes the header to return a compressed version of the WACZ, which is not what we want.

Barring the fix in Firefox, I think the best option is to ensure your server ignores the Accept-Encoding header for WACZ files.

You can see that if you do curl --head -H "Accept-Encoding: gzip, deflate, br, zstd" https://digital.lib.utk.edu/demo/abolition_now_test.wacz, there will be no content-length. Unfortunately, it seems there's no way to prevent Firefox from sending this header. (Will open a bug in firefox).

from replayweb.page.