-
Notifications
You must be signed in to change notification settings - Fork 2.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Do not cancel downloads behind proxy just because it is slow #5717
Comments
You should be able to add global [http]
timeout = 1000000 would that work for your use case? |
Unfortunately not. I am already using a very long timeout. The error message also does not appear after a certain amount of time(out). It is immediately appearing (I assume as soon as the connection is established). I've tried many things, including a local mirror of the crates.io-index. The index seems to be ok, since it is trying to download the first crate. As said, and as others have reported, I guess it wouldnt be a problem if our proxy wouldn't send any data. But it does, which must trigger some exception in the cargo chain. |
Hm this may either be a bug in curl, the proxy, or a timeout in curl that we accidentally aren't configuring? I'm not entirely sure unfortunately :( If you're using a super long timeout already though and it's failing quickly, then that probably means it's a bug in how we're telling curl about timeouts (maybe we're missing one?) |
Curl provides these two options
An option to override those would probably be enough. Or Cargo sets higher values if a proxy is configured. |
It looks like Cargo doesn't currently have the ability to overrides its configuration of |
Thanks for providing the location. This is exactly our problem since the proxy only sends 5 bytes/sec. I can try to work on a PR. |
Ah yeah a |
Here´s how to reproduce the issue (adjust tc to your network adapter).
to clear tc call How to reproduce (you have to limit bandwith after the index is updated and cargo starts downloading crates...otherwise a simple timeout will occur)
Result (without stupid company proxy) $ cargo build |
Fixes rust-lang#5717 low-speed-time was removed because the corresponding curl-option is already set via http.timeout. removed unnecessary Option.
Provide http-config option for curl low-speed-limit/time Fixes #5717 Provides new override options for curl in Cargo http config-section. ``` [http] timeout = 2 low-speed-limit = 5 ``` Test with the following during crate-download `sudo tc qdisc add dev eth0 handle 1: root htb default 11 && sudo tc class add dev eth0 parent 1: classid 1:1 htb rate 8bps && sudo tc class add dev eth0 parent 1:1 classid 1:11 htb rate 8bps` Clear with `sudo tc qdisc del dev eth0 root`
Updates rust-lang#5717 Since people tend to copy/paste, the docs should not use the option which will disable curls low-speed-limit. Rather use a value lower than the default of 10
Do not use a disabled-option in the docs Updates #5717 Since people tend to copy/paste, the docs should not use the option which will disable curls low-speed-limit. Rather use a value lower than the default of 10 Also reverts removal of default low-speed-time (30s) in case no timeout is configured
Our company proxy is also scanning the downloaded artefacts. While doing so, it still sends some data (5 bytes/sec), probably in order to keep the connection alive.
Cargo thinks this is to slow and stops with an error.
Can we have an option to ignore this check?
The text was updated successfully, but these errors were encountered: