my understanding is that technically only gzipped content is supported, not gzipped transport of arbitrary content. Due to ambiguity around the word 'append' [1] in the spec, firefox adds 'identity' (aka don't compress) to the end of the list of compressions supported while most other browsers replace the list with 'identity'. Also it should be noted that this is not a user configurable header so you can't actually try to override it.

There is a second layer to the bug in that github pages should almost certainly not be sending back slices of compressed files even if gzip is listed before identity and some change to something in the github stack probably exposed the bug that was there in firefox all along.

I literally just stumbled on this last week while doing a side project that involved browser range requests so this is fresh in my head.

1. it comes down to whether it was meant that 'Accept-Encoding:identity' should be appended to the list of header values possibly overwriting the one that already was there or if 'identity' should be appended to the list of values already in the 'Accept-Encoding' header. Firefox does the latter, everyone else does the former.

works fine on safari desktop for me

Indeed, I lost the history in a shuffle, but a similar use case broke in some Firefox update, and it's the exact reason behind this comment:

https://github.com/seligman/podcast_to_text/blob/master/sear...

In my case, loading the entire file is loading a tiny bit more data, so this fallback doesn't hurt, but it's still annoying, and broke any hope I had of doing something more clever with the dataset.

The actual regression might be with githup pages where firefox was sending the same ambiguous headers the whole time but something in github's stack started interpreting them differently.