WP_PROXY_BYPASS_HOSTS has no effect inside curl transport, if http_proxy or https_proxy is set on the system

[fliespl]

OS: Debian Squeeze
PHP Version tested: 5.3.29

Will try to provide results from newer distros later today.

--

In case server hosting website has environmental settings for proxy, it's not possible to skip using it even for addresses that should be bypassed.

Let's take for example that printenv returns following:

http_proxy=http://proxy.com:8080 
https_proxy=http://proxy.com::8080

In this case, if we execute wp_remote_get (with domain that should be bypassed via WP_PROXY_BYPASS_HOSTS) it will still use system variable http_proxy in curl transport.

I think that wp_remote_get should explicitely set curl_setopt($handle, CURLOPT_PROXY, null);, if proxy is disabled inside wordpress or url SHOULD be bypassed.

[ocean90]

@fliespl Hello, thanks for your report.

Which WordPress version are you using? Is this issue new in trunk/the RC of 4.6 or can you also reproduce it with WordPress 4.5.3?

[fliespl]

This issue is valid for a long term, because it also happens on version 3.8.15.

[fliespl]

I have just confirmed that it is valid in all version of wordpress up to trunk. Tested on Ubuntu 16.04 (doesn't happen on windows).

Problem is because php curl will use system environment variable of http_proxy, https_proxy or other if set. That's why curl transport should set null to CURLOPT_PROXY.

http_proxy & other might be set in: global server config, current profile config, php-fpm setup, apache setup.

---

The easiest way to mimic http_proxy setting is to execute:

putenv('http_proxy=invalid.url:8888'); prior to executing wp_remote_get.

It behaves as if it was set in server setup.

I have created a sample pages to show the issue:
Authorization: 37614 / 37614

​http://37614.wordpress.codeone.pl/ -> env variable is not set (works correctly)
​http://37614.wordpress.codeone.pl/?proxy=1 -> http_proxy env variable set to a proxy which is offline - causes proxy error even though

And here's the sample code used (there's not definition of WP_PROXY anywhere in the code - yet it uses system settings):

<pre>
<?php

putenv('http_proxy=');

if(isset($_GET['proxy']) && $_GET['proxy'] == '1') {
   putenv('http_proxy=offline.proxy.url:18888');
}

print 'ENV variable - http_proxy='.getenv('http_proxy')."\n";

define('WP_PROXY_BYPASS_HOSTS', '*.wordpress.org, wordpress.org');

$response = wp_remote_get('http://wordpress.org');
if(is_wp_error($response)) {
    var_dump($response);
} else {
    var_dump($response['headers']);
}

?>
</pre>
<?php die; ?>

[dd32]

Thanks @fliespl for your report. I've confirmed that both WordPress 4.5 (WP_HTTP) and 4.6/trunk (using Requests) have this issue.

The issue as I see it, is that cURL is using the http_proxy/https_proxy environmental variable in the first place, which it shouldn't be in our environment.
Changing this however will potentially mean that some configurations which have expected these environmental variables to be respected will break. I feel like I'm okay with that.

@rmccue What's your thoughts here? This isn't a regression in the switch to Requests, but will need to be filed as an upstream bug for Requests regardless. An additional curl_setopt($this->handle, CURLOPT_PROXY, null); in the Requests_Transport_cURL::__constructor() does work around this, and should allow properly defined proxies to work. Or is Requests designed to respect these environment variables?

[rmccue]

The defaulting to HTTP_PROXY from the environment is unintended behaviour, so we should definitely fix that. Requests intentionally isn't meant to respect these vars, see also ​this issue.