On 26 Sep 2002, yarram sunil wrote:

> >I don't agree. CURLE_OPERATION_TIMEOUTED is returned when a timeout set by
> >you has elapsed. If it fails for normal/default network reasons,
> >CURLE_COULDNT_CONNECT is returned.
>
> Let me put my problem here. I can connect to more than one proxy. if my
> first proxy is down then i should connect to another proxy and the only way
> to know my first proxy was down is through the error code returned by curl
> as CURLE_COULDNT_CONNECT. If i get a CURLE_OPERATION_TIMEOUTED then i
> cannot distinguish whether it has happened during the connect time or a
> overall timeout.
>
> It would be better if a new error code CURLE_CONNECT_OPERATION_TIMEOUTED
> returned rather than CURLE_OPERATION_TIMEOUTED when connection time out is
> reached.

Ok, this clearly identifies your problem indeed.

But if your read-callback never was called, you can pretty safely assume that
the transfer didn't begin, right? Then you know that the time-out happened
during the connect phase.

Introducing a CURLE_CONNECT_OPERATION_TIMEOUTED timeout would make it more
complicated internally. This brings back an old idea of mine: to add some
kind of callback for "states" in operations, so that an application would
know in which "state" the current transfer is. Optionally to set an internal
variable to a state name so that the application could query the handle after
a timeout (or whatever) how far it actually did reach.

-- 
 Daniel Stenberg -- curl related mails on curl related mailing lists please
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf