curl_setopt() In Feed Options?

[markmcwilliams]

On upgrading my blog(s) from 2.9 RC1, to the final 2.9 release, I encountered a problem were on the WordPress Development Blog feed, and the Plugins feed it would show this error...

Warning: curl_setopt() [function.curl-setopt]: CURLPROTO_FILE cannot be activated when in safe_mode or an open_basedir is set in /home/XXXXXXXX/public_html/wp-includes/http.php on line 1302

Warning: curl_setopt() [function.curl-setopt]: CURLPROTO_FILE cannot be activated when in safe_mode or an open_basedir is set in /home/XXXXXXXX/public_html/wp-includes/http.php on line 1303

...then show the actual correct information! So I'm not 100% sure whats going on, if anyone does, it'd be good to find out! :)

In fact, thinking about it, although I'm not 100% sure, this problem could have been in 2.9 RC1! I should have looked before hitting the upgrade button, but I never!

#11468

I was unable to reproduce with PHP Version 5.2.8 WINNT CFGI, safe_mode ON (cURL support: enabled; cURL Information: libcurl/7.16.0 OpenSSL/0.9.8i zlib/1.2.3). Attached you'll find a plugin I've used to force and ensure that CURL transport is used. URLOPT_TIMEOUT_MS was not available with that config, but the alternative lines 1306 / 1307 did not throw any safemode warnings to me.

Please report which PHP version, CURL version and plattform you're using and provide steps to reproduce.

Testplugin - Enforce CURL usage

I'm getting the same warning (from lines 1302/1303) on the "Incoming Links," "WordPress Development Blog," and "Plugins" widgets on the dashboard since upgrading to WP2.9.

PHP 5.2.11 (LiteSpeed / Linux)
Safe mode: off
open_basedir has a value set
curl: libcurl/7.19.5 OpenSSL/0.9.8b zlib/1.2.3 libidn/0.6.5

This also appears to be affecting other people:  http://wordpress.org/support/topic/343008

See also #11505

 http://wordpress.org/support/topic/343008#post-1320553

Patch up on #11505.

http://core.trac.wordpress.org/attachment/ticket/11505/11505.diff

Hmm this issue is not directly related to the _MS values it seems.

It maybe worse than that!

Looking at the php source code there was a huge drop through case statement for curl_setopt which doesn't look like it will work at all.

An extract of the code from ( http://cvs.php.net/viewvc.cgi/php-src/ext/curl/interface.c?revision=1.175&view=markup) :

1548 	#if LIBCURL_VERSION_NUM >= 0x71304
1549 	case CURLOPT_REDIR_PROTOCOLS: 
1550    case CURLOPT_PROTOCOLS:
1551 	#endif
1552 	#if LIBCURL_VERSION_NUM > 0x070a07 /* CURLOPT_IPRESOLVE is available since curl 7.10.8 */
1553 	case CURLOPT_IPRESOLVE:
1554 	#endif
1555 	#if LIBCURL_VERSION_NUM >= 0x070f01
1556 	case CURLOPT_FTP_FILEMETHOD:
1557 	#endif
1558 		convert_to_long_ex(zvalue);
1559 		#if LIBCURL_VERSION_NUM >= 0x71304
1560 		if ((PG(open_basedir) && *PG(open_basedir)) && (Z_LVAL_PP(zvalue) & CURLPROTO_FILE)) {
1561 			php_error_docref(NULL TSRMLS_CC, E_WARNING, "CURLPROTO_FILE cannot be activated when open_basedir is set");
1562 			RETVAL_FALSE;
1563 			return 1;
1564 		} 

So basically for a boat load of curl options the value set is check by a bitmask against CURLPROTO_FILE and if open_basedir is set and the bitmask matches then setting of that option won't work.

PHP.net bug -  http://bugs.php.net/bug.php?id=49531

This issue is fixed for PHP 5.2.12 and PHP 5.3.2.

Doesn't look like they realised on the ticket how many options is could affect.

The constant that the bitmask test is done against is defined as follows:

#define CURLPROTO_FILE (1<<10)

Therefore when we try and set a 10 second timeout (the default for feeds) using millisecond resolution you end up with a test of (10000 & 1024) which evaluates to true.

Thereby triggering this error.

Maybe we should still try and use the _MS timeouts for sub one second timeouts which will be safe from this PHP bug.

(In [12472]) Don't use CURLOPT_CONNECTTIMEOUT_MS or CURLOPT_TIMEOUT_MS due to bugginess. fixes #11505 see #11499

(In [12473]) Don't use CURLOPT_CONNECTTIMEOUT_MS or CURLOPT_TIMEOUT_MS due to bugginess. fixes #11505 see #11499 for 2.9

This is fixed, unless someone reported errors on other setops?