Safari 不通过接受编码：gzip，放气答案

【问题标题】：Safari not passing accept-encoding:gzip, deflateSafari 不通过接受编码：gzip，放气
【发布时间】：2017-05-08 20:03:49
【问题描述】：

我正在向云端 CDN 发出请求，并看到非常令人沮丧的行为。在 chrome 和 firefox 中，请求传递了正确的 accept-encoding:gzip, deflate 标头。

但是，safari 不会这样做，因此会获取文件的未压缩版本。这是 HTML 文档中的一个简单脚本标记。所以我不能设置标题。

同一个文档产生一个带有以下标头/浏览器组合的请求

Safari 标题

-H '缓存控制：max-age=0' \ -H 'If-Modified-Since: Mon, 08 May 2017 18:01:40 GMT' \ '

Chrome 标头

:方法:GET :path:/main-b54b8739d65dfbd36152.js ：方案：https 接受：/ 接受编码：gzip、deflate、sdch、br 接受语言:en-US,en;q=0.8 缓存控制：无缓存 pragma:no-cache

此外，相应的网络检查员在 safari 中提供了其他信息，

在 chrome 中，

此外，该请求在 safari 中花费的时间是 3 倍。 chrome 大约 55 毫秒，Safari 大约 150 毫秒。

为了保护我的隐私，我遗漏了一些信息。感谢您的帮助！

【问题讨论】：

我想即使 Safari 不在请求中发送此标头，大多数（如果不是所有）服务器仍然会提供 gzip 编码的内容，因为这是当今的标准。我刚刚验证了这一点，尽管请求中没有 accept-encoding 标头，但我确实收到了 content-encoding: gzip 的回复。但是有许多情况会阻止服务器使用压缩。此外，不要只相信 Safari 的开发工具会报告通过网络传递的大小。（作为评论，因为它只是模糊的指示，而不是经过充分研究的答案）。基本上：你确定吗？ :)
@HuguesMoreau 我添加了一些额外的细节，很高兴提供更多信息。
我认为问题不在于压缩。你应该看的是压缩：是的。这意味着在传输中使用了压缩。但是压缩率和大小在 Safari 中似乎被破坏了。甚至请求标头似乎也被误报了。为了苹果的辩护，我前段时间很难调试压缩，发现所有浏览器都以一种或另一种方式误报压缩使用。但这并没有多大帮助。如果您可以控制服务器，我建议在服务器端记录 Accept-Encoding 标头和响应大小（访问日志通常有助于后者）。

标签： javascript html amazon-web-services safari gzip

【解决方案1】：

Safari 在其开发人员工具中使用不同的命名约定，这与您的观察一致。引用自this answer，

[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 属性，看看它是否真的被压缩了。

【讨论】：