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

如果网络服务器可以发送gzip响应，为什么浏览器无法发送gzip请求？

客户端和服务器必须就如何进行通信达成共识；部分原因在于通信是否可以压缩。HTTP被设计为请求/响应模型，几乎可以肯定的是，最初的创建总是具有较小的请求和可能较大的响应。实施HTTP不需要压缩，因为服务器和客户端都不支持压缩。

HTTP压缩由客户端实现，它说它可以支持压缩，并且如果服务器在请求中看到了此消息并且支持压缩，则可以压缩响应。为了压缩请求，客户端必须具有一个“ pre-request”，该“ pre-request”实际上协商将请求压缩为压缩请求，或者它需要压缩作为所有请求的受支持编码。

*更新时间：17 年2月*已经8年了，但是正如@ Phil_1984_指出的那样，第三个可能的解决方案是让客户端和服务器协商压缩支持，然后将其用于后续请求。实际上，HSTS之类的事情就是通过客户端缓存来实现的，服务器希望客户端仅讲TLS，而忽略任何未加密的链接。HTTP被明确设计为无状态的，但我们已经超越了这一点。

客户端无法预先知道服务器可以理解gzip压缩的请求，但是服务器可以知道客户端将接受一个请求。

只要可以保证服务器可以接受它，它就可以。这可能意味着使用OPTIONS请求。

Web浏览器可以执行许多其他操作，而不能完成（例如，流水线操作）。Web浏览器开发人员考虑了更改的兼容性影响。

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

也许只有1％的服务器可以接受压缩的请求，但是其中一些可能会宣传它们确实接受了请求，但不能正确接受-因此，将拒绝用户将文件上传到那些站点。

从历史上看，有很多损坏的客户端/服务器实现-很长一段时间以来，主要的Web浏览器中的压缩响应都被破坏了（幸运的是，这些响应现在大部分都消失了）。

因此，您最终会获得自动关闭这些选项的用户代理或服务器（或域名）黑名单，这很麻烦。

因为它不知道服务器可以接受它。HTTP事务具有一个由客户端发送的单个请求，然后是一个响应。客户端发送的内容之一是它可以支持哪种编码/压缩。然后，服务器可以决定如何压缩响应。客户没有这种奢侈。

如果您正在编写Web应用程序，那么我假设您可以控制发送给客户端的内容以及从客户端发回的内容。

用javascript编写gzip实现很容易，它将压缩发送到服务器的数据。服务器可能有一个过滤器（j2ee术语），它知道客户端数据是压缩发送的，该过滤器对数据进行解压缩，然后将数据传递到servlet（或Struts中的动作类），该servlet可以正常读取数据，例如request.getParameter（ ...）。

如果您处于控制之中，这似乎是完全合乎逻辑且可行的。就像其他帖子提到的那样，您不能依靠浏览器来自动执行此操作，但是由于您正在编写网页，因此可以使浏览器执行您要执行的压缩（只需做一些工作）。

安迪

HTTP以这种方式设计：

• 客户以纯文本形式表示其请求（包括是否可以理解压缩的答案）
• 服务器使用适当的编码进行响应（是否压缩）

但是在此设计中，客户端无法发送压缩的请求，因为它不知道服务器是否会事先知道。