`curl_setopt_array()` not properly honoured when using `CURLOPT_DNS_SERVERS`

[Muffinman]

Description

The following code:

<?php
$options = [
    \CURLOPT_DNS_SERVERS => '8.8.8.8',
    \CURLOPT_CUSTOMREQUEST => 'GET',
    \CURLOPT_URL => 'http://example.com/',
    \CURLOPT_RETURNTRANSFER => false,
    \CURLE_ABORTED_BY_CALLBACK => false,
    \CURLOPT_CONNECTTIMEOUT => 300,
    \CURLOPT_PROTOCOLS => 3,
    \CURLOPT_HTTP_VERSION => 2,
    \CURLOPT_SSL_VERIFYHOST => 2,
    \CURLOPT_SSL_VERIFYPEER => true,
    \CURLOPT_ACCEPT_ENCODING => "",
    \CURLOPT_HTTPHEADER => [
        'Accept-Encoding:',
        'User-Agent: GuzzleHttp/7',
        'Host: example.com',
        'Accept:',
    ],
    \CURLOPT_WRITEFUNCTION => static function ($ch, $write) {
        return strlen($write);
    },
    \CURLOPT_TIMEOUT_MS => 2000.0,
    \CURLOPT_STDERR => fopen('php://stdout', 'w'),
    \CURLOPT_VERBOSE => true,
    \CURLOPT_HEADERFUNCTION => static function ($ch, $header) {
        echo $header;
        return strlen($header);
    },
];

$ch = curl_init();
curl_setopt_array($ch, $options);
curl_exec($ch);

if (curl_error($ch)) {
    echo curl_error($ch);
}
curl_close($ch);

Resulted in this output:

No URL set 

But I expected this output instead:

* Host example.com:80 was resolved.
* IPv6: (none)
* IPv4: 23.215.0.138, 23.192.228.84, 96.7.128.198, 23.215.0.136, 96.7.128.175, 23.192.228.80
*   Trying 23.215.0.138:80...
* Connected to example.com (23.215.0.138) port 80
* using HTTP/1.x
> GET / HTTP/1.1
Host: example.com
User-Agent: GuzzleHttp/7

* Request completely sent off
< HTTP/1.1 200 OK
HTTP/1.1 200 OK
< Content-Type: text/html
Content-Type: text/html
< ETag: "84238dfc8092e5d9c0dac8ef93371a07:1736799080.121134"
ETag: "84238dfc8092e5d9c0dac8ef93371a07:1736799080.121134"
< Last-Modified: Mon, 13 Jan 2025 20:11:20 GMT
Last-Modified: Mon, 13 Jan 2025 20:11:20 GMT
< Cache-Control: max-age=2337
Cache-Control: max-age=2337
< Date: Tue, 28 Jan 2025 11:46:44 GMT
Date: Tue, 28 Jan 2025 11:46:44 GMT
< Content-Length: 1256
Content-Length: 1256
< Connection: keep-alive
Connection: keep-alive
<

* Connection #0 to host example.com left intact

When CURLOPT_DNS_SERVERS is used in the curl_setopt_array() array, all subsequent array keys seem to be ignored or otherwise discarded.

If used in curl_setopt() it works as expected:

// Doing it this way works
curl_setopt_array($ch, $options);
curl_setopt($ch, CURLOPT_DNS_SERVERS, '8.8.8.8');
curl_exec($ch);

Ref: guzzle/guzzle#3265

PHP Version

PHP 8.3.15

Operating System

MacOS 15.2

[Muffinman]

Looking it the source, it seems that curl_setopt_array() bails as soon as it finds an option that returns FAILURE.
Unfortunately not clear what the failure is caused by in this case.

[cmb69]

From https://curl.se/libcurl/c/CURLOPT_DNS_SERVERS.html:

This option requires that libcurl was built with a resolver backend that supports this operation. The c-ares backend is the only such one.

Nothing we can do about that. You should better check the return value of curl_setopt_array().

[Muffinman]

Thanks, yes I see the issue now. Shame I had to dig this deep and waste people's time with the bug report, but I can understand the limitations of not knowing how libcurl was compiled.

I was also expecting an error when I tried curl_setopt($ch, CURLOPT_DNS_SERVERS, '8.8.8.8'); but perhaps there was and I messed up somewhere when testing that.

Thanks again!

[nono303]

Hi @here,
Running own compiled PHP 8.4.4rc2, I can confirm the bug with curl 8.12 (not 8.11.1)
see curl/curl#16216 (comment)

[cmb69]

@nono303, I don't think issue is related to cURL 8.12.0 which only has been the other day.

[nono303]

Fully agree when I saw this issue was opened 1 week ago ^^
I just note that passing CURLOPT_DNS_SERVERS thru curl_setopt_array() have impact on CURLOPT_HEADER return - between curl 8.11 & 8.12 (same code and same php version)
extracting CURLOPT_DNS_SERVERS to curl_setopt() bypass the issue

[nono303]

Fyi, found that curl_setopt($ch, CURLOPT_DNS_SERVERS, 'X.X.X.X'); result depends on my curl 8.12 compilation opts:

