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
