摘要:我想从GitHub页面发出Range标头请求。但是,在某些浏览器中,此操作失败-可能是由于Gzip压缩问题。它可以在Chrome(v74)和FF(v66)的Mac OS中使用。
目标:我想在所有浏览器中可靠地发出此请求,例如通过在每次发出范围请求时强制将响应类型编码为文本。
我不清楚这种行为是由浏览器,服务器还是两者的某种组合所决定的。知道来源可以帮助定义与Github页面一起使用的修复程序,这很好,但不是强制性的。
我也不清楚这是否代表错误,如果是,则代表错误。 (在浏览器中,在规格中等)
示例测试用例:
可能因为这涉及服务器端gzip编码,所以示例测试用例无法在本地复制。您需要在https://abought.github.io/weetabix/
的JS控制台中输入这些命令才能重现。
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'
添加到提取请求中,但这是forbidden header,通过代码对其进行修改无效。
答案 0 :(得分:3)
规格最近在这里已更改。 Here is the link to the PR。
TLDR; They now ask UA,Acccept-Encoding/Identity
标头已添加到所有范围请求。
[§5.15]
如果httpRequest的标题列表包含
Range
,则将Accept-Encoding
/identity
附加到httpRequest的标题列表中。
Firefox在这里尚未跟进,但a bug report has been filled。
就目前而言,Firefox中的Range请求确实是使用Gzipped数据发出的,因此,您不能破坏字节的完整性(例如,范围0-100
在Firefox中是可解码的)。 / p>