On Fri, 16 May 2008, Jeff Weber wrote:

> In all my tests, I defined a progress callback to enforce timeouts. In the
> test where I started an FTP upload to a non-DNS IP address with a broken
> network connection (i.e. curl should fail to connect to remote host), poll()
> was passed a timeout of 299998 msec. In another test where I was in the
> middle of uploading N files, and broke the network connection, poll() was
> passed a timeout of 3600000 msec. Is there a bug, in that registering a
> progress callback should have changed all poll() timeouts to 1000 msec, but
> didn't?

Yes, that's exactly what I tried to say in my previous mail. It should wait
for input for the specified time, but it should still call the progress
callback every second while doing so.

> The Curl documentation still warns that active FTP connections can block.
> Can I depend upon CURLOPT_CONNECTTIMEOUT, CURLOPT_TIMEOUT,
> CURLOPT_FTP_RESPONSE_TIMEOUT to always timeout a FTP connection?

If you're using c-ares you can depend on that, as blocking doesn't mean it
can't be aborted. Blocking in this sense means that it doesn't return
immediately but instead will sit waiting for something to happen before it
returns.

> That depends if I will need the progress callback to enforce my FTP connect,
> transfer timeouts.

Well, if you reach the timeout places previously mentioned they will "hang"
there until they times out or until there's input on the socket. That's a bug
and that's what I'm talking about. If that will hurt you in the end or not is
really up to you to figure out and analyze.

-- 
  Commercial curl and libcurl Technical Support: http://haxx.se/curl.html