• ENABLE_ARES must be ON

🔴 when ENABLE_THREADED_RESOLVER is ON for 8.12 (works with 8.11.1)

php_cURL libcurl/8.12.0-DEV (Windows) OpenSSL/3.4.0 (Schannel) zlib/1.3.1 brotli/brotli/1.1.0 c-ares/1.34.4 nghttp2/brotli/1.1.0 libssh2/1.11.1_DEV
Protocols: dict file ftp ftps gopher gophers http https imap imaps ldap ldaps mqtt pop3 pop3s rtsp scp sftp smb smbs smtp smtps telnet tftp ws wss
Features: ALTSVC ASYNCHDNS BROTLI HSTS HTTP2 HTTPS_PROXY IDN IPV6 KERBEROS5 LARGEFILE LIBZ MULTI_SSL NTLM SPNEGO SSL SSPI TLSAUTH_SRP UNICODE UNIX_SOCKETS ZSTD
------------------------
true    CURLOPT_USERAGENT => Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:133.0) Gecko/20100101 Firefox/133.0
true    CURLOPT_RETURNTRANSFER => 1
true    CURLOPT_HEADER => 1
false   CURLOPT_DNS_SERVERS => 8.8.8.8

✅ when ENABLE_THREADED_RESOLVER is OFF

php_cURL libcurl/8.12.0-DEV (Windows) OpenSSL/3.4.0 (Schannel) zlib/1.3.1 brotli/brotli/1.1.0 c-ares/1.34.4 nghttp2/brotli/1.1.0 libssh2/1.11.1_DEV
Protocols: dict file ftp ftps gopher gophers http https imap imaps ldap ldaps mqtt pop3 pop3s rtsp scp sftp smb smbs smtp smtps telnet tftp ws wss
Features: ALTSVC ASYNCHDNS BROTLI HSTS HTTP2 HTTPS_PROXY IDN IPV6 KERBEROS5 LARGEFILE LIBZ MULTI_SSL NTLM SPNEGO SSL SSPI TLSAUTH_SRP UNICODE UNIX_SOCKETS ZSTD
------------------------
true    CURLOPT_USERAGENT => Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:133.0) Gecko/20100101 Firefox/133.0
true    CURLOPT_RETURNTRANSFER => 1
true    CURLOPT_HEADER => 1
true    CURLOPT_DNS_SERVERS => 8.8.8.8

echo "------------------------".PHP_EOL.Common::curlVersion()."------------------------".PHP_EOL;
const DEFAULT_CURL_OPTS = [
	CURLOPT_USERAGENT	=> "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:133.0) Gecko/20100101 Firefox/133.0",
	CURLOPT_RETURNTRANSFER	=> 1,
	CURLOPT_HEADER		=> 1,
	CURLOPT_DNS_SERVERS	=> '8.8.8.8',
];
$ch = curl_init($url);
foreach(DEFAULT_CURL_OPTS as $k => $v)
	echo (curl_setopt($ch,$k,$v) ? "true" : "false")."\t".PHPCURLopt[$k]." => ".$v.PHP_EOL;
curl_exec($ch);

Unfortunately, THREADED_RESOLVER doesn't appear in curl_version() return.

Looking it the source, it seems that curl_setopt_array() bails as soon as it finds an option that returns FAILURE. Unfortunately not clear what the failure is caused by in this case.

Yes! and setting CURL_OPTS in a loop with curl_setopt instead of curl_setopt_array well fixed curl/curl#16216 (comment) ;)
My dirty fix:

1. disable_functions=curl_setopt_array
2. add to my auto_prepend_file

	function curl_setopt_array(&$ch, $opts){
		foreach($opts as $k => $v)
			curl_setopt($ch,$k,$v);
	}

[Muffinman]

You could make the argument that this the curl_setopt_array responses are poorly handled:

PHP_FUNCTION(curl_setopt_array)
{
	zval		*zid, *arr, *entry;
	php_curl	*ch;
	zend_ulong	option;
	zend_string	*string_key;

	ZEND_PARSE_PARAMETERS_START(2, 2)
		Z_PARAM_OBJECT_OF_CLASS(zid, curl_ce)
		Z_PARAM_ARRAY(arr)
	ZEND_PARSE_PARAMETERS_END();

	ch = Z_CURL_P(zid);

	ZEND_HASH_FOREACH_KEY_VAL(Z_ARRVAL_P(arr), option, string_key, entry) {
		if (string_key) {
			zend_argument_value_error(2, "contains an invalid cURL option");
			RETURN_THROWS();
		}

		ZVAL_DEREF(entry);
		if (_php_curl_setopt(ch, (zend_long) option, entry, 1) == FAILURE) {
			RETURN_FALSE; /* <----- Do we need to return here? */
		}
	} ZEND_HASH_FOREACH_END();

	RETURN_TRUE;
}

There's an argument to be had whether throwing an exception or contining with the rest of the curl opts would be more appropriate than bailing with no immediate feedback.

At least this behavior is correctly outlined in the docs, but I got this deep into debugging here because Guzzle (as probably the most popular PHP cURL client library) aren't checking the return value of curl_setopt_array().