cURL / Mailing Lists / curl-library / Single Mail


Re: weird timer behavior when re-using existing connection

From: Daniel Stenberg <>
Date: Thu, 19 Jun 2008 00:13:35 +0200 (CEST)

On Wed, 18 Jun 2008, David Lasker wrote:

> I am using libcurl to replace a homegrown Browser implementation. The legacy
> code I am replacing supports individual timeouts for connect, write, and
> read on the socket used to communicate with the remote web server. I am
> trying to replicate these individual timeouts as close as possible, when
> using libcurl to do an HTTP POST.

Doing separate read and write timeouts are not really possible to do easily
with libcurl. But there should be little reason to have them set separately.

> In my libcurl code, I set CURLOPT_CONNECTTIMEOUT to 20 seconds, and
> CURLOPT_TIMEOUT to 100 seconds.

Ah, ok. So there's where the 20000 milliseconds came from.

> I was assuming that CURLOP_TIMEOUT times the entire HTTP transaction, from
> DNS lookup through receipt of data from the remote server, and is inclusive
> of CURLOPT_CONNECTTIMEOUT. Is that correct?


> In the calls libcurl makes to my timer callback function, I can see the 20
> second connect timeout, but I don't see any timing being done after the
> connection is made. Is libcurl making use of CURLOPT_TIMEOUT?

People have reported similar effects before which makes me believe that
CURLOPT_TIMEOUT doesn't work with the multi interface, and I really can't find
any code that would make it do so.

But there really is little reason to support it. I think I'd rather just
document that this timeout doesn't work for the multi interface. At least for
now until someone steps forward and makes the necessary fixes.

> Is there any way to have libcurl enforce a timeout on the total HTTP
> transaction (including write to and read from the web server) when using
> multi?

You can just remove the handle at any point in time yourself when you think
you're done waiting.

Received on 2008-06-19