curl / Mailing Lists / curl-library / Single Mail


Re: should curl_multi_timeout() account for CURLOPT_LOW_SPEED_TIME?

From: Rainer Canavan via curl-library <>
Date: Mon, 10 Apr 2017 13:39:54 +0200

On Thu, Apr 6, 2017 at 9:04 PM, Daniel Stenberg <> wrote:
> On Thu, 6 Apr 2017, Rainer Canavan wrote:
>> it looks like curl_multi_timeout() doesn't always respect
> I'm not entirely sure why that is so, but I'd like to mention that the
> CURLOPT_LOW_SPEED_TIME handling and its timeouts were just now changed, in
> commit 29147ade0456a which landed just hours ago.

I can't find that commit anywhere, is that 2d5711dc11 in the github repository?

> When CURLOPT_LOW_SPEED_TIME is set, libcurl should now use no longer than
> 1000ms timeouts.

I've just merged 2d5711dc11 into 7.53.1, and I don't really see an improvement.
curl_multi_timeout() still returns the same erratic values, but
protects itself by limiting the select timeout to 1s, so I suppose I'll have
to do the same.

The other thing is that I would have expected CURLOPT_LOW_SPEED_TIME to
be the actual interval over which the speed is measured, i.e. if a
server does not
send any data for 2 * CURLOPT_LOW_SPEED_TIME seconds, the transfer should
always fail. The actual implementation uses progress.current_speed, which is
averaged over longer periods with the result that bursty transfers are
kept going.
That's perfectly fine, and probably more useful in reality than how I thought it
would work, but I would say the documentation could be clearer.

Received on 2017-04-10