On Wed, 18 May 2011, Ethan wrote:

> 4. It seems that the relevant change is a change to gtls.c:handshake, here:
>
> https://github.com/bagder/curl/commit/cbf4961bf3e42d88f6489f981efd509faa86f501#L0L219

Nice work!

> I wanted to ask what the original intent of this change was -- it looks like
> perhaps if the 1-second timeout happens, the for(;;) loop should continue
> and poll for another second? Or is it expected that all handshakes should
> finish in a second, and if it doesn't, there's another problem?

The original problem that lead me to fixing this is linked in the commit
message for cbf4961bf:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=594150

> For now I'm increasing the timeout to ten seconds, but I'm curious what the
> "correct" solution is.

When I read the code now I just can't understand how I ended up with that.

How about using 1000 only if no timeout is set and a blocking connect is
made? Like this:

--- a/lib/gtls.c
+++ b/lib/gtls.c
@@ -255,7 +255,8 @@ static CURLcode handshake(struct connectdata *conn,
          connssl->connecting_state?sockfd:CURL_SOCKET_BAD;

        what = Curl_socket_ready(readfd, writefd,
- nonblocking?0:(int)timeout_ms?1000:timeout_ms);
+ nonblocking?0:
+ ((int)timeout_ms?timeout_ms:1000));
        if(what < 0) {
          /* fatal error */
          failf(data, "select/poll on SSL socket, errno: %d", SOCKERRNO);

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