相关疑难解决方法(0)

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

Transfer-Encoding: gzip

或者a

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.

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