Why does Safari not accept GZIP compression?

Question

I have a pretty big JavaScript file here which I want to embed into my website. The HTTP server is smart enough to GZIP the file before delivering it to the browser.

However, I tested with Google Chrome and Safari.

On Chrome, it works very well. 400K go down compressed to around 100k:

BUT on Safari compression doesn't work:

The funny thing is, in gz2b.png you can clearly see that content-encoding is set to "gzip".

---

Note: I already read up on a GZIP-Bug in Safari where files cannot end on ".gz" or Safari won't accept GZIP. Since my file does not end on .gz this problem shouldn't be an issue.

Answer 1

I've run into this problem as well, while trying to optimize the load time of a website on iOS7 Safari mobile iPad.

• Encoded = uncompressed filesize, from server
• Decoded = uncompressed filesize, locally
• Transferred = uncompressed file size + headers sent and received
• Content-Length = compressed file sent, from server

Safari chose a really weird way of representing these numbers in their debugger.

Answer 2

This is a while ago but I just came across a very similar issue or maybe the source of this issue. When you compress data with gzip for safari like this:

gzip jquery.min.js

You will end up with a jquery.min.js.gz which will fail in Safari even when correctly specified as gzip encoded file stream and also when renamed to jquery.jgz as mentioned in a lot of other threads about this issue. This seems to be because the filename is encoded in the gzip file.

If you encode a gzip file like this:

cat jquery.min.js | gzip > jquery.jgz

Then you will have a file that is a few bytes smaller and does work flawlessly with Safari.

Answer 3

The HTTP headers sent to Safari say it's compressed (It has the Content-Encoding: gzip header, and it says the Content-Length is 119406 bytes) - I'd trust those more than the bold number saying 430.61 in Web Inspector. How it determines both those numbers in the top column, , I don't know.

You can get verification on how many bytes is going over the wire if you sniff the HTTP request with wireshark.