On Mar 3, 2013, at 3:13 AM, Aki Koskinen <curl_at_akikoskinen.info> wrote:

> On line 100 errno (which is now set to theErr) is examined even though read() returned 0. I tried to remove the test after && on line 100 and run my test again and curl didn't hang on that case.
>
> Any ideas if I might have some truth in my guesswork here?

Okay, thanks to Günter I got the Python server working, and was able to reproduce the problem. And you're right; what's happening is the server is hanging up the socket instead of telling Secure Transport that it is closing the connection. I also found out that this is technically illegal, but common, server behavior. And the receiving code in curl_darwinssl.c was taken from Apple sample code, and that sample code doesn't use non-blocking I/O except in certain circumstances, and I suspect they didn't test for this situation with non-blocking I/O.

I just pushed a change that fixes the problem by removing the above test and watching for errSSLClosedNoNotify in darwinssl_recv(), because I also found while looking at the ST source code that the framework mutates the errSSLClosedGracefully we return in SocketRead() for the benefit of "paranoid clients." Can you please pull the latest code and let me know if it works for you?

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 2013-03-04