客户端正在向 http 服务器发出 0-1023 范围的请求。它更喜欢 gzip 压缩 接受编码：gzip；q=1.0，身份； q=0.5,*;q=0 在请求中。
响应头中的内容长度是多少？是1024还是压缩数据的大小。
谢谢，
这取决于
Content-EncodingRFC 2616 有这样的说法（除其他外）关于
Content-Length应用程序应该使用该字段来指示传输长度 消息正文，除非第 1 节中的规则禁止这样做 4.4.
所以我们必须弄清楚传输长度是什么； 第 4.4 节（消息长度）说了关于传输长度的两件事：
消息的传输长度是消息主体的长度，如下所示 它出现在消息中；也就是说，在任何传输编码之后 已申请。
如果存在 Content-Length 标头字段（第 14.13 节），则其 OCTET 中的十进制值表示实体长度和实体长度 传输长度。如果满足以下条件，则不得发送 Content-Length 标头字段： 这两个长度不一样
好的，所以我们知道在这种情况下，transfer-length、entity-length 和 Content-Length 都具有相同的值，并且都指的是“消息中出现的消息正文的长度”，所以我们必须确定消息正文是什么。 第 4.3 节 介绍了消息正文：
HTTP 消息的消息体（如果有）用于携带 与请求或响应关联的实体主体。”
那么什么是实体主体？为此，您必须基本上参考全部第 7 节。 （这也定义了实体长度。）最重要的是：
实体主体：=内容编码（内容类型（数据））
实体主体的长度（以及因此我们根据 4.4 规定的 Content-Length 值）是内容编码后数据的长度。
实际内容长度取决于传输编码和数据：如果使用identity，则不应用压缩，内容长度为1024；如果您使用gzip，实际内容长度取决于要压缩的数据。
实际上是1024，这是压缩数据的大小。
Content-Length 响应头的目的是让客户端准确地知道要读取多少字节，直到获得完整的响应。因此长度必须是压缩后的长度（解压前浏览器从套接字接收到的长度）。
我正在为未来的读者回答一个老问题，因为所有旧答案都不正确。
假设选择gzip内容编码并且压缩内容的大小等于或大于1024，则内容长度将为1024。
如果表示数据应用了内容编码，则每个字节范围是根据编码的字节序列计算的，而不是根据解码后获得的底层字节序列计算的。
15.3.7。 206部分内容还说了以下内容：
206 响应中存在的 Content-Length 标头字段指示该消息内容中的八位字节数，这通常不是所选表示的完整长度。每个 Content-Range 标头字段都包含有关所选表示的完整长度的信息。