Last modified: 2014-02-12 23:32:48 UTC
From mediawiki-l at http://permalink.gmane.org/gmane.org.wikimedia.mediawiki/40553 Situation: InstantCommons does not work for me (I sitting behind a proxy). Configuration: - mediawiki 1.20 on debian squeeze Proxyconfig in Localsettings.php # PROXY Setting $wgHTTPProxy = "http://*<myproxy>*:8080"; # proxy bypass list $wgConf->localVHosts[] = '*<www.secret.com>*'; In my firewall-log I see that the debian-box tries to connect directly (which does not work) - Server: 91.198.174.224 port 80 http - wikimedia-lb.esams.wikimedia.org
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.
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 ?:|
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)
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.
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?
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.
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.
Is there any resolution on this issue? My current workaround is to enable outgoing tcp requests bypassing the proxy server.
Created attachment 12151 [details] 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.
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?
MW 1.21 is fine. Cheers, Roland
