cURL / Mailing Lists / curl-library / Single Mail


Re: Re: SessionHandle is waiting for resolve, but CURL_POLL_REMOVE is called to sockect callback and leads to Connection Closing

From: supercaowei <>
Date: Sat, 4 Jun 2016 19:55:13 +0800

Dear Mr Stenberg:
Thanks for your directions.
But I cannot find, in what way does libcurl tell me that a transfer is completed and the session handle should be removed.
Should I set another callback, or is there a return code indicates that?

As to your questions, There are such facts:
1. I set the option CURLOPT_FOLLOWLOCATION to 1.
2. The session handles of the first request and the second request are the same one. In other words, the second request didnot create a new handle, it just changed the url of the former handle. This is reasonable.
3. The execution entered function "Curl_follow", and soon the socket is removed. The logs below proves these.
19:29:00.088 < Server: nginx
19:29:00.088 < Date: Wed, 01 Jun 2016 11:29:01 GMT
19:29:00.088 < Content-Length: 0
19:29:00.088 < Connection: keep-alive
19:29:00.088 < Location: http://{second host}/connect/oauth2/authorize?appid=46c7ca7b186645f4b1085371872d211e&
19:29:00.088 < Content-Language: en-US
19:29:00.088 <
19:29:00.088 * Connection #5 to {first host} left intact
19:29:00.088 * Issue another request to this URL: 'http://{second host}/connect/oauth2/authorize?appid=46c7ca7b186645f4b1085371872d211e&'
19:29:00.088 * Hostname was NOT found in DNS cache´╗┐
19:29:00.091 * Closing connection 6
4. The redirect url is indeed on a different host. But it's unexpected that the connection to the first host is #5 while the one closed is #6.



Message: 1
Date: Fri, 3 Jun 2016 16:32:45 +0200 (CEST)
From: Daniel Stenberg <>
To: libcurl development <>
Subject: Re: SessionHandle is waiting for resolve, but
    CURL_POLL_REMOVE is called to sockect callback and leads to Connection
Message-ID: <>
Content-Type: text/plain; charset=US-ASCII; format=flowed

On Fri, 3 Jun 2016, supercaowei wrote:

> I sent an https request and the server answered me with a redirected url. So
> the redirected url request would be automatically sent. But, before it was
> sent ( function "Curl_http" was not executed, and the session handle's
> mstate was CURLM_STATE_WAITRESOLVE ) , the execution entered the function
> "singlesocket" in file multi.c. Then, CURL_POLL_REMOVE was called to the
> sockect callabck set by me. So, the socket was removed. In result, the whole
> session handle was removed too and the corresponding connection is closed.
> That means, the redirected url request was never sent.

You leave out some vital information here that makes this hard to follow.

I assume you had CURLOPT_FOLLOWLOCATION set so that it would actually follow
the direct?

If so, was the second URL that it would redirect to on a different host name?
It sounds like that, and if that is true then isn't it expected that your
application should stop caring about the first connection (CURL_POLL_REMOVE)
and then start caring about the new one once it gets created and told about to
the application?

> I traced into the function "singlesocket" in file multi.c, it was executed like below :
> static void singlesocket(struct Curl_multi *multi, struct SessionHandle *data)


> Later, in the socket_cb, I checked how many active sockets the session
> handle still has. When I find it's 0, I destroyed the session handle.

There's your problem. Don't do that. libcurl tells you when the transfer is
completed, and before it has told you the transfer isn't completed and you are
probably better off not trying to second-guess it.

A transfer can very well have no active file descriptors/sockets to monitor
and still be alive. Like when doing a name resolve with the threaded resolver.



List admin:
Received on 2016-06-04