使用 http 压缩时的内容长度答案

【问题标题】：content-length when using http compression使用 http 压缩时的内容长度
【发布时间】：2011-04-18 16:05:36
【问题描述】：

客户端正在向 http 服务器发出范围请求 0-1023。它更喜欢使用 gzip 压缩接受编码：gzip；q=1.0，身份； q=0.5, *;q=0 在请求中。

响应标头中的内容长度是多少？是 1024 还是压缩数据的大小。

谢谢，

【问题讨论】：

标签： http

【解决方案1】：

这取决于Content-Encoding。

RFC 2616 对Content-Length 有这样的说法（除其他外）：

应用程序应该使用这个字段来指示传输长度消息正文，除非本节中的规则禁止这样做 4.4.

所以我们必须弄清楚传输长度是多少； Section 4.4 (Message Length) 说了这两个关于传输长度的事情：

消息的传输长度是消息体的长度，如它出现在消息中；也就是说，在任何传输编码具有已应用。

如果存在 Content-Length 标头字段（第 14.13 节），则其 OCTET 中的十进制值表示实体长度和传输长度。如果出现以下情况，则不得发送 Content-Length 标头字段这两个长度不同

好的，所以我们知道在这种情况下，传输长度、实体长度和内容长度都具有相同的值，并且都是指“出现在消息中的消息体的长度”，所以我们必须确定什么是消息体。 Section 4.3 说的是消息体：

HTTP 消息的消息体（如果有）用于携带与请求或响应关联的实体主体。”

那么什么是实体？为此，您基本上必须参考所有Section 7。（这也定义了实体长度。）最重要的是：

entity-body := Content-Encoding( Content-Type( data ) )

实体主体的长度（因此我们在 4.4 中的 Content-Length 值）是内容编码后的数据长度。

【讨论】：

【解决方案2】：

实际内容长度取决于传输编码和数据：如果使用identity，则不进行压缩，内容长度为1024；如果您使用 gzip，实际内容长度取决于要压缩的数据。

【讨论】：

【解决方案3】：

实际上它将是 1024，即压缩数据的大小。

【讨论】：