FileDownloader下载某些源必现报错！[已提供下载链接可复现]
Before Issue
Issue
https://downloads.wamu.org/mp3/dr/19/10/r1191015.mp3
最终都得到了这样的错误反馈：
require range[xxxxxx-) with contentLength(xxxxxxx), but the backend response contentLength is xxxxxxx on downloadId[-xxxxxxx]-connectionIndex[2], please ask your backend dev to fix such problem.
当时OkDownload的作者让我使用单线程来下是可以解决这个问题的。前阵子咨询过你们同样的问题。针对fileDownloader的chunk问题 Issues 说是已经解决了，但是现在问题好像依然存在？
kerneltea
All 22 comments
我用这个链接试了下：https://downloads.wamu.org/mp3/dr/19/10/r1191015.mp3 。
在获取文件大小的时候，无论是使用 GET 还是 HEAD 方法，我们的请求参数里面有 Range 0-0 ，这个时候返回的 Accept-Range 很奇怪，三次返回的都不一样：
bytes 0-0/34700125
bytes 0-11566707/34204425
bytes 23133416-34584349/34584350
注意看最后一部分，那个本应该是文件大小，应该是不变的，我们分块下载时按照第一次返回的 34700125 作为文件大小。所以在实际下载时，和新返回的一个 block 的 content length 不相等。
所以希望你能和服务端确认一下，为什么每次请求返回的 Accept-Range 里面，文件大小在不断变化？这是个动态文件吗？
rantianhua
on 30 Oct 2019
我用这个链接试了下：https://downloads.wamu.org/mp3/dr/19/10/r1191015.mp3 。
在获取文件大小的时候，无论是使用 GET 还是 HEAD 方法，我们的请求参数里面有 Range 0-0 ，这个时候返回的 Accept-Range 很奇怪，三次返回的都不一样：bytes 0-0/34700125
bytes 0-11566707/34204425
bytes 23133416-34584349/34584350注意看最后一部分，那个本应该是文件大小，应该是不变的，我们分块下载时按照第一次返回的 34700125 作为文件大小。所以在实际下载时，和新返回的一个 block 的 content length 不相等。
所以希望你能和服务端确认一下，为什么每次请求返回的 Accept-Range 里面，文件大小在不断变化？这是个动态文件吗？
嗯，现在是这样的，我们是做播客产品的，全球有各个源的提供商，可以播可以下载，所以基本上联系不到对方的提供者，现在的现象是我们可以播(Exoplayer)，但是无法下载，最近我们刚从okdownload迁移回filedownloader，主要原因也是okdownload我们fork了代码一直在改，很多改动已经无法和现有主线merge了，而且这些改动都是在filedownloader中不存在的问题，还有就是okdownload的在下载进队列时经常性卡死，而且现在维护的频率比较慢，所以切回到了filedownloader，但是我们的app最近的用户反馈下载问题比之前用okdownload时要多了，后来查了log发现多半是因为这个问题造成的，所以我想，可能这类源在全球播主那里还是挺多的，可能并不是单方面的某一个源的问题，所以还请咱们团队看看有没有办法解决这类问题。谢谢
kerneltea
on 31 Oct 2019
刚才上面的问题。我们用OKDOWNLOAD的版本。尝试上面的两个源。都可以下载 。还请帮忙看下。是哪的问题？
kerneltea
on 31 Oct 2019
我们刚从 okdownload 转到 filedownloader， 也遇到这个问题。
jinmiao
on 31 Oct 2019
okdownload 没问题
jinmiao
on 31 Oct 2019
filedownloader 下载错误 log: DownloadEngine: download error!
com.liulishuo.filedownloader.exception.FileDownloadGiveUpRetryException: require range[11452988-) with contentLength(5726496), but the backend response contentLength is 5712494 on downloadId[-738789479]-connectionIndex[2], please ask your backend dev to fix such problem.
at com.liulishuo.filedownloader.download.FetchDataTask.run(FetchDataTask.java:105)
at com.liulishuo.filedownloader.download.DownloadRunnable.run(DownloadRunnable.java:121)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:458)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1167)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:641)
at java.lang.Thread.run(Thread.java:764)
jinmiao
on 31 Oct 2019
给大家添麻烦了，先说下维护的事情。因为现在只有我一人在抽时间，计划是把 FileDownloader 的问题解决一些后再着重维护 OkDownload ，现在大部分时间也在维护 OkDownload 的一些东西。由于时间和精力有限，所以给大家造成 OkDownload 维护频率慢的问题。不过可以明确的是，在未来重点还是会放在 OkDownload 上面。
rantianhua
on 31 Oct 2019
@kerneltea 既然你说是播客源的话，那我就明白了，这类是动态资源，应该按照 chunk 的方式去下载，即服务端返回的 response header 里面 Transfer-Encoding 值应为 chunked 。现在看来并不是这样，我再抽时间多试试看。
rantianhua
on 31 Oct 2019
@kerneltea 既然你说是播客源的话，那我就明白了，这类是动态资源，应该按照 chunk 的方式去下载，即服务端返回的 response header 里面 Transfer-Encoding 值应为 chunked 。现在看来并不是这样，我再抽时间多试试看。
您好，辛苦，辛苦，感谢FileDownloader团队对社区的贡献。这里再次感谢！现在Android下载库目前也就是FileDownloader和OkDownloader这两个库比较成熟稳定一些，而且也都是流利说公司的开源项目，从star数上也能看出大家对咱们库的认可。
我们后期也会等OkDownloader稳定后尝试再次迁移回OkDownloader。但是现阶段来看。我们还是认为 FileDownloader更稳定一些，所以还是把FileDownloader库做作为我们App的首先下载库，从上面的留言的朋友来看，应该还是有不少的开发者也遇到了相同的问题，我觉得有必要尝试解决一下这个问题，或者是有没有Workaround的方法来解此问题，因为现在来看OkDownloader库并没有出现此问题，是否可以尝试借鉴一下？我们也不是很了解源码的细节，可能对这里面的技术有一些误区，所以还请帮助再次看看，是否有workaroud的方法绕过该问题？？
再次感谢FileDownloader。。
kerneltea
on 31 Oct 2019
对了还有一个线索提供给你们
之前我在咱们的issues列表中提过一个问题issues
大概的情况就是，在1.4.2的版本是可以正常下载的，后来升到1.5以后就不可以了
不知道这个线索有用没有。还请您帮助看下。。
kerneltea
on 31 Oct 2019
OkDownload 也是我在维护哈哈，会看的会看的，感谢信任。
rantianhua
on 31 Oct 2019
OkDownload 也是我在维护哈哈，会看的会看的，感谢信任。
再次感谢，还有就是刚说的那个线索，我们最开始很早的版本也是用的FileDownloader，版本是1.4.2，当时并没有遇到这些问题，但是升到1.5以后就出现下不了的问题了。当时1.4.2有很多ANR的问题，但是升到1.5以后，由于内部的数据库升级了，我们也没有版本降会到1.4.2了，后来在1.5.X上做了一系列的尝试，无果后，切到了OKDOWNLOADER。这个库解决了下不了的问题，但是出现了一些FileDownloader中不存在的问题，我们TEAM内部大概维护 了一年，发现无法坚持下去，还是决定切回到FileDownloader，这刚切了两周，发现之前1.4.2升1.5之后的问题又暴露出来了。
所以我们也是挺着急的。不知道是否可以加个QQ或微信？我们可以快速提供一些你们需要的数据。或是协助你们一起快速定位这个问题。
我的QQ是100161026
kerneltea
on 31 Oct 2019
通过提供的链接测试已经发现问题，是 FileDownloader 处理 302 的逻辑有问题，会尽快修复。
rantianhua
on 1 Nov 2019
其实问题在于 HttpUrlConnection 默认自动处理了 302 重定向，所以 FileDownloader 就拿不到重定向后的 Location ，这就导致获取的文件大小不对，所以最后在具体下载的时候总是出现大小不正确的问题。解决这个问题也很简单，把 HttpUrlConnection 的自动重定向关掉即可，可以看下我提的 PR 。
发版还需要一些时间，如果你们着急的话可以按照我的 PR 先改一下，或者你们可以用 OkHttp ，使用可见 https://github.com/Jacksgong/filedownloader-okhttp3-connection .
其实 OkDownload 也有这个问题，你们用的时候发现 OkDownload 没有问题应该是你们同时引用了 com.liulishuo.okdownload:okhttp 这个库，此时网络请求会走 OkHttp , OkHttp 默认没有自动处理，所以我们的自己的重定向逻辑可以起作用。OkDownload 那边内部的 DownloadUrlConnection 我也会提 PR 纠正的。
rantianhua
on 1 Nov 2019
不过我们用的是okhttp呀
kerneltea
on 2 Nov 2019
其实问题在于 HttpUrlConnection 默认自动处理了 302 重定向，所以 FileDownloader 就拿不到重定向后的 Location ，这就导致获取的文件大小不对，所以最后在具体下载的时候总是出现大小不正确的问题。解决这个问题也很简单，把 HttpUrlConnection 的自动重定向关掉即可，可以看下我提的 PR 。
发版还需要一些时间，如果你们着急的话可以按照我的 PR 先改一下，或者你们可以用 OkHttp ，使用可见 https://github.com/Jacksgong/filedownloader-okhttp3-connection .
其实 OkDownload 也有这个问题，你们用的时候发现 OkDownload 没有问题应该是你们同时引用了 com.liulishuo.okdownload:okhttp 这个库，此时网络请求会走 OkHttp , OkHttp 默认没有自动处理，所以我们的自己的重定向逻辑可以起作用。OkDownload 那边内部的
DownloadUrlConnection我也会提 PR 纠正的。
现在用的就是OKHTTP..所以还是帮忙在确认下
FileDownloader.setupOnApplicationOnCreate(context.applicationContext as Application)
.connectionCreator(CustomOkHttp3Connection.Creator(proxy.getOkHttpBuilder().build()))
.database(NoDatabaseImpl.createMaker())
.maxNetworkThreadCount(1)
.commit()
kerneltea
on 2 Nov 2019
对了，我们用的是okhttp4.0的版本
kerneltea
on 4 Nov 2019
@kerneltea 跟 OkHttp 版本没有关系。我之前说 OkHttp 默认没有自动处理重定向是错误的，不好意思，它也会自己处理。而 OkDownload 没有问题是因为，在 com.liulishuo.okdownload:okhttp 里，我通过 OkHttp 的 Response 检查了前一个 Request 是否是重定向，如果是的话，通过 OkHttp 取出重定向的 Location ，所以 OkDownload 里面没有问题。
OkHttpClient 也暴露了接口可以关闭自动重定向：OkHttpClient.Builder.followRedirects 和 OkHttpClient.Builder.followSslRedirects 。你可以关闭之后看看下载是否正常恢复了。
rantianhua
on 4 Nov 2019
好的我试下
kerneltea
on 4 Nov 2019
OkHttp
刚才验了下，问题已经解决了，非常感谢！请问这种方法是workaround的方法，还是后续会有修复？
kerneltea
on 4 Nov 2019
针对 FileDownloader 和 OkDownload 的默认 Connection 已经修复。针对 FileDownloader 使用 OkHttp 的话，按照刚才说的设置取消默认重定向即可，这个在 FileDownloader 外部也很好操作，OkDownload 的 OkHttp library 里面本身已经不存在这个问题。
综上，可以理解为该问题已修复。
rantianhua
on 4 Nov 2019
OK 。谢谢，那我关掉这个问题了，非常感谢帮忙查看该问题！
kerneltea
on 4 Nov 2019
Related issues
vd92
·
3Comments
congwiny
·
4Comments
logan62334
·
3Comments
Jeffin21
·
4Comments
a483210
·
4Comments
Most helpful comment
OkDownload 也是我在维护哈哈，会看的会看的，感谢信任。