如果网络服务器可以发送 gzip 响应，为什么浏览器不能发送 gzip 请求？
问问题
29942 次
6 回答
63
客户端和服务器必须就如何通信达成一致；部分原因是通信是否可以压缩。HTTP 被设计为请求/响应模型，最初的创建几乎可以肯定地设想总是有小请求和潜在的大响应。实现 HTTP不需要压缩，有服务器和客户端都不支持它。
HTTP 压缩是由客户端实现的，说它可以支持压缩，如果服务器在请求中看到它并且它支持压缩，它可以压缩响应。为了压缩请求，客户端必须有一个“预请求”，实际上协商请求将被压缩，或者它必须要求压缩作为所有请求的支持编码。
* 2017 年 2 月更新 * 已经 8 年了，但正如 @Phil_1984_ 所指出的，第三种可能的解决方案是客户端和服务器协商压缩支持，然后将其用于后续请求。事实上，像 HSTS 这样的东西就是这样与客户端缓存一起工作的，服务器期望只使用 TLS 并忽略任何未加密的链接。HTTP 被明确设计为无状态，但我们现在已经超越了这一点。
于 2009-01-08T16:34:48.573 回答
27
客户端无法提前知道服务器会理解压缩后的请求，但服务器可以知道客户端会接受请求。
于 2009-01-08T16:33:19.170 回答
7
它可以，只要它可以保证服务器会接受它。这可能意味着使用 OPTIONS 请求。
Web 浏览器可以做很多他们不做的事情（例如，流水线）。Web 浏览器开发人员考虑更改的兼容性影响。
在异构环境中，有许多不同的 Web 服务器和配置。改变客户的工作方式可能会破坏其中的一些。
也许只有 1% 的服务器可能会接受 gzip 压缩请求，但也许其中一些服务器宣传他们接受，但无法正确接受 - 因此用户将被拒绝将文件上传到这些站点。
从历史上看，有很多损坏的客户端/服务器实现 - 很长一段时间以来，主要 Web 浏览器中的 gzip 响应都被破坏了（谢天谢地，这些现在大部分都消失了）。
因此，您最终会得到自动关闭这些选项的用户代理或服务器（或域名）的黑名单，这很讨厌。
于 2009-04-10T07:36:20.987 回答
3
因为它不知道服务器可以接受它。HTTP 事务具有由客户端发送的单个请求，然后是响应。客户端发送的其中一件事是它可以支持什么编码/压缩。然后服务器可以决定如何压缩响应。客户没有这种奢侈。
于 2009-01-08T16:34:38.590 回答
2
如果您正在编写一个 Web 应用程序，我假设您可以控制发送给客户端的内容以及从客户端发送回的内容。
用 javascript 编写一个 gzip 实现会很容易，它可以压缩发送到服务器的发布数据。服务器可以有一个过滤器（j2ee 术语），它知道客户端数据是压缩发送的，这个过滤器解压缩数据，然后将数据传递给 servlet（或 Struts 中的操作类），它可以正常读取数据，例如 request.getParameter( ...）。
如果您可以控制，这似乎完全合乎逻辑且可行。正如其他帖子所提到的，您不能依靠浏览器自动执行此操作，但是由于您正在编写网页，因此您可以让浏览器进行您所追求的压缩（只需做一些工作）。
安迪。
于 2009-09-14T05:29:34.090 回答
0
HTTP 是这样设计的：
- 客户以纯文本形式表示其请求（包括是否可以理解压缩答案）
- 服务器使用适当的编码响应（压缩与否）
但是在这个设计中，客户端不能发送压缩请求，因为它不知道服务器是否会提前理解它。
于 2017-06-02T21:43:14.737 回答