传输编码：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客户端库可能会反对实用性。

引用RFC 2616的作者之一Roy T. Fielding：

以一种不一致的方式（无论是“从不”还是“总是”）动态地更改内容编码，使得以后有关该内容的请求（例如，PUT或条件GET）无法正确处理。这就是为什么要执行动态内容编码是一个愚蠢的想法，为什么我将Transfer-Encoding添加到HTTP作为在不更改资源的情况下进行动态编码的正确方法。

来源：https : //issues.apache.org/bugzilla/show_bug.cgi?id=39727#c31

换句话说：不要进行即时的 Content-Encoding，而要使用Transfer-Encoding！

编辑：也就是说，除非您要向仅了解Content-Encoding的客户端提供压缩的内容。不幸的是，其中大多数似乎是这样。但是请注意，您离开了规范的领域，并且可能会遇到诸如Fielding提到的问题以及其他问题，例如，当涉及到缓存代理时。

RFC 2616中定义并在野外实际实现的正确用法是让客户端发送Accept-Encoding请求标头（客户端可以指定多种编码）。然后，服务器只有然后才能根据客户端支持的编码对响应进行编码（如果文件数据尚未存储在该编码中），则在Content-Encoding响应头中指示正在使用哪种编码。然后，客户端可以基于Transfer-Encoding（即chunked）从套接字读取数据，然后基于Content-Encoding（即：）对数据进行解码gzip。

因此，在您的情况下，客户端将发送一个Accept-Encoding: gzip请求标头，然后服务器可能决定压缩（如果尚未压缩）并发送一个Content-Encoding: gzip（可选）Transfer-Encoding: chunked响应标头。

是的，Transfer-Encoding标头可以在请求中使用，但只能用于HTTP 1.1，这要求客户端和服务器实现均支持chunked双向编码。

ETag唯一地标识服务器上的资源数据，而不是实际传输的数据。如果给定的URL资源更改其ETag值，则意味着该资源的服务器端数据已更改。