gzip的Web服务器，例如microsoft.com，我的一个系统（64位）获得带有Transfer-Encoding:chunked的响应标头。另一个使用Content-Encoding:gzip以正确的形式获取响应标头。为什么？
两个系统都有Windows 7 SP1（其中一个是32位，另一个是64位）。我在两个系统上使用相同版本的Chrome进行了测试。我也用FireFox和IE测试。
答案 0 :(得分：0)
因为在传输编码中，不需要将要传输的分块内容长度。数据被分解为碎片并通过网络发送。
Chunked transfer encoding是1.1版中的数据传输机制 超文本传输协议（HTTP）中的数据发送方式 系列的“块”。它使用Transfer-Encoding HTTP标头 Content-Length标头，它的早期版本 否则协议将需要。因为Content-Length标头 没有使用，发件人不需要知道的长度 在开始向接收者发送响应之前的内容。 发件人之前可以开始传输动态生成的内容 知道该内容的总大小。
每个块的大小都是在块本身之前发送的 接收器可以告诉它何时完成接收数据 块。数据传输由最后一块长度终止 零。
编码数据
在以下示例中，每隔一行是新块的开头，块大小为十六进制数 然后是\ r \ n作为行分隔符。
4\r\n
Wiki\r\n
5\r\n
pedia\r\n
e\r\n
in\r\n\r\nchunks.\r\n
0\r\n
\r\n
注意：块大小仅表示块数据的大小。这个 在计算结束时不包括尾随CRLF（“\ r \ n”） 字符。在这个特定的例子中，“in”之后的CRLF是 对于0xE（14）的块长度计数2，并且CRLF在其自身中计数 对于块长度0xE（14），行也被计数2。时期 “chunk”末尾的字符是第14个字符，所以它是 长度为0xE（14）的块的最后一个字符。 CRLF紧随其后 period是尾随的CRLF，所以不计入块 长度为0xE（14）。
解码数据
Wikipedia in
chunks.