为什么浏览器无法发送gzip请求？
如果网络服务器可以发送 gzip 响应，为什么浏览器不能发送 gzip 请求？
If webserver can send gzip response, why can't browser sent gzip request?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
如果网络服务器可以发送 gzip 响应，为什么浏览器不能发送 gzip 请求？
If webserver can send gzip response, why can't browser sent gzip request?
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
接受 或继续使用网站，即表示您同意使用 Cookies 和您的相关数据。
发布评论
评论（6）
客户端和服务器必须就如何通信达成一致； 其中一部分是通信是否可以被压缩。 HTTP 被设计为请求/响应模型，并且最初的创建几乎可以肯定地设想总是有小请求和潜在的大响应。 实现 HTTP 并不需要压缩，服务器和客户端都不支持压缩。
HTTP 压缩是由客户端实现的，表示它可以支持压缩，如果服务器在请求中看到这一点并且它支持压缩，则可以压缩响应。 要压缩请求，客户端必须有一个“预请求”，该请求实际上协商请求将被压缩，或者必须要求压缩作为所有请求的受支持编码。
* 2017 年 2 月更新 *
已经过去 8 年了，但正如 @Phil_1984_ 指出的，第三种可能的解决方案是客户端和服务器协商压缩支持，然后将其用于后续请求。 事实上，像 HSTS 这样的东西就是以这种方式与客户端缓存一起工作的，服务器期望只使用 TLS 并忽略任何未加密的链接。 HTTP 被明确设计为无状态的，但我们现在已经超越了这一点。
The client and server have to agree on how to communicate; part of this is whether the communication can be compressed. HTTP was designed as a request/response model, and the original creation was almost certainly envisioned to always have small requests and potentially large responses. Compression is not required to implement HTTP, there are both servers and clients that don't support it.
HTTP compression is implemented by the client saying it can support compression, and if the server sees this in the request and it supports compression it can compress the response. To compress the request the client would have to have a "pre-request" that actually negotiated that the request would be made compressed OR it would have to require compression as a supported encoding for ALL requests.
* UPDATE Feb '17 *
It's been 8 years, but as @Phil_1984_ notes, a 3rd possible solution would be for the client and server to negotiate compression support and then use that for subsequent requests. In fact, things like HSTS work just this way with the client caching that the server expects to only speak TLS and ignore any unencrypted links. HTTP was explicitly designed to be stateless but we've moved beyond that at this point.
客户端无法提前知道服务器是否会理解 gzip 压缩的请求，但服务器可以知道客户端会接受请求。
A client can't know in advance that a server would understand a gzipped request, but the server can know that the client will accept one.
可以，只要它能保证服务器会接受它。 这可能意味着使用 OPTIONS 请求。
Web 浏览器有很多可以做但没有做的事情（例如，管道化）。 Web 浏览器开发人员考虑更改的兼容性影响。
在异构环境中，存在许多不同的 Web 服务器和配置。 改变客户的工作方式可能会破坏其中一些。
也许只有 1% 的服务器可能接受 gzip 压缩的请求，但也许其中一些服务器宣称它们接受，但无法正确接受 - 因此用户将被拒绝将文件上传到这些站点。
从历史上看，有很多损坏的客户端/服务器实现 - 很长一段时间，gzip 压缩的响应在主要的 Web 浏览器中被损坏（值得庆幸的是，这些现在大部分都消失了）。
因此，您最终会得到用户代理或服务器（或域名）的黑名单，其中这些选项会自动关闭，这很糟糕。
It could, provided it could guarantee that the server would accept it. This might mean using an OPTIONS request.
There are a lot of things that web browsers could do (for example, pipelining) that they don't do. Web browser developers consider the compatibility implications of a change.
In a heterogeneous environment, there are a lot of different web servers and configurations. Making a change to the way a client works could break some of them.
Perhaps only 1% of servers might accept gzipped requests, but perhaps some of those advertise that they do, but cannot correctly accept it - so users would be denied from uploading files to those sites.
Historically there have been a lot of broken client / server implementations - for a long time, gzipped responses were broken in major web browsers (thankfully those are now mostly gone).
So you'd end up with blacklists of user-agents or servers (or domain names) where those options were automatically turned off, which is nasty.
因为它不知道服务器是否可以接受它。 HTTP 事务包含客户端发送的单个请求，后面跟着一个响应。 客户端发送的内容之一是它可以支持什么编码/压缩。 然后服务器可以决定如何压缩响应。 客户没有这种奢侈。
Because it doesn't know that the server can accept it. An HTTP transaction has a single request sent by the client followed by a response. One of the things the client sends is what encoding/compression it can support. The server can then decide how to compress the response. The client does not have this luxury.
如果您正在编写 Web 应用程序，我假设您可以控制发送到客户端的内容以及从客户端发回的内容。
在 javascript 中编写 gzip 实现是很容易的，它可以压缩发送到服务器的 post 数据。 服务器可以有一个过滤器（j2ee 术语），它知道客户端数据是压缩发送的，该过滤器解压缩数据，然后将数据传递给像平常一样读取数据的 servlet（或 Struts 中的操作类），例如 request.getParameter( ...）。
如果你能控制的话，这似乎是完全合乎逻辑且可行的。 正如其他帖子提到的，您不能依赖浏览器自动执行此操作，但由于您正在编写网页，因此您可以让浏览器执行您之后的压缩（只需做一些工作）。
安迪.
If you're writing a web application, I'm assuming that you're in control of what is sent to the client and what is sent back from the client.
It would be easy enough to write a gzip implementation in javascript, that compresses the post data being sent to the server. The server could have a filter (j2ee term), that knows client data is sent compressed, this filter decompresses the data and then passes the data to the servlet (or action classes in Struts) that read the data as normal e.g. request.getParameter(...).
This seems perfectly logical and do-able if you're in control. As other posts mention, you couldn't rely on the browser to do this automatically, but since you're writing the web pages, you can get the browser to do the compression you're after (with a little work).
Andy.
HTTP 是这样设计的：
，但在这种设计中，客户端无法发送压缩请求，因为它不知道如果服务器会提前理解它。
HTTP is designed in this way:
BUT IN THIS DESIGN the client can not send compressed requests because it doesnt know if server will understand it in advance.