为什么浏览器不能发送gzip请求？
如果web服务器可以发送gzip响应，为什么浏览器不能发送gzip请求？
客户端和服务器必须就如何通信达成一致; 其中一部分是通信是否可以压缩。 HTTP被devise为一个请求/响应模型，并且几乎可以肯定，原始创build总是有小的请求和可能的大的响应。 压缩不需要实现HTTP，有服务器和客户端不支持它。
HTTP压缩是由客户端实现的，它可以支持压缩，如果服务器在请求中看到它，并且它支持压缩，它可以压缩响应。 为了压缩请求，客户端将不得不有一个“预先请求”，实际上已经谈判请求将被压缩，或者它将不得不要求压缩作为所有请求的支持编码。
*更新2月17日*已经8年了，但@ Phil_1984_注意到，第三个可能的解决scheme将是客户端和服务器协商压缩支持，然后用于后续请求。 事实上，像HSTS这样的事情，客户端caching就是这样工作的，服务器希望只说TLS而忽略任何未encryption的链接。 HTTP被明确地devise为无状态，但在这一点上我们已经超越了这一点。
客户端不能事先知道服务器会理解gzip请求，但是服务器可以知道客户端会接受。
它可以，只要它能保证服务器会接受它。 这可能意味着使用OPTIONS请求。
Web浏览器可以做很多事情（例如stream水线），他们不这样做。 Web浏览器开发人员考虑到变更的兼容性影响。
在异构环境中，有许多不同的Web服务器和configuration。 改变客户的工作方式可能会破坏其中的一部分。
也许只有1％的服务器可以接受gzip的请求，但也许有一些做广告，但不能正确接受 – 所以用户将被拒绝上传文件到这些网站。
从历史上看，客户端/服务器的实现有很多问题，很长一段时间以来，主要浏览器的gzip响应都被打破了（幸好现在已经大部分都没有了）。
所以你最终会得到用户代理或服务器（或域名）的黑名单，这些选项被自动closures，这是不好的。
因为它不知道服务器可以接受它。 一个HTTP事务有一个由客户发送的请求，然后是响应。 客户端发送的东西之一是它可以支持的编码/压缩。 服务器可以决定如何压缩响应。 客户没有这种奢侈。
如果你正在编写一个Web应用程序，我假定你在控制什么发送到客户端，什么是从客户端发回的。
在javascript中编写一个gzip实现将非常简单，它压缩发送到服务器的发布数据。 服务器可以有一个filter（j2ee术语），知道客户端数据被压缩发送，这个filter解压缩数据，然后将数据传递给读取数据的servlet（或Struts中的动作类），例如request.getParameter …）。
这似乎是完全合乎逻辑的，如果你在控制之下可行的话。 正如其他post所提到的，你不能依靠浏览器来自动完成这个工作，但是由于你正在编写网页，你可以让浏览器做一些压缩工作。
安迪。
HTTP是这样devise的：
- 客户用纯文本表示请求（包括能否理解压缩的答案）
- 服务器响应与propper编码（压缩与否）
但在这个devise中，客户端不能发送压缩的请求，因为它不知道服务器是否会提前理解它。
