1.4.2的版本可以正常下载的源在最新版本后无法下载！

[kerneltea]

您好，我也遇到了这个链接的问题:#678

但是我认为这并不是后端造成的问题，我们的APP使用咱们的下载库。但是一直没有升级，一直使用的是1.4.2的版本，之前尝试升级到1.5.X的版本，遇到过一次这类的问题，因为这个错误影响很大，所以为了确保稳定性，后来只能重新降回1.4.2继续使用，又过了一阵子，也就是最近这几天，我们再一次尝试升级到1.6.8的版本，可是发现问题依然存在，我们用两个版本来测试，先前1.4.2的版本可以正常下载 ，1.6.8的版本则不可以，我们下载的源就是NPR系列的播客，批量下载会很容易出现这个问题，而且出现这个错误后，再次单独下载则没有这个问题！

使用单连接下载方案一

1. 在filedownloader.properties中配置不使用独立进程: 实现FileDownloadHelper.ConnectionCountAdapter，并在里面配置需要单连接的连接缓存，当下载出现类似错误的时候，将连接加入缓存，然后重新下载。
2. 通过FileDownloder.setupOnApplicationOnCreate注册该ConnectionCountAdapter

使用单连接下载方案二

1. 实现FileDownloadHelper.ConnectionCountAdapter全局都该用单线程下载。

使用上面的方法后依然有问题，单个下载没什么问题，问题主要出现在批量下载上，所以我认为在批量下载的时候，对应的content-length没有查看是否为该URL对应的response。这只是我的猜测，希望可以给你们一些线索

我的联系方式：
kerneltea@gmail.com

[rantianhua]

多谢提供的信息，我会针对你提供的信息进行更多测试。

[kerneltea]

这是我的代码。

[Jacksgong]

我没有理解该issue的问题所在，如果是#678的问题，已经解释的很清楚了，所谓有没有问题是RFC定义的，并不是我们讨论定义的（如: 1, 2 ），而是否是即便是后端返回的content-length不是请求的区间大小，只要content-length大于请求的range的大小，并且通过content-range获知区间在请求range内，那么便依然下载，忽略有可能带来的额外的TCP窗口缓存的流量开销，这些点有待商榷，如果是本身就是非常不make sense的点，并且只是为了解决一些不符合rfc的问题，只有可能会在okdownload修复。

如果你认为后端是正确的，还希望拿出对应的rfc文档，以及给出对应情况的处理方案，甚至直接PR谢谢。

由于这里存在较多讨论点，在1.7.3不会带上。

[kerneltea]

但是同样的链接，在1.4.3的版本并没有发现异常，而且国外的很多源都会有问题。我使用了 VPN下载。不知道这个会不会有影响
在下面的链接里我做了一些分析
lingochamp/okdownload#31

[Jacksgong]

该问题已经在okdownload中进行答复与跟进，该task中将关闭该Issue。

Ref to : lingochamp/okdownload#31