WordPress.org

Make WordPress Core

Opened 4 years ago

Closed 4 years ago

#11499 closed defect (bug) (fixed)

curl_setopt() In Feed Options?

Reported by: markmcwilliams Owned by:
Milestone: 2.9.1 Priority: normal
Severity: normal Version: 2.9
Component: Feeds Keywords: reporter-feedback
Focuses: Cc:

Description

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! :)

Attachments (1)

11499-curlforce.php (2.7 KB) - added by hakre 4 years ago.
Testplugin - Enforce CURL usage

Download all attachments as: .zip

Change History (13)

comment:1 markmcwilliams4 years ago

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!

comment:3 hakre4 years ago

  • Keywords reporter-feedback added

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.

hakre4 years ago

Testplugin - Enforce CURL usage

comment:4 laceous4 years ago

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

comment:5 ryan4 years ago

See also #11505

comment:8 westi4 years ago

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.

comment:9 westi4 years ago

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.

comment:10 automattor4 years ago

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

comment:11 ryan4 years ago

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

comment:12 miqrogroove4 years ago

  • Resolution set to fixed
  • Status changed from new to closed

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

Note: See TracTickets for help on using tickets.