On Thu, 16 Feb 2017, Philippe Daouadi wrote:
I am using curl multi with a boost asio backend. On windows only, when I
open a connection that's supposed to be refused (my test connects to
http://127.0.0.1:1/), curl never signals me that the socket couldn't
It seems to work for me on Linux. When we build curl debug-enabled, it also
builds a version of the main loop that uses the event-based system internally
and I can then try that URL like this:
$ ./src/curl --test-event 127.0.0.1:1
curl: (7) Failed to connect to 127.0.0.1 port 1: Connection refused
I am not sure where the bug is, but I think it is in curl. From what I saw in
curl's code, curl does an asychronous connect() and sets a timer (through the
multi's timer callback) to 200ms.
That's the happy eyeballs timeout. It is not really there to detect connect
problems per se, but sure it should make you call libcurl again after 200 ms.
After those 200ms, curl checks that the socket is indeed connected
(CURLM_STATE_WAITCONNECT in multi_runsingle() in multi.c),
The state machine will stay in that state until a connect is verified or
failed, so yes. But for a failed connect, the socket should get a signal too
and the regular "monitoring" of the socket should get triggered, libcurl
should get called again and the failed connection attempt get noticed.
and for some reason windows doesn't return the "connection refused" error
yet. Then nothing more happens, curl doesn't set a new timer to check the
connection again. In the end, the timeout set on the request (if there is
one) triggers and we get a connection timeout error.
Yeah, there's actually an internal "max time limit" for connections (300
seconds), but for some reason this isn't set to an actual timer! (There's a
historical reason for that, but we should probably fix it.)
What I don't understand is why you need a timeout. The failed connection
should get noticed on the socket descriptor itself. That's the actual reason
for this problem.