On Thu, 28 Aug 2003, Early Ehlinger wrote:

> I'm not sure this is appropriate; at the point where the timeout is
> happening, we're already connected and in fact have already accomplished
> some transfers, and are attempting to re-use the existing connection for
> another transfer. From the doc, "This only limits the connection phase,
> once it has connected, this option is of no more use."
>
> The problem in this case is not that the connect is taking to long, it's
> that the connection goes stale "mid-session," while we're traversing the
> directory tree in-between downloads/uploads.

Yes, but that would be a question of what "connecting" means. I would argue
that it could include the initial command-response communication.

> Also, I don't want to set an aggressive timeout on the connect; all the
> TCP/IP stuff can easily make the session painfully slow to set up, even
> though there's actual progress being made the whole time. I.e., a 60-second
> or even 90-second timeout for connect is not unreasonable, even though a 10
> second timeout for server response is probably conservative! I only want to
> govern how long things like CWD, MDTM, MKD, etc., are allowed to take before
> we assume that the connection is dead and allow the application code to
> re-init the curl connection.

You have convinced me. I agree that your suggested timeout setting makes
sense, and perhaps we should even consider to lower the default timeout
somewhat.

-- 
 Daniel Stenberg -- curl: been grokking URLs since 1998
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf