Hi,

it looks like curl_multi_timeout() doesn't always respect
CURLOPT_LOW_SPEED_TIME.
In therory, I'd expect all timeouts "suggested" by
curl_multi_timeout() to be less than or
equal to the lowest of CURLOPT_TIMEOUT and CURLOPT_LOW_SPEED_TIME that
is set in any curl handle it examines, and -1 if none is set. However,
if I alter
docs/examples/multi-app.c to set

 curl_easy_setopt(handles[HTTP_HANDLE], CURLOPT_TIMEOUT, 50);
 curl_easy_setopt(handles[HTTP_HANDLE], CURLOPT_LOW_SPEED_TIME, 2);
 curl_easy_setopt(handles[HTTP_HANDLE], CURLOPT_LOW_SPEED_LIMIT, 100000);

and point it to a script, that prints more than SPEED_LIMIT bytes and
only a trickle
every second after that, and check the timeouts computed by
curl_multi_timeout(),
the results are somewhat surprising:

0, 199, 195, [...] 188, 188, 1, 49798, 2000, 999, 46795, 2000, 999,
43794, 195, 194,

If a server happens to stop transmitting when the select() waits until
the TIMEOUT, the
LOW_SPEED_LIMIT basically does not apply. Tested with curl 7.53.1.

A trivial workaround, namely to ignore the result of curl_multi_timeout() if
it is greater than LOW_SPEED_TIME seems to work for me.

rainer
-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.haxx.se/mail/etiquette.html
Received on 2017-04-06