On Jul 9, 2012, at 5:44 AM, Daniel Stenberg wrote:

> On Mon, 9 Jul 2012, Christian Hägele wrote:
>
>> I think I spotted the problem already. In http.c the function https_getsock is only implemented properly when USE_SSLEAY or USE_GNUTLS is defined, but it is also necessary for USE_SCHANNEL. I attached a trivial patch to fix this.
>
> Thanks, this made me also suspect that the darwinssl layer doesn't work properly. And as darwinssl even has a new state for the non-blocking connection it might in fact need a separate implementation of that function. (CC'ed you Nick because of this!)

And you would be correct; it just freezes when I try adapting the 10-at-a-time example code to use SSL. Oh dear.

I can try to fix this, but before I go about plastering #ifdefs everywhere, I'm wondering if I should just take the new WOULDBLOCK state out of just the darwinssl #ifdef and make it available everywhere, even if only darwinssl would use it for right now. The problem is, unlike other SSL libraries, SecureTransport has only a single "would block" status code when performing a read or write. It is called "errSSLWouldBlock". You can see this for yourself by reading the header file: <http://www.opensource.apple.com/source/libsecurity_ssl/libsecurity_ssl-32463/lib/SecureTransport.h>

Since we don't know whether that means "would block reading" or "would block writing", we have to test for both scenarios in order to be sure. So the question is, would it be okay if I rolled the "would block reading or writing, we're not quite sure yet" state out to all implementations? It seems to me that it would be cleaner, and it wouldn't require changes to other SSL plugins…

Oh, and I already tried implementing custom "would block reading" and "would block writing" status codes in the functions that do socket communications, and SecureTransport didn't know how to interpret them, so it raised errors in response to calling a read/write function. I guess this means returning a dishonest code for one condition or the other would not be a good idea.

Nick Zitzmann
<http://www.chronosnet.com/>

-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2012-07-09