On Thu, 31 Aug 2006, Dmitriy Sergeyev wrote:

> First of all, thanks a lot for such perfect library. I hope its developing
> will never stopped.

I'm happy you like it and I appreciate your help to improve it further!

> It seems like I have found bug in mult_runsingle at the multi.c(639).
> Now multistate(easy, CURLM_STATE_WAITCONNECT) stated there
> and libcurl always switches state to CURLM_STATE_WAITCONNECT
> regardless of is the protocol connect was performed
> (protocol_connect variable).
> But if protocol connect was performed and we are switching to
> CURLM_STATE_WAITCONNECT state then as result of it protocol specific
> connection routine such as Curl_http_connect tries to perform 3
> times and after that connection fails.
> I think in this case libcurl behavior must be the same as in
> CURLM_STATE_CONNECT. If we have already performed protocol connect
> then we should go directly to CURLM_STATE_DO state.

Sounds like a reasonable conclusion, yes.

> I.e. we need to replace multi.c(639):
> multistate(easy, CURLM_STATE_WAITCONNECT);
>
> with following:
> result = CURLM_CALL_MULTI_PERFORM;
>
> if(protocol_connect)
> multistate(easy, CURLM_STATE_DO);
> else
> multistate(easy, CURLM_STATE_WAITCONNECT);

I don't think the CURLM_CALL_MULTI_PERFORM assignment should be there like
that, and in fact I'm not sure it should be like that in the
CURLM_STATE_CONNECT case either.

Can you try your test case again without that line and see if it causes any
noticable problem? If it must be there, it should at least only be set for the
STATE_DO case.

> I have libcurl 7.15.5. 7.15.1 version of libcurl haven't this bug and works
> properly with this specific server.

Yeah, I've made some pretty drastic internal changes in the multi.c code
recently that have introduced some bugs but on the other hand I've introduced
the curl_multi_socket() API...

-- 
  Commercial curl and libcurl Technical Support: http://haxx.se/curl.html