下载报错java.net.ProtocolException: unexpected end of stream排除服务器端问题

Nobody has claimed this yet.

关于这个问题，前面已经看过类似提出以及网上更多的解决办法：
https://blog.csdn.net/lyabc123456/article/details/87368161
https://github.com/lingochamp/FileDownloader/issues/1059
https://stackoverflow.com/questions/45838774/java-io-ioexception-unexpected-end-of-stream-on-connection-in-android#
大神最终分析初步结论为：此问题要想解决必须在服务器端修正响应头中的Content-Length字段，Content-Length必须严格等于响应正文【按照响应头中返回的charset编码】的字节数，或者不用Content-Length字段（如使用Transfer-Encoding:chunked）。
为此，我专门给我的服务器提供商阿里云提交工单，和其来回沟通多日，最终通过我的1台安卓自带模拟器复现，并用wireshark抓包，分析结果如下：
https://workorder.console.aliyun.com/attach/note_attach.do?spm=5176.2020520129.105.5.14bruf&id=74912426&order=0

https://workorder.console.aliyun.com/attach/note_attach.do?spm=5176.2020520129.105.5.14bruf&id=74912426&order=1
阿里云工程师回复：客户端请求的range长度 和返回的 content length是匹配的 没有异常，但是如果okhttp兼容性不够好 实际返回的body大小和length不一致就会抛出异常的话 ，建议查看okhttp源码 看下这块异常判断的逻辑能否跳过。
我是小白，仅供大神参考，并且可以极力拿我当前的这台复现的模拟器进行配合测试，我的Email:20066442@qq.com

Start with the okhttp source path that raises java.net.ProtocolException and reproduce the report using the supplied Android emulator. Compare the captured Range, Content-Length, charset, and response-body byte counts; done means establishing whether the server response is valid and whether the client-side exception logic is responsible.

Written by the indexing model from the issue text.