使用http压缩时的内容长度
客户端向 http 服务器发出 0-1023 范围的请求。它更喜欢 gzip 压缩 接受编码：gzip；q=1.0，身份； q=0.5,*;q=0 在请求中。
响应标头中的内容长度是多少？是1024还是压缩数据的大小。
谢谢，
The client is making a range request 0-1023 to the http server. It prefers gzip compression with
Accept-Encoding: gzip;q=1.0, identity; q=0.5, *;q=0
in the request.
What would be the content-length in the response header? Will it be 1024 or the size of the compressed data.
Thanks,
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
它取决于
内容编码。RFC 2616 对
Content-Length有这样的规定（除其他外）：所以我们必须弄清楚传输长度是什么； 第 4.4 节（消息长度）说了这两件事关于传输长度：
好的，所以我们知道在这种情况下，transfer-length、entity-length 和 Content-Length 都具有相同的值，并且都指的是“消息正文中出现的长度” ”，所以我们必须确定消息体是什么。 第 4.3 节介绍了有关消息正文的内容：
那么什么是实体主体？为此，您必须基本上引用所有 第 7 节。（其中还定义了实体长度。）最重要的是，有：
实体主体的长度（因此我们根据 4.4 规定的 Content-Length 值）是内容编码后数据的长度。
It depends on the
Content-Encoding.RFC 2616 has this to say (amongst other things) about
Content-Length:So we have to figure out what transfer-length is; Section 4.4 (Message Length) says these two things about transfer-length:
Okay, so we know that in this case transfer-length, entity-length, and Content-Length all have the same value, and all refer to "the length of the message-body as it appears in the message", and so we have to determine what message-body is. Section 4.3 says this about message-body:
So what's an entity-body? For that you have to refer to basically all of Section 7. (Which also defines entity-length.) Most importantly, there this:
The length of the entity-body (and therefore our value for Content-Length per 4.4) is the length of the data after content-coding.
实际内容长度取决于传输编码和数据：如果使用identity，则不应用压缩，内容长度为1024；如果您使用gzip，则实际内容长度取决于要压缩的数据。
The actual content length depends on the transfer encoding and data: If you use identity, no compression is applied and the content length is 1024; if you use gzip, the actual content length depends on the data that is to be compressed.
实际上它是 1024，这是压缩数据的大小。
Actually it will be 1024 which is the size of compressed data.
Content-Length 响应标头的目的是让客户端准确地知道要读取多少字节，直到获得完整的响应。因此，长度必须是压缩后的长度（浏览器在解压缩之前从套接字接收到的长度）。
The purpose of Content-Length response headers is to allow the client to know the precisely how many bytes to read until it has the entire response. Hence the length must be the compressed one (what the browser will receive from the socket before decompression).
我正在为未来的读者回答一个老问题，因为所有旧答案都是不正确的。
假设选择gzip内容编码并且压缩内容的大小大于1024，则范围请求的响应的内容长度将为1024，这是编码内容的前1024字节部分的大小(根据 RFC 9110 选择的表示形式）。
14.1.2 部分。 RFC 9110 的字节范围规定如下：
还有 15.3.7 部分。 206 部分内容 内容如下：
I'm answering an old question for future readers because all of the old answers are incorrect.
Assuming the gzip content encoding is chosen and the size of the compressed content is larger than 1024, the content length of the response of the range request will be 1024, which is the size of the first 1024 byte part of the encoded content(the selected representation in terms of RFC 9110).
The section 14.1.2. Byte Ranges of RFC 9110 says the following:
Also the section 15.3.7. 206 Partial Content says the following: