>> 1) Is the configured easy handle timeout of 2 minutes also relevant
>> for the OpenSSL library, or does OpenSSL has its own timeouts for the
>> handshake phase, which are not under control of libCurl?
>
> The OpenSSL handshake phase is supposed to be non-blocking since about
> 7.15.4 and thus it should be subject to the same timeouts as
> everything else.
>
OK, I looked into issue in libCurl 7.18.1 running on Windows 2000. The
problem itself occured on SW running on QNX, but there are my debugging
possibilities not so good. As you stated, the OpenSSL connection phase
should be under control by the timeouts set with CURLOPT_TIMEOUT or
CURLOPT_CONNECTIONTIMEOUT.
I wrote a little python script which listens to a socket and accepts a
incomming connecion. Nothing more is done in that script. Then I sent a
GET request via an HTTPS URL to that port. libCurl connects fine and
send a "SSL client hello". As the python script does not send anything
back, libCurl waits longer than my configured timeout and "hangs" from
then on. The socket connection is not closed nor is anythink sent back
to libCurl.
Debugging revealed the following. In file ssluse.c, at a certain point
during the SSL handshake, the function ossl_connect_common() is called.
In line 1790 it checks for sockets ready. Sockets are nonblocking, so
the timeout is 0. Curl_socket_ready() returns then 0 every time. That
leads to the return of CURLE_OK. Without any action on the sockets, that
repeats endlessly and longer than the configured timeout.

I think, I observed a very similar situation under QNX. But due to some
reason, after 9 minutes there was action on the sockets and the timeout
check detected the expired timeout of 2 minutes.

Do you also think, there is a problem ?
Received on 2008-04-11