为什么Safari不接受GZIP压缩？ [英] Why does Safari not accept GZIP compression?

问题描述

我在这里有一个非常大的JavaScript文件，我希望将其嵌入到我的网站中。
HTTP服务器非常智能，可以在将文件传送到浏览器之前对文件进行GZIP。

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.

但是，我使用谷歌浏览器和Safari进行了测试。

However, I tested with Google Chrome and Safari.

在Chrome上，效果非常好。 400K压缩到100k左右：

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

但不起作用：

有趣的是，在gz2b.png中，您可以清楚地看到内容编码设置为gzip。

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

注意：我已经阅读了Safari中的GZIP-Bug，其中文件无法以.gz结尾，或者Safari不接受GZIP。由于我的文件没有以.gz结尾，这个问题应该不是问题。

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.

推荐答案

发送到Safari的HTTP标头说它是压缩的（它有Content-Encoding：gzip标头，它说内容长度是119406字节） - 我相信那些比Web Inspector中的粗体数字 430.61 更多。它是如何确定顶部列中的那些数字的，我不知道。

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.

如果你嗅到它，你可以验证通过网络传输的字节数使用wireshark的HTTP请求。

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

这篇关于为什么Safari不接受GZIP压缩？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！