cURL / Mailing Lists / curl-library / Single Mail

curl-library

Re: Using CURLOPT_CONNECT_ONLY option in multi interface

From: Daniel Stenberg <daniel_at_haxx.se>
Date: Mon, 17 Oct 2011 23:29:45 +0200 (CEST)

On Thu, 13 Oct 2011, Gökhan Şengün wrote:

> I would like to use CURLOPT_CONNECT_ONLY option and still be able to see if
> connecting to FTP server is finished with curl_multi_info_read function so
> that I can inform the other thread driving mine regarding the result of
> CONNECT command.
>
> Checking the code, I saw that in function multi_runsingle in file multi.c,
> easy connection's state is set to CURLM_STATE_DONE instead of
> CURLM_STATE_COMPLETED. When in this state, the easy handle is not considered
> as "finished" and I can not get the result of my request with
> curl_multi_info_read.
>
> if(data->set.connect_only) {
> /* keep connection open for application to use the socket */
> easy->easy_conn->bits.close = FALSE;
> *multistate(easy, CURLM_STATE_DONE);*
> easy->result = CURLE_OK;
> result = CURLM_OK;
> }
>
> If I change the state in above code to CURLM_STATE_COMPLETED, I got the
> behavior I really like to have.
>
> Could you please tell if the current design is the intended behavior? Or I
> am missing something here? And if there is any work-arounds?

I don't exactly remember when or why we did that change, as I'm not really
aware of any users who use CURLOPT_CONNECT_ONLY with the multi interface. I
can see how your change is necessary but I'm just a little concerned that just
skipping over a lot of states like that might leave something behind that
shouldn't be left...

Do all test cases still run fine with this change?

Would you be able to work on writing a new test case that uses exactly this
feature with the multi interface so that we can make sure that it works fine
and will remain working fine in the future?

-- 
  / daniel.haxx.se

-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2011-10-17