[Webkit-unassigned] [Bug 247421] Content downloaded with fetch() API when Concent-Encoding: gzip is set is not decompressed

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=247421

--- Comment #11 from jujjyl at gmail.com ---
Oh my god no :( that bug was reported in 2017.. five years ago.

I am the original author of the project https://s3.amazonaws.com/mozilla-games/ZenGarden/EpicZenGarden.html from bug https://bugs.webkit.org/show_bug.cgi?id=175597. (which looks like has since been taken down after I left Mozilla)

The experience from that project hosting is the very reason why all Unity content on the web today is being produced with .data.gz files with Content-Type: application/octet-stream and Content-Encoding: gzip.

I was never aware of bug 175597, and thought all this time that scheme would have been the "best practices" pre-compressed gzip encoding scheme that would work everywhere.

Specifically, the "success" of that project hosting was the reason that Unity rejected the notion of using ad hoc .jsgz, .datagz and .wasmgz suffixes for compressed files, but instead in early 2020 chose to use .js.gz, .data.gz and .wasm.gz (and a few others, like .symbols.gz) for the opportunity to enable using systematic rulesets on web servers to define precompressed assets via wildcards, e.g. set *.gz to get Content-Encoding: gzip, and set Content-Type: according to regex-matching the first extension before .gz part, where supported).

So there are now potentially thousands of Unity web game build sites out there that follow this scheme. Although Unity does default to utilizing brotli compression, which does not seem to have this issue.

Unity also offers a "Decompression Fallback" build option that enables a software JS based gzip decompressor that was all the time intended "for developers that do not have access to configuring web server hosting with the best practices Content-Type/Content-Encoding settings". It may be that the existence of this fallback option is what has caused nobody to ever before report to us that there is an issue with gzipped Unity content on Safari, but they just thought they would need to tick that checkbox for "things to work".

We have been trying to vocally get developers to not use this option, since it has a major impact to Unity game startup times. But for some reason (likely this bug), the use of that fallback option has persisted.

It does look like the issue occurs with both XHR and not limited to Fetch.

> I can't reproduce this on iOS 16 so this seems to be macOS-specific, at least as of iOS 16.

I concur, our QA reported back that they were not able to reproduce the issue on iOS either, but only on macOS Safari.

Additionally the bug occurs on old macOS Catalina 10.15.7 (19H2) test system with Safari Version 14.0 (15610.1.28.1.9, 15610, released on Sep 16, 2020), so it does not seem like any fix from 175597 would have regressed (or if it did, it has regressed before Safari 14).

All updated Unity content will now explicitly test whether the conditions of this issue are met, and guide developers to workarounds. Can't wait to see this issue being resolved in Safari, it will simplify hosting configuration headscratchers for a lot of developers!

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20221111/31723c65/attachment-0001.htm>