Re: DarwinSSL in infinite loop when server stops arbitrarily?
Date: Sun, 3 Mar 2013 18:49:50 -0700
On Mar 2, 2013, at 10:58 AM, Aki Koskinen <curl_at_akikoskinen.info> wrote:
> Hello, curl people. My first time here.
Hi Aki! Thanks for writing. I wrote the darwinssl code, and this is the first I've heard of this problem.
> I have a weird case with curl using the DarwinSSL functionality. Below is a simple HTTPS server written in Python that is useful in demonstrating the issue.
> The server receives HTTPS connections on port 55556. When a GET request arrives it returns a 200 OK code and a body with the string "Hello, World!". Then it terminates the server after a one second delay (this termination isn't strictly needed to demonstrate the issue but it makes really sure that the server isn't there any more after the request).
Okay, so I did this:
1. Saved the code in your message as a text file called "testserver.py"
2. Exported my test server's certificate from Keychain Access as a PEM to the same folder as testserver.py, as "server.pem"
3. Ran the server: python testserver.py
The server ran, but any time I try to connect curl to it, it connects and then hangs up during the SSL handshake, returning errSSLConnectionRefused when SSLHandshake() is called. Something similar is happening when I try connecting with OpenSSL, so it's not the engine. Am I missing a step, or how do I get this to work? I'm using Mountain Lion Server, and I'm using the stock Python interpreter with no add-ons installed.
> I tried to debug this issue but couldn't find the root cause. I tried the SecureTransport example code provided by Apple . I see that curl's DarwinSSL code is somewhat influenced by this example. The difference is that SSLSample doesn't hang on the test.
SSLSample also only uses non-blocking I/O if you built it with the NON_BLOCKING preprocessor macro, whereas libcurl always uses non-blocking I/O. Non-blocking I/O causes read() to return EAGAIN if the operation would block.
List admin: http://cool.haxx.se/list/listinfo/curl-library
Received on 2013-03-04