WordPress.org

Make WordPress Core

Opened 3 years ago

Last modified 6 weeks ago

#37614 new defect (bug)

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

Reported by: fliespl Owned by:
Milestone: Priority: normal
Severity: normal Version:
Component: HTTP API Keywords:
Focuses: Cc:

Description

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.

Change History (6)

#1 @ocean90
3 years ago

  • Keywords reporter-feedback added

@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?

#2 @fliespl
3 years ago

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

#3 @ocean90
3 years ago

  • Keywords reporter-feedback removed
  • Version trunk deleted

#4 @fliespl
3 years ago

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; ?>

#5 @dd32
3 years ago

  • Milestone changed from Awaiting Review to Future Release

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?

#6 @rmccue
3 years ago

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.

Note: See TracTickets for help on using tickets.