为什么浏览器无法发送gzip请求？

如果webserver可以发送gzip响应,为什么浏览器不能发送gzip请求？

1> Peter Oehler..：

---

客户端和服务器必须就如何通信达成一致; 部分原因是通信是否可以压缩.HTTP被设计为请求/响应模型,并且几乎可以肯定原始创建始终具有小请求和可能的大响应.实现HTTP 不需要压缩,服务器和客户端都不支持它.

HTTP压缩是由客户端实现的,它说它可以支持压缩,如果服务器在请求中看到它并且它支持压缩,它可以压缩响应.为了压缩请求,客户端必须具有实际协商的"预请求",该请求将被压缩,或者它必须要求压缩作为所有请求的支持编码.

*更新 2017年2月*已经8年了,但正如@ Phil_1984_所说,第三种可能的解决方案是客户端和服务器协商压缩支持,然后将其用于后续请求.实际上,像HSTS之类的东西就像服务器希望只能说TLS并忽略任何未加密的链接的客户端缓存一样.HTTP被明确设计为无状态,但我们已经超越了这一点.

---

"规范不要求压缩,服务器和客户端都不支持它." 客户首先说,"嘿,我说法语,对吗？" 服务器响应,并以英语或法语回答,具体取决于它是否知道法语.这个例子中的法语是压缩.如果OP询问,客户端能够立即开始用法语交谈,所有服务器都必须说法语或者系统会中断.系统只允许压缩响应,因为它需要协商并且两个系统都同意.

2> Paul Dixon..：

---

客户端无法事先知道服务器会理解gzip压缩请求,但服务器可以知道客户端会接受一个.

---

不对.Content-Encoding是客户端提供的允许标头.RFC说:"如果请求消息中的实体的内容编码对原始服务器不可接受,则服务器应该响应状态代码415(不支持的媒体类型)." - 根据[尼克约翰逊](http://stackoverflow.com/questions/2395440/sending-gzipped-form-data#comment-2375417)

---

你所说的与我驾驶的东西有点不同.您可以*尝试*按照您的建议发送gzip压缩请求,但事先无法知道服务器会接受它(不与服务器通信).也就是说,你的观点很好:如果你试图发送一个gzip压缩请求,你可能会发现服务器可以支持它.

---

有很多地方你事先知道服务器支持它.例如,移动应用程序与后端通信.

3> MarkR..：

---

它可以,只要它可以保证服务器会接受它.这可能意味着使用OPTIONS请求.

Web浏览器可以执行许多操作(例如,流水线操作).Web浏览器开发人员考虑更改的兼容性含义.

在异构环境中,有许多不同的Web服务器和配置.改变客户端的工作方式可能会破坏其中的一部分.

也许只有1%的服务器可能会接受gzip压缩请求,但也许有些服务器会宣传它们,但是无法正确接受它 - 因此用户将被拒绝将文件上传到这些网站.

从历史上看,已经有很多破坏的客户端/服务器实现 - 很长一段时间,主流Web浏览器中的gzipped响应被破坏了(幸好那些现在已经基本消失了).

所以你最终会得到用户代理或服务器(或域名)的黑名单,这些选项会自动关闭,这是令人讨厌的.