[wp-trac] [WordPress Trac] #34398: Default User-Agent string causes status 500 response for wp_remote_get()

[WordPress Trac]

#34398: Default User-Agent string causes status 500 response for wp_remote_get()
------------------------------+-----------------------------
 Reporter:  luke.a.danielson  |      Owner:
     Type:  defect (bug)      |     Status:  new
 Priority:  normal            |  Milestone:  Awaiting Review
Component:  General           |    Version:  4.3.1
 Severity:  normal            |   Keywords:
  Focuses:                    |
------------------------------+-----------------------------
 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
 <?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!

--
Ticket URL: <https://core.trac.wordpress.org/ticket/34398>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform