http - 传输编码:gzip 与内容编码:gzip

Question

要不要做，目前情况如何

Transfer-Encoding: gzip

或一个

Content-Encoding: gzip

当我想让客户使用例如限制带宽以表示他们愿意接受压缩响应，服务器最终决定是否压缩。

后者就是例如Apache 的 mod_deflate 和 IIS 可以，如果你让它负责压缩的话。根据要压缩的内容的大小，它将执行额外的 Transfer-Encoding: chunked。

它还将包含一个 Vary: Accept-Encoding，它已经暗示了这个问题。 Content-Encoding 似乎是实体的一部分，因此更改 Content-Encoding 相当于更改实体，即不同的 Accept-Encoding header 表示例如缓存不能使用其他相同实体的缓存版本。

是否有我错过的明确答案(并且没有隐藏在某些 Apache 新闻组的长线程中的消息中)？

我目前的印象是:

• 传输编码实际上是执行现有服务器和客户端实现主要使用内容编码完成的工作的正确方法
• Content-Encoding，由于其语义含义，带来了一些问题(当服务器透明地压缩响应时，服务器应该如何处理 ETag？)
• 原因是先有鸡还是先有蛋:浏览器不支持是因为服务器不支持，因为浏览器不支持

所以我假设正确的方法是 Transfer-Encoding: gzip(或者，如果我另外分块 body，它 would become Transfer-Encoding: gzip, chunked)。在这种情况下，没有理由触及 Vary 或 ETag 或任何其他 header ，因为它是传输级别的东西。

现在我不太关心 Transfer-Encoding 的“逐跳”特性，这似乎是其他人最关心的，因为代理可能解压缩并转发解压缩到客户端。但是，如果原始请求具有正确的 Accept-Encoding header ，代理也可以按原样(压缩)转发它，对于我所知道的所有浏览器来说都是给定的。

顺便说一句，这个问题至少有十年了，参见例如 https://bugzilla.mozilla.org/show_bug.cgi?id=68517 .

如有任何澄清，我们将不胜感激。在什么被认为符合标准和什么被认为实用方面。例如，仅支持透明“内容编码”的 HTTP 客户端库将成为反对实用性的论据。

Answer 1

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

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

是的，Transfer-Encoding header 可用于请求，但仅适用于 HTTP 1.1，这要求客户端和服务器实现都支持 chunked双向编码。

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