On Wed, 11 Nov 2009, Kamil Dudka wrote:

> Moreover the current blocking implementation of SSL connecting is probably
> incorrect anyway since it may fail completely on PR_ERROR_WOULD_BLOCK:

I had a look at this just now. I must agree that it is funny that this hasn't
caused pain for anyone yet. I guess one way to force this to happen to get
tested, is if you can somehow enforce some kind of slow-down magic on an
interface so that you get traffic byte-per-byte[*].

The "correct" way of fixing this flaw is probably to make sure we implement a
function for non-blocking connects and make sure we define
'curlssl_connect_nonblocking' to identify it. This is done already in the
OpenSSL glue code so inspiration could be gotten from there.

The point is quite simply to do as much as possible and not block, and it will
get called again until it has completed and then it sets *done = TRUE so that
the parent then happily moves on.

[*] = some ideas on how to accomplish this include:
http://monkey.org/~marius/pages/?page=trickle and
http://wanem.sourceforge.net/ but I've not personally tried either one.

-- 
  / daniel.haxx.se
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html