Safari不能传递accept-encoding:gzip, deflate。

Question

我正在向Cloudfront CDN发出请求，并看到非常令人沮丧的行为。在Chrome和Firefox中，请求通过了正确的accept-encoding:gzip, deflate头部。

然而，Safari不这样做，因此获取文件的未压缩版本。这是HTML文档中的简单脚本标记。所以我不能设置头部。

相同的文档会生成具有以下标头/浏览器组合的请求

Safari头部

-H 'Cache-Control: max-age=0' \ -H 'If-Modified-Since: Mon, 08 May 2017 18:01:40 GMT' \ '

Chrome头部

:method:GET :path:/main-b54b8739d65dfbd36152.js :scheme:https accept:/ accept-encoding:gzip, deflate, sdch, br accept-language:en-US,en;q=0.8 cache-control:no-cache pragma:no-cache

此外，各自的Web检查器提供了额外的信息，在Safari中,在Chrome中。

另外，在Safari中，请求需要3倍于Chrome的时间。大约是55毫秒在Chrome中和150毫秒在Safari中。

我删除了一些信息以保护我的隐私。感谢您的帮助！

- dandlezzz

---

我认为，尽管Safari在请求中没有发送此标头，但大多数服务器仍然会提供gzip编码的内容，因为这是现今的标准。我刚刚验证了这一点，尽管请求中没有accept-encoding标头，但我确实收到了一个带有content-encoding: gzip的回复。但是，有许多情况可能会阻止服务器使用压缩。此外，不要仅仅相信Safari的开发工具报告的传输大小。（作为评论，因为这只是模糊的指示，而不是经过深入研究的答案）。基本上：你确定吗？ :) - Hugues M.

@HuguesMoreau 我已经添加了一些额外的细节，并且很乐意提供更多信息。 - dandlezzz

我认为问题不在于压缩。你应该看的是“已压缩：是”。这意味着在传输中使用了压缩。但在Safari中，压缩率和大小似乎出现了问题。甚至请求头也似乎被错误地报告了。为了辩护苹果，我曾经花费了很多时间来调试压缩，并发现所有浏览器都以一种或另一种方式错误地报告了压缩使用情况。但这并没有太大帮助。如果您对服务器有控制权，我建议在服务器端记录Accept-Encoding头和响应大小（访问日志通常有助于后者）。 - Seva

Answer 1

Safari在其开发者工具中使用不同的命名约定，这与您的观察结果一致。引用这个答案的话：

[1] Encoded = uncompressed filesize, from server
[2] Decoded = uncompressed filesize, locally
[3] Transferred = uncompressed file size + headers sent and received
[4] Content-Length = compressed file sent, from server

请检查 content-length 属性，以确定是否已经进行了压缩。

- TheChetan