传输-编码: 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报头意味着例如，缓存不能使用其缓存版本的其他相同的实体。

在这个问题上，是否有明确的答案，我已经错过了(而且这不是隐藏在某个apache新闻组的一个长线程中的消息中)？

我目前的印象是：

• 实际上，传输编码将是对现有服务器和客户端实现进行内容编码的正确方法。
• 内容编码，因为它的语义含义，带来了一些问题(当服务器透明地压缩响应时，它应该对ETag做些什么？)
• 原因是鸡蛋:浏览器不支持它，因为服务器不支持，因为浏览器不支持它

所以我假设正确的方式是一个Transfer-Encoding: gzip (或者，如果我加块的话，它就是会变成 Transfer-Encoding: gzip, chunked)。在这种情况下，没有理由接触Vary、ETag或任何其他标题，因为这是一个传输级别的问题。

目前，我并不太关心Transfer-Encoding的‘逐跳’，其他人似乎首先关心的是代理，因为代理可能解压缩并将其转发给客户端。但是，如果原始请求有适当的Accept-Encoding头，那么代理也可以转发- is (压缩)，对于我知道的所有浏览器来说，这都是给定的。

顺便说一句，这个问题至少有十年了，参见bug.cgi?id=68517。

如对此作出任何澄清，将不胜感激。无论是在什么被认为是符合标准和什么被认为是实际的。例如，仅支持透明的“内容-编码”的HTTP客户端库将是一个反对实用性的论据。

Answer 1

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

更改内容--以不一致的方式进行编码(既不是“从不”，也不是“总是”)，使得以后关于该内容的请求(例如PUT或条件GET)无法得到正确的处理。当然，这就是为什么执行即时内容编码是一个愚蠢的想法，以及为什么我将传输编码添加到HTTP中作为在不改变资源的情况下执行动态编码的正确方法。

来源：bug.cgi?id=39727#c31

换句话说:不要做上的内容-编码，使用传输-编码代替！

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

Answer 2

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

因此，在您的示例中，客户端将发送一个Accept-Encoding: gzip请求头，然后服务器可能决定压缩(如果还没有)，并发送一个Content-Encoding: gzip和可选的Transfer-Encoding: chunked响应头。

是的，Transfer-Encoding头可以在请求中使用，但只能用于HTTP1.1，这要求客户机和服务器实现都支持chunked编码。

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