在某些浏览器中发出范围请求时出现问题

Question

摘要：我想从 GitHub 页面发出 Range 标头请求。然而，在某些浏览器中，此操作会失败 - 可能是由于 Gzip 压缩问题。它适用于 Chrome (v74)，但不适用于 FF (v66)、Mac OS。

目标：我想在所有浏览器中可靠地发出此请求，例如每当发出范围请求时强制将响应类型编码为文本。

我不清楚这种行为是由浏览器、服务器还是两者的某种组合决定的。了解起源有助于定义修复方案——使用 Github 页面会很好，但不是强制性的。

我也不清楚这是否代表一个错误，或者如果是，那么在哪里。（在浏览器、规范等中）

示例测试用例：可能因为这涉及服务器端 gzip 编码，所以示例测试用例不会在本地重现。您需要在 JS 控制台中输入这些命令才能https://abought.github.io/weetabix/重现。

fetch('https://abought.github.io/weetabix/example_data/McDonald_s.csv', {headers: {range: 'bytes=1-100'}} ).then(resp => resp.text());

在 Chrome 中，这会获取响应文本。在 Firefox 中，它给出“解码错误”。

如果我省略resp.text，Firefox 可以完成请求 - 解码错误在于读取正文，而不是任何其他代码。复制为curl显示FF添加了一个--compress标志而Chrome没有。

调查 如果字节范围是 0-100，则请求在 FF 中有效。如果范围是 1-100，则失败。文件的这一部分都是 ASCII 字符。

如果我检查响应标头 ( Array.from(r.headers.entries()))，FF 有一个额外的“内容编码：gz 标志”，我认为这是导致问题的原因。（例如，如果没有秘密解码器指令，gzip 就没有意义）

我尝试添加'accept-encoding': 'identity'到获取请求，但它是禁止的标头，并且通过代码修改它没有效果。

Answer 1

这里的规格最近发生了变化。这是 PR 的链接。

\n\n

太长了；他们现在要求UA 将Acccept-Encoding/Identity标头添加到所有范围请求中。

\n\n

[\xc2\xa75.15]

\n\n

\n

如果 httpRequest\xe2\x80\x99s 标头列表包含Range，则将Accept-Encoding/附加identity到 httpRequest\xe2\x80\x99s 标头列表。

\n

\n\n

这里Firefox还没有跟进，但是已经填了一个bug报告。

\n\n

目前，Firefox 中的范围请求确实是使用 Gzipped 数据发出的，因此，您不能破坏字节完整性（例如，范围0-100在 Firefox 中是可解码的）。

\n