It would be useful to know if the user has the curl php extension installed. If the extension is installed we use curl to connect, otherwise we use php's fopen wrappers. Both code paths should have support for proxies (And should automatically support $wgHTTPProxy) however they are separate code paths, so it would be useful to know which one the user is encountering.

PHP version numbers, and versions of curl php extension installed might also be helpful.

I've replied to the list to ask original issue submitter to comment with the the relevant information.

roolze wrote:

PHP
root@wsrz1002:~# php -v
PHP 5.3.3-7+squeeze14 with Suhosin-Patch (cli) (built: Aug 6 2012 14:18:06)

CURL installed
apt-get install php5-curl
Hole:2 http://ftp.tu-graz.ac.at/mirror/debian/ squeeze/main libcurl3 amd64 7.21.0-2.1+squeeze2 [285 kB]
php Hole:3 http://ftp.tu-graz.ac.at/mirror/debian/ squeeze/main php5-curl amd64 5.3.3-7+squeeze14 [27,0 kB]
/etc/init.d/apache2 restart

still same effect ?:|

roolze wrote:

I have to add that i am using a windows box (windows 2008 r2 with iis with arr for url rewriting) in front of the linux box running mediawiki.

Just mentioning it to avoid that we are looking at the wrong place ... (not sure if this can be a reason)

rabe wrote:

Same issue here.

OS: FreeBSD 7.4 but with recent (2012-08) ports build
PHP5: php5-curl-5.4.5
Proxy: squid

MediaWiki is doing some kind of api-requests via proxy which get answered by 200:
[…] TCP_MISS/200 1277 GET http://commons.wikimedia.org/w/api.php? - DIRECT/91.198.174.224 application/json

The relevant environment is set (as shown by phpinfo()):

http_proxy our-proxy-fqdn:3128
https_proxy our-proxy-fqdn:3128
ftp_proxy our-proxy-fqdn:3128
ALL_PROXY our-proxy-fqdn:3128
RSYNC_PROXY our-proxy-fqdn:3128

There's no variable name containing "proxy" in our LocalSettings.*, so we use defaults here.

I guess MediaWiki is actually doing requests to http://commons.wikimedia.org/w/api.php but may have problems parsing the result.

rabe wrote:

some correction to my last comment (2012-12-01 17:18:37 UTC): there's *no* access to our proxy, the access i saw was from another MediaWiki project.

Correct is: There was no access to our proxy.

According to the curl(1) manpage it will use following environment variables to

http_proxy [protocol://]<host>[:port]
HTTPS_PROXY [protocol://]<host>[:port]
[url-protocol]_PROXY [protocol://]<host>[:port]
ALL_PROXY [protocol://]<host>[:port]

Grepping our proxy from the output of "phpinfo()" brings:

ALL_PROXY            our-proxy-fqdn:3128
ftp_proxy            our-proxy-fqdn:3128
http_proxy           our-proxy-fqdn:3128
https_proxy          our-proxy-fqdn:3128
RSYNC_PROXY          our-proxy-fqdn:3128
_SERVER["ALL_PROXY"] our-proxy-fqdn:3128
_SERVER["ftp_proxy"] our-proxy-fqdn:3128
_SERVER["http_proxy"] our-proxy-fqdn:3128
_SERVER["https_proxy"] our-proxy-fqdn:3128
_SERVER["RSYNC_PROXY"] our-proxy-fqdn:3128

So libcurl / curl should be able to find one matching environment variable here. This configuration worked fine until yesterday, I upgraded from 1.19.0 to 1.20.1 today.

We use following setting since 10/2011 or longer:

$wgForeignFileRepos[] = array(

'class'                   => 'ForeignAPIRepo',
'name'                    => 'shared',
'apibase'                 => 'http://commons.wikimedia.org/w/api.php',
'fetchDescription'        => true, // Optional
'descriptionCacheExpiry'  => 43200, // 12 hours, optional (values are seconds)
'apiThumbCacheExpiry'     => 43200, // 12 hours, optional, but required for local thumb caching

);

This worked very well, I didn't change this conf sincs 2011-10-06.

So something is new with 1.20.x or I missed some change?

rabe wrote:

Just to be sure, I added
$wgHTTPProxy="our-proxy-fqdn:3128";
to our LocalSettings.php without any success. So neither environment variables not setting this $wgHTTPProxy seems to work here.

rabe wrote:

I just granted unlimited outgoing tcp requests from our wiki-server and sucessfully opened a file descrition file from commons.wikimedia.org, still configured $wgForeignFileRepos[] ...

The symptom is bound to this firewall rule. Another parallel mediawiki 1.19.1 on this hosts works perfect with commons via our proxy so I strongly belive on a proxy configuration issue since 1.20.x.

I diff'ed includes/HttpFunctions.php of both projects (1.19.1 --> 1.20.1) and found some new code around !$this->noProxy

Since we have protected $noProxy = false; this shouldn't be a problem here ... I didn't find any $this->noProxy=something; so i think it is always false here.

rabe wrote:

Is there any resolution on this issue? My current workaround is to enable outgoing tcp requests bypassing the proxy server.

removed negation when evaluating noProxy

!this->noProxy is true iff the proxy sould be set. The old version of the method returns without setting the proxy in this case, while the new one does set the proxy.

Attached:

Church of emacs, could you put your patch in gerrit please?

This was fixed in commit 5c8245acdffd8ff5f52638b85520c54b0aed6b9b.

MW 1.21 should have the fix. Do you want it backported to 1.20?

roolze wrote:

MW 1.21 is fine. Cheers, Roland