客户端正在向http服务器发出范围请求0-1023 . 它更喜欢使用Accept-Encoding进行gzip压缩：gzip; q = 1.0，identity;请求中q = 0.5，*; q = 0 .
响应头中的内容长度是多少？它是1024还是压缩数据的大小 .
谢谢，
实际上它将是1024，这是压缩数据的大小 .
实际内容长度取决于传输编码和数据：如果使用标识，则不应用压缩，内容长度为1024;如果使用gzip，实际内容长度取决于要压缩的数据 .
它是1024或压缩大小中的较小者 .
RFC2616 section 14说：
“[这个答案的其余部分与提出的实际问题无关 . 我将其留下，因为有些人认为它很有用 . ]
关于Content-Length的RFC 2616（包括其他内容）有这个说法：
应用程序应该使用此字段来指示消息正文的传输长度，除非4.4节中的规则禁止这样做 .
所以我们必须弄清楚转移长度是多少; Section 4.4（消息长度）说这两个关于传输长度的事情：
消息的传输长度是消息中出现的消息体长度;也就是说，在应用任何转移编码之后 . 如果存在Content-Length头字段（第14.13节），则其在OCTET中的十进制值表示实体长度和传输长度 . 如果这两个长度不同，则不得发送Content-Length头字段
好的，所以我们知道在这种情况下，transfer-length，entity-length和Content-Length都具有相同的值，并且都引用"the length of the message-body as it appears in the message"，因此我们必须确定什么是message-body . Section 4.3这说消息体：
HTTP消息的消息体（如果有的话）用于携带与请求或响应相关联的实体主体 . “
那么什么是实体 - 身体？为此你必须基本上参考Section 7 . （这也定义了实体长度 . ）最重要的是，有：
entity-body：=内容编码（内容类型（数据））
实体主体的长度（因此我们的每4.4内容长度的值）是内容编码后的数据长度 .
3 回答
实际上它将是1024，这是压缩数据的大小 .
实际内容长度取决于传输编码和数据：如果使用标识，则不应用压缩，内容长度为1024;如果使用gzip，实际内容长度取决于要压缩的数据 .
它是1024或压缩大小中的较小者 .
RFC2616 section 14说：
“[这个答案的其余部分与提出的实际问题无关 . 我将其留下，因为有些人认为它很有用 . ]
关于Content-Length的RFC 2616（包括其他内容）有这个说法：
所以我们必须弄清楚转移长度是多少; Section 4.4（消息长度）说这两个关于传输长度的事情：
好的，所以我们知道在这种情况下，transfer-length，entity-length和Content-Length都具有相同的值，并且都引用"the length of the message-body as it appears in the message"，因此我们必须确定什么是message-body . Section 4.3这说消息体：
那么什么是实体 - 身体？为此你必须基本上参考Section 7 . （这也定义了实体长度 . ）最重要的是，有：
实体主体的长度（因此我们的每4.4内容长度的值）是内容编码后的数据长度 .