Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.
Sign upIdle time seems to count towards timeout configured in CURLOPT_TIMEOUT #3264
Comments
This comment has been minimized.
This comment has been minimized.
I can confirm that this is indeed how the timeout value is set and used. The timeout is for "the entire operation" and the commands that are sent when shutting down a connection are also included in that "entire operation" - which in a case like described here is far from obvious and a bit strange. It would probably make sense to reset the timestamp when Whatever we decide, we should document this. |
bagder
added
the
libcurl API
label
Nov 13, 2018
bagder
self-assigned this
Dec 8, 2018
added a commit
that referenced
this issue
Dec 14, 2018
added a commit
that referenced
this issue
Dec 14, 2018
This comment has been minimized.
This comment has been minimized.
I've made sure that the timeout is not used anymore when in disconnect "phase". Please have a go and see if #3374 fixes the problem for you! |
jasal82 commentedNov 13, 2018
In my application I'm using libcurl to perform FTP requests via the easy interface. I create a handle with
curl_easy_init()
and keep it open for as long as I need it. Most of the time the handle will be in idle state. Actual calls tocurl_easy_perform()
might occur, but sometimes there will be no request at all before the handle is destroyed viacurl_easy_cleanup()
.curl_easy_cleanup()
sends aQUIT
command to the FTP server. The server implementation I am using wants to respond to that command by sendingBye
on the connection. What I observe now is that ifCURLOPT_TIMEOUT
is set to some valueX
and the time span betweencurl_easy_init()
andcurl_easy_cleanup()
is greater thanX
(without anycurl_easy_perform()
in between), libcurl closes the connection immediately after sending theQUIT
command, making the FTP server fail to send theBye
because the connection is already closed. I tested with multiple values ofCURLOPT_TIMEOUT
and I can confirm that the timeout is directly correlated to the observed behavior.I skimmed through the libcurl sources and it seems that the current timestamp is stored inside the connection handle (
conn->now
). This is done in only one place and that is in theCurl_setup_conn()
function inurl.c
. The stored timestamp is then used to evaluate the timeout by calculating the difference against the current timestamp inCurl_pp_state_timeout()
inpingpong.c
.This tells me that idle time counts towards the timeout which seems unintuitive to me. I don't know where
Curl_setup_conn()
is called but obviously the stored time is updated whenever acurl_easy_perform()
is executed, which is good. That way I can keep the connection open (and fix my problem) by sending periodicNOOP
s on the control connection. But in my opinion it should not be necessary in the first place. The timeout should affect the runtime ofcurl_easy_perform()
only.Maybe I'm using libcurl the wrong way, but I think the behavior is wrong in an application context. It might make sense for command line calls of curl but when using the library functions I would expect that
CURLOPT_TIMEOUT
is equivalent to a transmit timeout and does not count idle time on the handle.The issue can be reproduced on Linux and Windows with the latest version of libcurl.