2
传输编码：gzip与内容编码：gzip
关于是否要做事，目前的状况是什么 Transfer-Encoding: gzip 或一个 Content-Encoding: gzip 当我要允许带宽有限的客户表示他们愿意接受压缩响应并且服务器最终决定是否压缩时。 后者就是例如Apache的mod_deflate和IIS所做的，如果让它负责压缩的话。根据要压缩的内容的大小，它将执行额外的操作Transfer-Encoding: chunked。 它还将包含一个Vary: Accept-Encoding，已经暗示了该问题。Content-Encoding似乎是实体的一部分，因此将Content-Encoding金额更改为实体的变化，即，不同的Accept-Encoding标头意味着例如缓存无法使用其在其他方面相同的实体的缓存版本。 我是否错过了一个明确的答案（并且没有在某些Apache新闻组的长线程中隐藏在消息中）？ 我目前的印象是： 实际上，传输编码将是正确完成现有服务器和客户端功能的内容编码的正确方法 由于内容编码的语义含义，它带来了两个问题（服务器ETag透明压缩响应时，服务器应该如何处理？） 原因是“鸡蛋”：浏览器不支持它，因为服务器不支持，因为浏览器不支持 因此，我假设正确的方法是Transfer-Encoding: gzip（或者，如果我另外对主体进行分块，它将变成 Transfer-Encoding: gzip, chunked）。在这种情况下，没有理由触摸Vary或ETag任何其他标头，因为这是传输级的事情。 目前，我不太在乎的“逐跳”性质Transfer-Encoding，这是其他人首先关注的问题，因为代理可能会解压缩并转发给客户端。但是，如果原始请求具有正确的Accept-Encoding标头，则代理可能会按原样转发（压缩）它，对于我所知道的所有浏览器来说，都是给定的。 顺便说一句，这个问题至少存在十年了，请参阅例如 https://bugzilla.mozilla.org/show_bug.cgi?id=68517。 任何对此的澄清将不胜感激。无论是从符合标准的方面还是从实用性方面而言。例如，仅支持透明“ Content-Encoding”的HTTP客户端库可能会反对实用性。