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

Question

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

Answer 1

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

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

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

Answer 2

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

Answer 3

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

Web浏览器可以执行很多操作（例如，流水线操作）。 Web浏览器开发人员考虑更改的兼容性含义。

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

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

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

所以你最终会得到用户代理或服务器（或域名）的黑名单，这些选项会自动关闭，这很糟糕。

Answer 4

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

Answer 5

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

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

如果你处于控制之中，这似乎是完全合乎逻辑的。正如其他帖子所提到的那样，你不能依靠浏览器自动执行此操作，但由于你正在编写网页，你可以让浏览器进行你正在进行的压缩（稍加工作）。

安迪。

Answer 6

HTTP 是这样设计的：

• 客户以纯文本形式说出其请求（包括是否可以理解压缩答案）
• 服务器以正确的编码响应（压缩或未压缩）

但在这种设计中，客户端无法发送压缩请求，因为它不知道服务器是否会提前理解它。