Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
GitHub is where the world builds software
Millions of developers and companies build, ship, and maintain their software on GitHub — the largest and most advanced development platform in the world.
--retry doesn't retry on connection timeout, if you don't pass --connect-timeout #4461
I did this
240.0.0.1 is a reserved IP address, so connections to it should just time out. When using
If I add an explicit
I suspect the problem is that curl's retry logic doesn't know that
I can sort of see the justification for this, even, if I squint. But this really confused me. In the real situation where I ran into this, I was getting transient errors in CI runs, and curl was reporting them as "connection timed out". So I checked the man page, it says
Previosly all connect() failures would return CURLE_COULDNT_CONNECT, no matter what errno said. This makes for example --retry work on these transfer failures. Fixes #4461
I think the logic has roughly been that the timeout error code is for when libcurl itself decides to give up due to timing constraints, while when a regular libc call fails it ends up in a plain
PR #4462 changes this when connect() fails with a
I'm just a tad bit worried this changes behavior for someone or that by returning a timeout error it might hint for users that they can extend the timeout value and get a better shot at it (which they can't since this is the TCP stack's timeout value which isn't easily accessible).
Maybe the docs for
Yeah, I'm rather convinced that this is the right fix. The little problem I've run into now is that there are three tests failing on the freebsd tests because the port it tries to connect to that it wants a connection refused from (it presumes port 60000 on 127.0.0.1 has nothing listening on it) instead causes an ETIMEDOUT so thus with this PR the return code is different and three tests fail!
@bagder That sounds annoying!
I've noticed before that on macOS, if you try to connect to a port that (a) has a socket bound to it, and (b) that socket has not called
In my case I solved it by switching to port 2 as my "nothing should be there" port. I don't remember why 2 specifically. But using one of the low numbered ports that's been assigned to some protocol that hasn't been used for 50 years seems like a reliable way to get a port where nothing will be happening.