conan: [bug] Downloading a big package fails with Incorrect Content-Range header

Environment Details (include every applicable attribute)

  • Operating System+version: Ubuntu 20.04
  • Compiler+version: clang 9
  • Conan version: 1.39.0
  • Python version: 3.8.10

Steps to reproduce (Include if Applicable)

  • Simply trying to run conan install android-ndk/r21d@ yields the error, the download fails, keep retrying and failing the same way.
  • The same error happens with a different android NDK package.

This seems similar to #7498 except the package is on Conan center in this case.

Logs (Executed commands with output) (Include/Attach if Applicable)

conan install android-ndk/r21d@
Configuration:
[settings]
arch=x86_64
arch_build=x86_64
build_type=Release
compiler=clang
compiler.libcxx=libstdc++11
compiler.version=9
os=Linux
os_build=Linux
[options]
[build_requires]
[env]
CC=/usr/bin/clang-9
CXX=/usr/bin/clang++-9
Installing package: android-ndk/r21d
Requirements
    android-ndk/r21d from 'conan-center' - Cache
Packages
    android-ndk/r21d:4db1be536558d833e52e862fd84d64d75c2b3656 - Download

Installing (downloading, building) binaries...
android-ndk/r21d: Retrieving package 4db1be536558d833e52e862fd84d64d75c2b3656 from remote 'conan-center' 
Downloading conanmanifest.txt completed [1028.25k]                                       
Downloading conaninfo.txt completed [0.20k]                                              
Downloading conan_package.tgz completed [1056295.44k]                                    
ERROR: Download failed, check server, possibly try again
Download failed, check server, possibly try again
Error in resumed download from https://center.conan.io/artifactory/api/conan/conan-center/v1/files/_/android-ndk/r21d/_/5013605c2f2c7c4cd448ea2d5c77e274/package/4db1be536558d833e52e862fd84d64d75c2b3656/f0d2c0a89bfe4745335cfea2ce9fd5d4/conan_package.tgz
Incorrect Content-Range header 
Waiting 0 seconds to retry...
Downloading conan_package.tgz completed [1057303.94k]                                    
ERROR: Download failed, check server, possibly try again
Download failed, check server, possibly try again
Error in resumed download from https://center.conan.io/artifactory/api/conan/conan-center/v1/files/_/android-ndk/r21d/_/5013605c2f2c7c4cd448ea2d5c77e274/package/4db1be536558d833e52e862fd84d64d75c2b3656/f0d2c0a89bfe4745335cfea2ce9fd5d4/conan_package.tgz
Incorrect Content-Range header 
Waiting 0 seconds to retry...

About this issue

  • Original URL
  • State: open
  • Created 3 years ago
  • Reactions: 1
  • Comments: 31 (18 by maintainers)

Most upvoted comments

I can verify that it fails in 1.59, in our gcc11 docker image, without using revisions:

Downloading conanmanifest.txt completed [1068.21k]
Downloading conaninfo.txt completed [0.29k]
Downloading conan_package.tgz completed [1060490.69k]
ERROR: Download failed, check server, possibly try again
Download failed, check server, possibly try again
Error in resumed download from https://center.conan.io/artifactory/api/conan/conan-center/v1/files/_/android-ndk/r21e/_/6de6a2d288f9ce3fa5bbd402d018652d/package/4db1be536558d833e52e862fd84d64d75c2b3656/86fc1b96570ed8e6f476bb21e809ad0d/conan_package.tgz
Incorrect Content-Range header
Waiting 0 seconds to retry...
Downloading conan_package.tgz completed [1057562.31k]
ERROR: Download failed, check server, possibly try again
Download failed, check server, possibly try again
Error in resumed download from https://center.conan.io/artifactory/api/conan/conan-center/v1/files/_/android-ndk/r21e/_/6de6a2d288f9ce3fa5bbd402d018652d/package/4db1be536558d833e52e862fd84d64d75c2b3656/86fc1b96570ed8e6f476bb21e809ad0d/conan_package.tgz
Incorrect Content-Range header

It finally succeed, but it seems a good start to reproduce. Next steps:

  • see if it fails with revisions enabled
  • see if it fails when downloading from other server, not ConanCenter (could be a server side, memory issue or something like that?)

Thanks @jblort If we can reproduce this against the ConanCenter server, removing the client side, that would help reporting something against Artifactory if necessary.

Trying to follow up on this, sorry that we haven’t been able to prioritize this enough.

I can still reproduce this with:

λ curl https://center.conan.io/artifactory/api/conan/conan-center/v1/files/_/android-ndk/r21d/_/d6416b530a0cbadc7aa8f7f6f8942757/package/4db1be536558d833e52e862fd84d64d75c2b3656/4dea2f1dfa5d49d6209017f94958ab19/conan_package.tgz --output my_conan_package.tgz
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
 87 1181M   87 1034M    0     0  6479k      0  0:03:06  0:02:43  0:00:23 5843k
curl: (56) Failure when receiving data from the peer

So still an issue 😦, and still an issue related specifically to ConanCenter only, which makes it more challenging 😦

ConanCenter has a CDN in front of it, and files should be served by the CDN. Adding @davidsanfal just in case he knows some CDN limitation or something like that.

But this problem have been constantly reproducsing without revisions.

Conan 2.0 uses the revisions API always, and using revisions has been the recommended approach in 1.X too. I don’t think that there is something that different in API v2 that would fix it and I am afraid that we might see issues too, but if it is fixed with revisions, that would be great.

I didn’t check for my own server but, I already have it there, so, I can check it if needed.

Yes, please, it would be super useful to know if it fails only from ConanCenter or other servers too.

I need to remove this from the milestone, as we haven’t manage to reproduce so far. There are many things that can affect here, network issues, proxies, etc, so this might be challenging to solve. I am closing it, as there is little more we can do, but if anyone keeps persistently hitting this issue, or have any possible way to reproduce, please re-open or create a new ticket.

Many thanks to all for all the feedback!

As using revisions is recommended anyway, and Conan 2.0 (already in alpha.4) is always using revisions, I am not sure that such a fix would land in a useful time window.

OK, thanks for that info. We will simply enable package revisions from now on since that seems to solve the issue.