conf: stalled-download-timeout: make tunable #3031
Conversation
|
If the default is too high, maybe we should just lower it? Adding configuration options seems like a bad solution in general because it requires the user to work around Nix problems. |
|
In this case I'm not sure it is a Nix problem they're working around, but a problem in their network or a problem with their infrastructure. I'm not opposed to it just being lowered, but I don't know what it should be lowered to -- that is why I made it tunable. That said, If there is a good number which would make sense and not be so bad -- I'm not opposed to it being lowered without a tunable. |
doc/manual/command-ref/conf-file.xml
Outdated
| @@ -468,6 +468,14 @@ builtins.fetchurl { | |||
| this option to <literal>true</literal>.</para></listitem> | |||
| </varlistentry> | |||
|
|
|||
| <varlistentry xml:id="conf-low-speed-limit"><term><literal>low-speed-limit</literal></term> | |||
There was a problem hiding this comment.
Maybe change this to something like stalled-download-timeout? low-speed-limit is pretty vague (it's not even clear what speed it refers to).
|
Okay, let's keep the option and change the default to something like 60? |
Make curl's low speed limit configurable via stalled-download-timeout. Before, this limit was five minutes without receiving a single byte. This is much too long as if the remote end may not have even acknowledged the HTTP request.
grahamc
force-pushed
the
low-speed-limit
branch
from
cc30304
to
a02457d
Compare
|
I renamed to stalled-download-timeout and updated the docs and what-not. A much better name :) |
grahamc
changed the title
Make the low speed limit configurable. Before, this limit was five minutes without
receiving a single byte. This is much too long as if the remote end may not have even
acknowledged the HTTP request.