On Sunday, 16 September 2012 at 08:44:37 UTC, Johannes Pfau wrote:
Am Fri, 14 Sep 2012 15:54:39 +0200
schrieb "Jonas Drewsen" <[email protected]>:
On Friday, 14 September 2012 at 13:31:50 UTC, Johannes Pfau
wrote:
> I've been using std.net.curl lately and there's a small
> issue with the
> default timeouts:
>
> dataTimeout is documented as:
> /// Set timeout for activity on connection.
>
> but this is not true! timeout_ms actually is "the maximum
> time that you
> allow the libcurl transfer operation to take". This timeout
> is enforced
> even if there is activity. So we currently limit all CURL
> operations to
> 2 Minutes (default limit), which sucks for download managers
> and other
> long-running operations.
>
> We should probably use CURLOPT_LOW_SPEED_LIMIT and
> CURLOPT_LOW_SPEED_TIME instead. Any comments?
This is indeed not good and the comments should be corrected.
CURLOPT_LOW_SPEED_LIMIT and CURLOPT_LOW_SPEED_TIME seems to be
good candidates for an extra option.
I think we should rather keep the comments and make dataTimeout
use
CURLOPT_LOW_SPEED_LIMIT=1 and CURLOPT_LOW_SPEED_TIME. Then we
could add
an extra operationTimeout option for CURLOPT_TIMEOUT.
Don't you think CURLOPT_TIMEOUT is more an operation timeout
than a
dataTimeout? It already includes connect time, so I'd say we
should
call it operationTimeout and not dataTimeout.
It probably is. And if it is acceptable that it might break some
users code that depends on the current behavior I'm all for it.
I'll do a pull request for it and see what the reviewers has to
say about it :)
/Jonas
