首页 文章

传输编码：gzip与内容编码：gzip

提问于
浏览 次
80

关于是否要做什么，目前的情况如何

Transfer-Encoding: gzip

或者a

Content-Encoding: gzip

当我想允许 clients 时，例如有限的带宽为 signal their willingness to accept a compressed response 和 server have the final say whether or not to compress .

后者是例如Apache的mod_deflate和IIS，如果你让它来处理压缩 . 根据要压缩的内容的大小，它将执行额外的 Transfer-Encoding: chunked .

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

有没有一个明确的答案，我已经错过了（并没有埋没在某个apache新闻组的长线程中的消息中）？

我目前的印象是：

  • Transfer-Encoding实际上是通过现有服务器和客户端实现完成内容编码主要完成工作的正确方法

  • Content-Encoding由于其语义含义，带来了一些问题（服务器在透明地压缩响应时应该对 ETag 做什么？）

  • 原因是鸡'n'鸡蛋：浏览器不要't support it because servers don' t因为浏览器没有

所以我假设正确的方式将是 Transfer-Encoding: gzip （或者，如果我另外扼杀身体，它would become Transfer-Encoding: gzip, chunked ） . 在这种情况下没有理由触及 Vary 或 ETag 或任何其他标头，因为它是传输级别的东西 .

现在我不是 Transfer-Encoding ，这是其他人似乎首先关注的事情，因为代理可能会解压缩并将未压缩转发给客户端 . 但是，如果原始请求具有正确的 Accept-Encoding 标头，则代理也可以按原样（压缩）转发它，如果所有浏览器都是给定的，则代理 .

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

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

http gzip content-encoding transfer-encoding

2 回答

  • 24

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

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

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

    换句话说：不要做 on-the-fly 内容编码，而是使用Transfer-Encoding！

    Edit: 即 unless you want to serve gzipped content to clients that only understand Content-Encoding . 遗憾的是，这似乎是其中的大多数 . 但请注意，你可能遇到诸如菲尔丁和其他人提到的问题，例如：当涉及缓存代理时 .

    回复于
  • 33

    RFC 2616中定义的 correct 用法实际上是在野外实现的，用于客户端发送 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 值，则表示该资源的服务器端数据已更改 .

    回复于

相关问题