传输编码：gzip与内容编码：gzip [英] Transfer-Encoding: gzip vs. Content-Encoding: gzip

问题描述

关于是否要做什么是当前的事态

What is the current state of affairs when it comes to whether to do

Transfer-Encoding: gzip

或

Content-Encoding: gzip

当我想允许客户时使用例如有限的带宽表明他们愿意接受压缩的响应，而服务器最终决定是否压缩。

when I want to allow clients with e.g. limited bandwidth to signal their willingness to accept a compressed response and the server have the final say whether or not to compress.

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

The latter is what e.g. Apache's mod_deflate and IIS do, if you let it take care of compression. Depending on the size of the content to be compressed, it will do the additional Transfer-Encoding: chunked.

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

It will also include a Vary: Accept-Encoding, which already hints at the problem. Content-Encoding seems to be part of the entity, so changing the Content-Encoding amounts to a change of the entity, i.e. a different Accept-Encoding header means e.g. a cache cannot use its cached version of the otherwise identical entity.

我是否有一个明确的答案，我已经错过了（并且它没有埋没在一个长的消息中一些apache新闻组中的主题）？

Is there a definite answer on this that I have missed (and that's not buried inside a message in a long thread in some apache newsgroup)?

我目前的印象是：

• 转移实际上，编码实际上是通过现有服务器和客户端实现完成内容编码的正确方法。


• 内容编码由于其语义含义，带有几个问题（当服务器透明地压缩响应时，服务器应该对 ETag 做什么？）


• 原因是鸡'n'egg ：浏览器不支持它，因为服务器没有，因为浏览器不支持

• Transfer-Encoding would in fact be the right way to do what is mostly done with Content-Encoding by existing server and client implentations
• Content-Encoding, because of its semantic implications, carries a couple of issues (what should the server do to the ETag when it transparently compresses a response?)
• The reason is chicken'n'egg: Browsers don't support it because servers don't because browsers don't

所以我假设正确的方式是转移编码：gzip （或者，如果我另外对主体进行分块，则将成为 Transfer-Encoding：gzip，chunked ）。在这种情况下没有理由触及 Vary 或 ETag 或任何其他标题，因为它是传输级别的东西。

So I am assuming the right way would be a Transfer-Encoding: gzip (or, if I additionally chunk the body, it would become Transfer-Encoding: gzip, chunked). And no reason to touch Vary or ETag or any other header in that case as it's a transport-level thing.

目前我并不太关心转发编码，其他人似乎首先关注的事情，因为代理可能会解压缩并将未压缩转发给客户端。但是，如果原始请求具有正确的 Accept-Encoding 标头，代理可能也会按原样转发（压缩），如果我知道所有浏览器的话是给定的。

For now I don't care too much about the 'hop-by-hop'-ness of Transfer-Encoding, something that others seem to be concerned about first and foremost, because proxies might uncompress and forward uncompressed to the client. However, proxies might just as well forward it as-is (compressed), if the original request has the proper Accept-Encoding header, which in case of all browsers that I know is a given.

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

Btw, this issue is at least a decade old, see e.g. https://bugzilla.mozilla.org/show_bug.cgi?id=68517 .

如有任何澄清，我们将不胜感激。无论是在符合标准的还是被认为是实用的方面。例如，仅支持透明Content-Encoding的HTTP客户端库将成为反对实用性的论据。

Any clarification on this will be appreciated. Both in terms of what is considered standards-compliant and what is considered practical. For example, HTTP client libraries only supporting transparent "Content-Encoding" would be an argument against practicality.

推荐答案

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

Quoting Roy T. Fielding, one of the authors of RFC 2616:

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

changing content-encoding on the fly in an inconsistent manner (neither "never" nor "always) makes it impossible for later requests regarding that content (e.g., PUT or conditional GET) to be handled correctly. This is, of course, why performing on-the-fly content-encoding is a stupid idea, and why I added Transfer-Encoding to HTTP as the proper way to do on-the-fly encoding without changing the resource.

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

换句话说：不要做 on-the-f 内容编码，改为使用转移编码！

In other words: Don't do on-the-fly Content-Encoding, use Transfer-Encoding instead!

编辑即，除非您想要投放将内容gzip压缩到仅了解内容编码的客户端。不幸的是，这似乎是其中的大多数。但要注意你离开规范领域并可能遇到诸如菲尔丁和其他人提到的问题，例如当涉及缓存代理时。

That is, unless you want to serve gzipped content to clients that only understand Content-Encoding. Which, unfortunately, seems to be most of them. But be aware that you leave the realms of the spec and might run into issues such as the one mentioned by Fielding as well as others, e.g. when caching proxies are involved.

这篇关于传输编码：gzip与内容编码：gzip的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！