Here's the fix that a colleague (Katie Wang) has come up with (apologies if this is not the proper process through which code contributions are made):

Index: lib/ssluse.c
===================================================================
RCS file: /home/engineering/cvs/external/curl-7.15.1/lib/ssluse.c,v
retrieving revision 1.1
diff -u -5 -r1.1 ssluse.c
--- lib/ssluse.c 16 Feb 2006 03:36:44 -0000 1.1
+++ lib/ssluse.c 12 Apr 2006 21:11:04 -0000
@@ -1304,18 +1304,23 @@
 
     /* Find out if any timeout is set. If not, use 300 seconds.
        Otherwise, figure out the most strict timeout of the two possible one
        and then how much time that has elapsed to know how much time we
        allow for the connect call */
- if(data->set.timeout || data->set.connecttimeout) {
+ if(data->set.timeout && data->set.connecttimeout) {
 
       /* get the most strict timeout of the ones converted to milliseconds */
- if(data->set.timeout &&
- (data->set.timeout>data->set.connecttimeout))
+ if(data->set.timeout < data->set.connecttimeout)
         timeout_ms = data->set.timeout*1000;
       else
         timeout_ms = data->set.connecttimeout*1000;
+ }
+ else if(data->set.timeout) {
+ timeout_ms = data->set.timeout*1000;
+ }
+ else if(data->set.connecttimeout) {
+ timeout_ms = data->set.connecttimeout*1000;
     }
     else
       /* no particular time-out has been set */
       timeout_ms= DEFAULT_CONNECT_TIMEOUT;
 

Daniel Stenberg wrote:
> On Mon, 10 Apr 2006, Ates Goral wrote:
>
>> Here, if CURLOPT_TIMEOUT is greater than CURLOPT_CONNECTTIMEOUT,
>> CURLOPT_TIMEOUT will be used. So, "most strict timeout" in this
>> context seems to be different than it is with non-SLL operation.
>>
>> Is this a bug or a feature (or am I missing something)?
>
> Given that even the comment surrounding this code says that the code
> works the way you expected it to, I can only conclude that this is a
> bug and I'll fix it immediately!
>
> Thanks!
>
Received on 2006-04-13