Re: Indefinate timeout on HTTP get
Date: Mon, 4 Oct 2010 23:26:45 +0200 (CEST)
On Mon, 4 Oct 2010, curl_at_james-rhodes.demon.co.uk wrote:
> The program periodically does an HTTP GET using the 'easy' interface, in
> it's own thread. On one run it paused for a long time (about 7 hours) before
> returning an error '56' - CURLE_RECV_ERROR
Does it happen often? Regularly? Sometimes? Only once?
> During this period another thread was sucessfully executing FTP gets/puts
> with the curl interface.
That proves the network was functional, but a single connection could still
have problems. Like if a NAT timed out the session or similar.
> It is notable that the call returned just as the the network interface was
Well, at that point the function call probably returned an error which it
> MSDN tells me...
> "If no incoming data is available at the socket, the recv call blocks and
> waits for data to arrive according to the blocking rules defined for WSARecv
> with the MSG_PARTIAL flag not set unless the socket is nonblocking."
> I had thought that Curl used non-blocking sockets internally, but only
> exposed non-blocking behaviour in the multi interface (from previous
> The interesting thing is that I can see from the web-server access_log that
> the response was dispatched (with out error) almost immediately.
Can you also see it happen if you snoop on the network like with wireshark? If
so, it sounds like a bug in libcurl. If so, I would ask you if you can repeat
this problem with the latest libcurl too.
> This is over a wireless broadband device so it possible that there is some
> transparent proxy in the path. It is (currently) my supposition that this
> proxy correctly got the data from the server but then failed to pass it on
> and then also failed to close the TCP connection (and kept it alive).
Yeah, that's what it sounds to me as well. Either that or a bug somewhere
> Is an indefinate timeout the deafult behaviour?
> Is it possible that Curl is stuck doing something else?
Everything is possible, but it isn't a bug that I recognize.
> Can I affect this timeout behaviour with the use of the various TIMOUT
> options? (or is that dangerous)
You can affect this with a CURLOPT_TIMEOUT, by using CURLOPT_LOW_SPEED_LIMIT /
CURLOPT_LOW_SPEED_TIME or implementing your own magic with the callbacks.
-- / daniel.haxx.se ------------------------------------------------------------------- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.htmlReceived on 2010-10-04