这个问题是关于 HTTP 标头“Accept-Encoding”的媒体类型的优先顺序，当所有的权重相同时，我的博客上的这条评论已经提示了这个问题。
Accept-Encoding 标头采用逗号分隔的浏览器可以接受的媒体类型列表，例如 gzip、deflate
还可以指定质量因子以优先考虑其他媒体类型，例如在“gzip;q=.8,deflate”的情况下，首选 deflate - 但与此问题无关。注意：带有“q=0”的类型表示“不可接受”。
RFC2616还指出应该首先对媒体类型定义的“最具体的参考”进行加权。即“text/html;level=1”应该用在“text/html”之上——这也与问题无关。
在以下情况下，哪种媒体类型具有优先权？
Accept-Encoding: gzip,deflate
两种类型都具有等效的品质因数 1，并且两种类型对浏览器都是“可接受的”——因此可以使用任何一种。我一直认为输入的第一种类型应该是“首选”，但在RFC中似乎没有针对这种特殊情况的具体示例或偏好。
我相信在 RFC 或相关 RFC 中的某处，它声明第一个是这种格式的所有字段的首选。
但是，在 gzip 与 deflate 的特殊情况下，如果可以的话，您可能应该使用 deflate，因为开销较低（页眉和页脚较少，虽然它仍然有一个 adler32 校验和，但它没有顶部的 crc32）。除此之外，它们完全相同。两者的实际数据以相同的方式压缩。这意味着放气速度更快，输出更小。这两者在重负载下的页面上变得更加重要。gzip 中的大多数额外标头都是诸如 unix 样式文件权限之类的东西，无论如何在这种情况下它们都是无用的。
确实，由于可靠性，客户端应该希望使用 gzip 服务，而由于性能，服务器应该希望使用 deflate 服务。额外的开销在每秒发生数千次时比在您加载的每个页面发生一次时更重要。
在我自己的网站上，我首先检查 deflate 并使用它，如果可以的话，然后我检查 gzip。如果我不能使用，我只是发送纯文本。我不知道您使用的是什么语言，但要做到这一点大约需要 5 行 ASP.NET。
这里没有客户端偏好。只需选择一个您（服务器端）更喜欢的。