部分文件返回数据错误，这是一个严重的BUG，请重视

liupan1890 commented 3 years ago

今天在测试时发现了一个情况，下载一个文件(xxx.txt 701b),总是失败，后来研究发现是6盘服务器的BUG，并且是严重BUG

使用案例

GET https://download2.99store.cn/oriStore/FtoFW5yGfXO4stiF9FQzrS7Ddvhe/wcs/user/%E5%88%86%E6%B5%81%E8%BD%AC%E8%BD%BD%E7%9A%84%E5%B8%8C%E6%9C%9B%E8%83%BD%E7%82%B9%E8%BF%9B%E6%9D%A5%E7%9C%8B%E4%B8%8B%3D%20%3D.txt?*******************************ck=aac1bb0f0f0b13388bafdd50a032e802&store=0 HTTP/1.1
Host: download2.99store.cn
Accept: */*
Range: bytes=604-700

HTTP/1.1 200 OK
Date: Thu, 31 Dec 2020 10:50:21 GMT
Content-Type: text/plain;charset=UTF-8
Transfer-Encoding: chunked
Connection: keep-alive
ETag: W/"FtoFW5yGfXO4stiF9FQzrS7Ddvhe"
Last-Modified: Sun, 07 Jul 2019 03:59:35 GMT
X-Reqid: 203322119924614820201231180132owE7Sukdsampled
Server: WS-web-server
Content-Encoding: gzip
Age: 2929
X-Via: 1.1 ydong91:3 (Cdn Cache Server V2.0)[82 200 2], 1.1 PS-PEK-01UVD107:2 (Cdn Cache Server V2.0)[0 200 0]
X-Ws-Request-Id: 5fedaced_PS-PEK-01WKu106_55012-39808
Access-Control-Allow-Origin: *

案例说明

正常的去下载一个文件（附加了Range: bytes=604-700，断点续传头），期望返回正确的文件数据（96b），实际返回发生了严重的BUG

返回了文件全部数据（而不是请求的部分数据）
返回了gzip压缩后的数据

我有测试了在请求头中附加 Accept-Encoding: identity Accept-Encoding: deflate Accept-Encoding: 希望强制返回非gzip数据，都无效

错误分析

未能正确的返回206 Range数据
未能正确的识别Accept-Encoding，返回合规的数据（默认无Accept-Encoding，返回原始数据，不压缩）

希望可以早点看到并回复

liupan1890 commented 3 years ago

测试了一下，6盘Lite客户端 V0.8.3-测试版.zip，也无法正常下载这样的文件------因为被gzip压缩了

liupan1890 commented 3 years ago

nobody care？

zzzhr1990 commented 3 years ago

谢谢反馈，经检查我们存储服务器上文件是正常的，也正确响应了未压缩请求。而似乎CDN侧将文件强制进行了gzip压缩，我们已经向CDN报告该故障，由于尚在假期值班给出的解释如下：对于一定的文件Content-Type和UA，CDN会尝试压缩文件，而且忽视掉Accept-Encoding。能否告知您下载的时候使用的User-Agent头，我们操作增加白名单，CDN厂商应该不会短期内给出patch？

zzzhr1990 commented 3 years ago

sonic@MacBook-Pro ~ % curl "https://bg.grs.jiangsu.scs.tencent.com/oriStore/FtoFW5yGfXO4stiF9FQzrS7Ddvhe" -v -H "Range: bytes=0-1" -o /dev/null % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0* Trying 10.0.31.181...

TCP_NODELAY set
Connected to bg.grs.jiangsu.scs.tencent.com (10.0.31.181) port 80 (#0)

GET /oriStore/FtoFW5yGfXO4stiF9FQzrS7Ddvhe HTTP/1.1 Host: bg.grs.jiangsu.scs.tencent.com User-Agent: curl/7.64.1 Accept: / Range: bytes=0-1

< HTTP/1.1 206 Partial Content < Date: Tue, 16 Feb 2021 19:05:40 GMT < Content-Type: text/plain;charset=UTF-8 < Content-Length: 2 < Connection: keep-alive < Accept-Ranges: bytes < ETag: "FtoFW5yGfXO4stiF9FQzrS7Ddvhe" < Content-Range: bytes 0-1/701 < Last-Modified: Sun, 07 Jul 2019 03:59:35 GMT < X-Reqid: 203322119924325720210217030540bGZZpQ3lsampled < Server: stgw/1.3.12.4_1.13.5 < { [2 bytes data] 100 2 100 2 0 0 28 0 --:--:-- --:--:-- --:--:-- 28

xiaokaixuan commented 3 years ago

@liupan1890 部分文件下载失败显示No URI available和Invalid range header红字错误是这个原因吗？

liupan1890 commented 3 years ago

1 下载请求User-Agent: Accelerider-Lite download engine 2 Invalid range header红字错误是这个原因！！我当时发现此BUG时发现，此BUG是随机文件发生的，就是有的文件不会发生此BUG，有的文件会发生此BUG，或许你们可以根据

GET https://download2.99store.cn/oriStore/FtoFW5yGfXO4stiF9FQzrS7Ddvhe/wcs/user/%E5%88%86%E6%B5%81%E8%BD%AC%E8%BD%BD%E7%9A%84%E5%B8%8C%E6%9C%9B%E8%83%BD%E7%82%B9%E8%BF%9B%E6%9D%A5%E7%9C%8B%E4%B8%8B%3D%20%3D.txt?*******************************ck=aac1bb0f0f0b13388bafdd50a032e802&store=0 HTTP/1.1

这个URL找到此文件进行测试，我遇到的问题是请求206，结果返回200，还被gzip压缩了。当时以为是我程序的BUG，立即使用官方客户端（windows版本uwp和lite都试了），也是一样的不能下载，会报错

错误原理就是：当断点续传下载文件的最后一部分时，比如701B的文件，下载500B-701B这一部分，因为文件整体被gzip了，导致文件体积变小了（比如压缩成600B了）他就无法返回500-701，只能返回完整的文件数据（1-600B）

Invalid range header红字错误：也是，就是说程序请求断点续传，结果返回了完整的数据内容（没有返回Content-Range: bytes 0-1/701），找不到Content-Range报错Invalid range header（非法的range头）

liupan1890 commented 3 years ago

记得多次测试后，经验是，必须是小文件比如1KB以内，最好是txt格式文件，部分文件会出现此错误（也可能是部分节点、或者部分域名download2.99store.cn）。总之错误是确实存在的，但也是类随机的，不是百分百触发。但是如果一个文件触发了此错误，短时间内多次重复下载此文件，都会触发此错误。短时间内无法通过重试下载成功下载

另外我看到你的测试里，

"https://bg.grs.jiangsu.scs.tencent.com/oriStore/FtoFW5yGfXO4stiF9FQzrS7Ddvhe" -v -H Range: bytes=0-1

直接返回了206，是正常的，没有出错，但是：

1.这是测试腾讯的CDN吧？https://download2.99store.cn/oriStore也是走的腾讯cdn吗？免费账号下载的话有的不是走泉州数据中心那个线路吗？ 2.你需要测试Range: bytes=699- 就是测试下载最后的数据（gzip压缩后导致文件体积小+请求最后的数据699超出gzip文件体积===返回200）。你只测试Range: bytes=0-1只能说名正确返回了数据，但你无法证明文件是否被自动gzip压缩了

我刚刚又测试了一下，此文件，正常下载，没有触发此BUG

GET https://cdn8.99store.cn/oriStore/FtoFW5yGfXO4stiF9FQzrS7Ddvhe/wcs/user/%E5%88%86%E6%B5%81%E8%BD%AC%E8%BD%BD%E7%9A%84%E5%B8%8C%E6%9C%9B%E8%83%BD%E7%82%B9%E8%BF%9B%E6%9D%A5%E7%9C%8B%E4%B8%8B%3D%20%3D.txt?***** HTTP/1.1 Host: cdn8.99store.cn User-Agent: Accelerider-Lite download engine Accept: / Range: bytes=0-700

真是迷一样的BUG，可能是与域名（节点）有关

zzzhr1990 commented 3 years ago

我们目前只能确定到节点吐出去的数据是未经压缩的。 CDN侧年前据说有更新系统不知道是不是因为这个原因。

zzzhr1990 commented 3 years ago

记得多次测试后，经验是，必须是小文件比如1KB以内，最好是txt格式文件，部分文件会出现此错误（也可能是部分节点、或者部分域名download2.99store.cn）。总之错误是确实存在的，但也是类随机的，不是百分百触发。但是如果一个文件触发了此错误，短时间内多次重复下载此文件，都会触发此错误。短时间内无法通过重试下载成功下载

另外我看到你的测试里，

"https://bg.grs.jiangsu.scs.tencent.com/oriStore/FtoFW5yGfXO4stiF9FQzrS7Ddvhe" -v -H Range: bytes=0-1

直接返回了206，是正常的，没有出错，但是：

1.这是测试腾讯的CDN吧？https://download2.99store.cn/oriStore也是走的腾讯cdn吗？免费账号下载的话有的不是走泉州数据中心那个线路吗？ 2.你需要测试Range: bytes=699- 就是测试下载最后的数据（gzip压缩后导致文件体积小+请求最后的数据699超出gzip文件体积===返回200）。你只测试Range: bytes=0-1只能说名正确返回了数据，但你无法证明文件是否被自动gzip压缩了

我刚刚又测试了一下，此文件，正常下载，没有触发此BUG

GET https://cdn8.99store.cn/oriStore/FtoFW5yGfXO4stiF9FQzrS7Ddvhe/wcs/user/%E5%88%86%E6%B5%81%E8%BD%AC%E8%BD%BD%E7%9A%84%E5%B8%8C%E6%9C%9B%E8%83%BD%E7%82%B9%E8%BF%9B%E6%9D%A5%E7%9C%8B%E4%B8%8B%3D%20%3D.txt?***** HTTP/1.1 Host: cdn8.99store.cn User-Agent: Accelerider-Lite download engine Accept: / Range: bytes=0-700

真是迷一样的BUG，可能是与域名（节点）有关

那个地址是源站非CDN服务器，是在我们管理范围内，经过测试有正确响应，并且我们已经将Gzip支持关闭了。
Content-Range 头的返回与预期一致，并且没有CONTENT-ENCODING

qingzhenyun / qingzhenyun-api-doc