为什么浏览器不能发送 gzip 请求? [英] Why can't browser send gzip request?

问题描述

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

If webserver can send gzip response, why can't browser sent gzip request?

推荐答案

客户端和服务器必须就如何通信达成一致；其中一部分是通信是否可以压缩.HTTP 被设计为请求/响应模型，并且几乎可以肯定，最初的创建总是有小的请求和潜在的大响应.实现 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 压缩是由客户端实现的，说它可以支持压缩，如果服务器在请求中看到这一点并且它支持压缩，它可以压缩响应.要压缩请求，客户端必须有一个预请求"，该请求实际上协商将请求压缩，或者必须要求压缩作为所有请求支持的编码.

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.

* 17 年 2 月更新 *已经 8 年了，但正如@Phil_1984_ 所指出的，第三种可能的解决方案是客户端和服务器协商压缩支持，然后将其用于后续请求.事实上，像 HSTS 这样的东西在客户端缓存中就是这样工作的，服务器期望只使用 TLS 并忽略任何未加密的链接.HTTP 被明确设计为无状态，但此时我们已经超越了这一点.

* 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 请求?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！