Default User-Agent string causes status 500 response for wp_remote_get()

[luke.a.danielson]

I am getting an odd server php curl error in both my local and production servers (Ubuntu 14.04.2 LTS, PHP 5.5.9-1ubuntu4.11, Apache 2.4.7).

Basically, a curl request to a remote API returns a status code 500 response, ONLY in wp_remote_get(), where it returns status 200 in both curl_exec() and a browser-based request.

My debug code:

<?php
$url = 'https://yoast.com?edd_action=activate_license&license=my-license-key-here&item_name=WooCommerce+Yoast+SEO&url=https://google.com';

// this return status 200:
$ch = curl_init();
curl_setopt($ch, CURLOPT_URL, $url);
curl_setopt($ch, CURLOPT_FOLLOWLOCATION, true);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
$result = curl_exec($ch);
curl_close($ch);
echo '<pre>' . print_r($result, true) . '</pre>';

// this return status 500:
$testResp = wp_remote_get($url);
echo '<pre>' . print_r($testResp, true) . '</pre>';

I could not figure out why it responded with a status 500 for wp_remote_get().

But when hooking into the http_headers_useragent filter, setting it to a blank string, a differnet, more normalized user-agent string, the requests were successful.

I believe the issue is the default User-Agent string Wordpress sets in wp-includes/class-http.php, set when creating an http request for wp_remote_get()

I'm not sure if the semicolon is the true culprit, but if I remove it and set the user-agent string to just "Wordpress/4.3.1", the request is successful as well.

Could be an issue with my server setup, but it is a pretty common LAMP-based stack with updated versions of CURL/Apache/PHP, etc etc.

Not a pressing bug, but something I thought should be made aware of. Thanks for the great work everyone at WP does!

[justingreerbbi]

I can not seem to replicate with given code:

WP 4.3.1
PHP 5.6.10

[dd32]

This isn't a bug in WordPress, and we won't be removing the ; character from the user-agent.

It's likely either an application bug in the software you're connecting to, or potentially a application firewall that is blocking the request because the request includes a URL in the user agent field (thinking it's a Remote File Inclusion vulnerability or something).

[luke.a.danielson]

OK yeah no problem. Thanks for looking into it!