As far as I tested correctly, this is unrelated to not being able to set the option.

Even this simple script runs in 5s no matter what:

$h = curl_init('http://unknown.local:1080/messages');
curl_setopt_array($h, [
    CURLOPT_CONNECTTIMEOUT => 2,
    CURLOPT_TIMEOUT => 2,
]);

curl_exec($h);

strace-ing the scripts, it shows many pool and then a long call like:
futex(0x7fe0741ff910, FUTEX_WAIT_BITSET|FUTEX_CLOCK_REALTIME, 149948, NULL, FUTEX_BITSET_MATCH_ANY

This looks like a curl issue to me.

Note that not being able to set the option is on purpose: the API of HttpClient already provides precise control over timeouts, via the timeout+max_duration options for general config, and via $client->stream($responses, $timeout) for precise timeout control, including connection timeout.

BUT, this is hidden by this futex, and I don't know how to work around it...

I could reproduce a 5 second wait time on MacOS, regardless of the set timeout value. This case could be reproduced in php call or using command line curl connecting to unknown.local host. The issue might not be entirely related to curl. The waiting could be occurring due to the DNS lookup timeout value, which should be addressed at the OS network configuration level.

Closing as this is not related to HttpClient.
See curl/curl#9272 for pointers.

@nicolas-grekas this still is an issue if DNS resolves but the target port is not open:

$h = curl_init('http://172.67.72.38:1080');
curl_setopt_array($h, [
    CURLOPT_CONNECTTIMEOUT => 2,
    CURLOPT_TIMEOUT => 10,
    CURLOPT_VERBOSE => true,
]);

curl_exec($h);

gives:

*   Trying 172.67.72.38:1080...
* After 2000ms connect time, move on!
* connect to 172.67.72.38 port 1080 failed: Connection timed out
* Connection timeout after 2001 ms
* Closing connection 0

So the curl connection timeout still has an effect in certain situations. We encountered this problem lately in a production environment, where a firewall misconfiguration caused the target port to be blocked. I now figured out, it is not possible to configure connection phase timeouts with Symfony HTTP client using curl. Being able to configure the timeout for the whole request time is not enough, as we want to fail fast on connection errors. At the moment we have to set the request timeout to a relatively high value which does not play well with the retry option. This leads to long waiting times on the user's side before giving up.

Would it be possible to reevaluate and eventually allow setting the curl connection timeout again?

Thank you very much!

@deeky666 I suggest you to create a new issue instead of commenting on a closed one (especially when your case is not exactly the same). Opened issues have much more visibility for the community than closed ones.

@nicolas-grekas agree with @deeky666 here. Even if its a curl error. There is no way to workaround zhis in Symfony http-client, essentially you cannot use it with domains not under your control, which then should be documented as a risk

@stof i think its the same issue as mine

Could be fixed by php/php-src#10454

@nicolas-grekas that could fix DNS resolution errors but it won't fix situations where DNS resolves but the client is not able to connect to the host (for example because a firewall rule does not allow to connect to that host/port).

There is nothing we can do about it so 🤷
Let me know if you find a way around.