Daniel Stenberg wrote:
> On Tue, 6 Aug 2013, Patrick Monnerat wrote:
>
>>> I've made a first go at that
>
>> Good job. May be one more state for SSL handshake ?...
>
> Hm, that's not a bad idea. I also thought about exposing the sub-state of
> FTP or SFTP somehow.

A CURLXFER_SECURITY would be a nice generic state for logins,
SSL handshake, etc?

> The little problem I have with exposing the SSL handshake is that it isn't
> currently very obvious in the multi state machine of today, which is the
> state I basically just expose (only slightly converted) in this patch.
>
> Also, in most cases the SSL handshake state will be very brief anyway so I'm
> not sure it is worth the extra detail. The same goes for FTP and SFTP
> details really...

Unless the authentication server at the other end is down and one
finds oneself in a protracted, inexplicable, delay as the web server.
tries to talk to it. Also, if you intend to log/report this state
upon failure, then were you are would be useful, even if it's
typically a very transient state.

Might be useful to provide some macros which classify these states?

#define CURLXFER_CONNECTING(s) \
            (s >= CURLXFER_NAMERES && s <= CURLXFER_PROXYCONNECT)

#define CURLXFER_TRANSFERRING(s) \
            (s >= CURLXFER_WAITDO && s <= CURLXFER_TOOFAST)

Then adding more states does not affect the ability to tell which
generic phase of operations one is in.

Or one could do it SMTP status-ish, with 3 digit codes with the
hundreds digit defining major states and tens and ones defining
sub_states. Would make it easy to stick in new ones without
disrupting existing ones. Of course, this might be getting
crazy...

Cheers!
Rich
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2013-08-06