XMLHttpRequest 和 Chrome 开发者工具不一样

Question

我正在使用 XMLHttpRequest 和 Range 标头以 5 MB 的块下载约 50 MB 的文件。一切都很好，除了检测我何时下载了最后一个块。

这是 first 块的请求和响应的屏幕截图。注意 Content-Length 是 1024 * 1024 * 5 (5 MB)。另请注意，服务器正确响应前 5 MB，并在 Content-Range 标头中正确指定了整个文件的大小（在/ 之后）：

当我将响应正文复制到文本编辑器 (Sublime) 中时，我只得到 5,242,736 个字符，而不是 Content-Length 所示的预期 5,242,880 个字符：

为什么缺少 144 个字符？对于下载的每个块都是如此，尽管确切的差异会有所不同。

然而，特别奇怪的是 last 块。服务器以文件的最后约 2.9 MB（而不是整个 5 MB）进行响应，并且显然在响应中正确地指出了这一点：

请注意，我正在请求下一个 5 MB（即使它超出了总文件大小）。没什么大不了的，服务器以文件的最后一部分进行响应，并且标头指示返回的实际字节范围。

但真的吗？

当我使用 Javascript 调用 xhr.getResponseHeader("Content-Length") 时，我在 Chrome 中看到了不同的故事：

XMLHttpRequest 对象告诉我在文件末尾之外又下载了 5 MB。 xhr 对象有什么我不明白的地方吗？

更更奇怪的是它可以在 Firefox 30 中按预期工作：

所以在xhr.responseText.length 与Content-Length 不匹配以及这些标头在xhr 对象和网络工具之间不一致，我不知道如何解决这个问题。

造成这些差异的原因是什么？

更新：我已经确认服务器本身正在正确发送请求，尽管最后一个块的请求中的 Range 标头超出了范围。这是原始 HTTP 请求的输出，感谢好的 'ol telnet:

HTTP/1.1 206 Partial Content
Server: nginx/1.4.5
Date: Mon, 14 Jul 2014 21:50:06 GMT
Content-Type: application/octet-stream
Content-Length: 2987360
Last-Modified: Sun, 13 Jul 2014 22:05:10 GMT
Connection: keep-alive
ETag: "53c30296-2fd9560"
Content-Range: bytes 47185920-50173279/50173280

所以看起来 Chrome 出现了故障。这应该作为错误提交吗？在哪里？

Answer 1

主要问题是您将二进制数据作为文本读取。请注意，服务器以 Content-Type: application/octet-stream 响应，它没有明确指定编码 - 在这种情况下，浏览器通常会假定数据以 UTF-8 编码。虽然长度大部分不会改变（值 0 到 127 的字节在 UTF-8 中被解释为单个字符，而具有更高值的字节通常会被替换字符替换），您的二进制文件肯定会包含一些有效的 multi -byte UTF-8 序列 - 这些将组合成一个字符。这就解释了为什么responseText.length 与从服务器接收的字节数不匹配。

现在您当然可以使用request.overrideMimeType() method 强制执行某些特定编码，ISO 8859-1 尤其有意义，因为前 256 个 Unicode 代码点与 ISO 8859-1 相同：

request.overrideMimeType("application/octet-stream; charset=iso-8859-1");

这应该确保一个字节总是被解释为一个字符。不过，更好的方法是将服务器响应存储在 ArrayBuffer 中，这明确用于处理二进制数据。

var request = new XMLHttpRequest();
request.open(...);
request.responseType = "arraybuffer";
request.send();

...

var array = new Uint8Array(request.response);
alert("First byte has value " + array[0]);
alert("Array length is " + array.length);

根据MDN， 从 Chrome 10、Firefox 6 和 Internet Explorer 10 开始支持 responseType = "arraybuffer"。另请参阅：Typed arrays。

旁注：从 Firefox 9 开始，Firefox 还支持 responseType = "moz-chunked-text" 和 responseType = "moz-chunked-arraybuffer"，它们允许在不诉诸远程请求的情况下以块的形式接收数据。 Chrome 似乎不打算实施它，而是在实施Streams API 时working。

编辑：我无法重现您的问题，即 Chrome 就响应标头向您撒谎，至少在没有您的代码的情况下无法重现。但是，负责的代码应该是partial_data.cc中的这个函数：

// We are making multiple requests to complete the range requested by the user.
// Just assume that everything is fine and say that we are returning what was
// requested.
void PartialData::FixResponseHeaders(HttpResponseHeaders* headers,
                                     bool success) {
  if (truncated_)
    return;

  if (byte_range_.IsValid() && success) {
    headers->UpdateWithNewRange(byte_range_, resource_size_, !sparse_entry_);
    return;
  }

此代码将删除服务器返回的 Content-Length 和 Content-Range 标头，并将它们替换为从您的请求参数生成的标头。鉴于我自己无法重现该问题，以下仅为猜测：

• 此代码路径似乎仅用于可以从缓存中满足的请求，所以我想如果您清除缓存，一切都会正常工作。
• resource_size_ 变量在您的情况下必须具有错误的值，大于请求文件的实际大小。这个变量是根据请求的第一个块中的Content-Range 标头确定的，也许您在那里缓存了一个服务器响应，表明文件更大。