Conan: [regression] Package downloads from Artifactory repo are broken in 1.25.0 due to HTTP error 416

[jasal82]

It seems that the support for resumable downloads added in 1.25.0 breaks package downloads in our build server environment. However, in a local environment the downloads succeed.

Inspecting the Conan trace files shows that on the build server Conan sends requests with the range header set whereas on the local machine these requests are missing.

There should be no proxy communication involved. However, we have a self-signed CA certificate in place for the HTTPS communication with our Artifactory server, but that's also used in the local environment.

I attached two trace files, one from the build server environment and the other from the local machine.

conan_trace-buildserver.log
conan_trace-local.log

[memsharded]

This might be a side effect of https://github.com/conan-io/conan/pull/6791 contribution (cc @flashdagger)

[memsharded]

Thanks for the traces @jasal82! It seems the local one you are running a conan install while the server environment is a conan create. Is this on purpose? Is it possible to have them for the same command to compare? Thanks!

[memsharded]

Also, can you please check and report on the following:

• The Artifactory versions, in both the local and server
• The command line output

[jasal82]

Ah sorry, I didn't notice, sure, I'll run the local one again with create. Artifactory version is 6.17.0 in both cases (same server). Here's the command line output:

edp_toolchain_cortexa9hf/1.0@sick/dev: Retrieving from server 'edp-conan-local' 
edp_toolchain_cortexa9hf/1.0@sick/dev: Trying with 'edp-conan-local'...
Downloading conanmanifest.txt
Waiting 0 seconds to retry...
Waiting 0 seconds to retry...
ERROR: Download failed, check server, possibly try again
Error 416 downloading file https://deagxartifactory.sickcn.net/artifactory/api/conan/edp-conan-local/v2/conans/edp_toolchain_cortexa9hf/1.0/sick/dev/revisions/bb2239506e717baa2e5e9198dfa6c300/files/conanmanifest.txt
ERROR: Download failed, check server, possibly try again
Error 416 downloading file https://deagxartifactory.sickcn.net/artifactory/api/conan/edp-conan-local/v2/conans/edp_toolchain_cortexa9hf/1.0/sick/dev/revisions/bb2239506e717baa2e5e9198dfa6c300/files/conanmanifest.txt
ERROR: Failed requirement 'edp_toolchain_cortexa9hf/1.0@sick/dev' from 'BASE/6.1.0@sick/develop'
ERROR: Download failed, check server, possibly try again
Error 416 downloading file https://deagxartifactory.sickcn.net/artifactory/api/conan/edp-conan-local/v2/conans/edp_toolchain_cortexa9hf/1.0/sick/dev/revisions/bb2239506e717baa2e5e9198dfa6c300/files/conanmanifest.txt. [Remote: edp-conan-local]

[jasal82]

Seems I made a mistake with the local build because I can't reproduce the succeeding build now anymore. Same problem as on the server. I attached the local log of conan create anyway.

conan_trace-local.log

[memsharded]

As a summary of my investigation of today: I have tried to reproduce, locally with an Artifactory 6.17.0 and in the cloud with latest Artifactory. I have forced downloads to be interrupted, they resume correctly. Normal downloads work fine too. I have analyzed the source code without any significant finding.

I would like to know more about the server side, if there is an Nginx, Apache, any special configuration. Thanks!

[flashdagger]

Hi as I trying to wrap my head around it I wonder if the "range" key should be capitalized as I read some servers might be strict about this...
Nevertheless. The problem seems to be that the second request is wrong. Hence the 416 Error (Range not satisfiable). I presume 126 bytes is the expected size of the conanmanifest.txt file.

[memsharded]

The thing is that it shouldn't be failing in the first instance, the first api call to the server should still be exactly the same, and only in case of an interrupted download, will send the header. But an interrupted download from the Artifactory is really unexpected, especially for a conanmanifest.txt. We haven't had this kind of errors before, interrupted downloads were only for very big files in some unusual cases.

[flashdagger]

I agree. Would be good to know the total length and the total downloaded size of the request.

[memsharded]

@flashdagger after a great job of @jasal82 investigating this, it seems that it is related to the difference when gzip is True, because of Accept-Encoding. Checking it for a fix for 1.25.1

[flashdagger]

Excellent! Is it the case where "Content-Encoding" is gzip and "Content-Length" is greater then the actual uncompressed data?

[jasal82]

Yes exactly.

[memsharded]

I have reverted partially in #6996, which means:

• if the server gzips the response, both the resumable downloads and checking the length and raising are disabled, as they were in the past
• if the response is not gzipped (which seems to be true in most cases) the resumable downloads will work. I have forced resumabled downloads in some different servers and it worked oke.
• the management of gzipped responses should be improved in the future if possible

please if @jasal82 if you could try the #6996 branch to make sure it works in your environment with your artifactory, that would be great, and we will try to release 1.25.1 today.

[jasal82]

Patch works fine, looking forward to the 1.25.1 release. Thanks for the quick response.

[memsharded]

Fixed by #6996, will be released next 1.25.1