Support » Developing with WordPress » wp_remote_get Response could not be parsed

  • I’m trying to troubleshoot a problem someone is having with my plugin.

    I’m using wp_remote_get to basically interact with a remote server. It all works fine from my own WP install and even works on installs on 2 different laptops.

    The error being reported is

    “Response could not be parsed”

    which digging into the WordPress code seems to suggest that the headers are missing.

    The odd thing is that the wp_remote_get call is to this url:

    https://canalplan.org.uk/cgi-bin/api.cgi?mode=version

    And that server actually sees a call from the user’s wordpress install to the url – but its dying at the other end.

    Is there any way of getting any better diagnostic information from the wp_remote_get error response?

Viewing 8 replies - 1 through 8 (of 8 total)
  • If it works for you on your own site, then chances are is a PHP version or extension issue.

    Does the user have cURL installed on their server on the PHP extensions? It’s one of those.

    As they seem to be able to make calls to the remote server I assume that curl is installed.

    I did point out that they were on an obsolete version of php but as I know my code worked under that version I don’t think it’s that.

    Moderator bcworkz

    (@bcworkz)

    The “Response could not be parsed” error is caused specifically when WP cannot extract the expected initial HTTP/1.1 200 OK header. Your resource clearly sends it, so it is either stripped out prior to your user’s installation (by load balancer, reverse proxy, firewall, etc.), or their installation is corrupted or conflicted in a way that causes the header to disappear.

    Have your user install and activate the health-check plugin. Then invoke troubleshooting mode. Have them reinstate your plugin through the admin bar troubleshooting item. Hopefully the error does not occur in this state, indicating there was a conflict. The source of conflict can be isolated by reactivating all their usual modules in troubleshooting mode, one at a time, testing after each. When the error returns, the last module activated is the cause.

    FWIW, WP falls back to other methods if cURL is not available.

    • This reply was modified 10 months, 1 week ago by bcworkz.

    OK I’ve asked them to do that.

    I do know that the remote file functionality using standard PHP functions has been disabled as they are on shared hosting.

    selected bits from their report:

    WordPress Version 5.0.3
    Plugin Versions
    Your site has 3 plugins waiting to be updated.
    Your site has 3 inactive plugins, it is recommended to remove any unused plugins to enhance your site security.

    PHP Version 5.6.40 – For best performance we recommend using PHP 7.2 or higher.
    Database Server version 10.1.37-MariaDB

    HTTPS status You are accessing this website using HTTPS, but your WordPress Address is not set up to use HTTPS by default.
    Secure communication Your WordPress install can communicate securely with other services.

    HTTP Requests HTTP requests should be working as expected.
    REST API availability The REST API is available.
    Communication with WordPress.org Unable to reach WordPress.org at 198.143.164.252: Response could not be parsed
    Background updates
    No version control systems were detected.
    Your installation of WordPress doesn’t require FTP credentials to perform updates.
    All of your WordPress files are writable.
    Loopback request The loopback request to your site completed successfully.

    So there is something wrong with their server.

    Moderator bcworkz

    (@bcworkz)

    Yeah, something their host needs to resolve. To avoid a common knee jerk response like “It’s not us, it’s a WP problem”, it would be telling to see the actual headers, if any, of a typical response. They could put the following into a new PHP file and request the file, then report the result.

    <?php
    if ( ! in_array('curl', get_loaded_extensions())) die('cURL not available');
    
    $url = 'https://canalplan.org.uk/cgi-bin/api.cgi?mode=version';
    $ch = curl_init();
      curl_setopt($ch, CURLOPT_URL, $url);
      curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
      curl_setopt($ch, CURLOPT_HEADER, 1);
    
      $response = curl_exec($ch);
      
      $header_size = curl_getinfo($ch, CURLINFO_HEADER_SIZE);
      $headers = substr($response, 0, $header_size);
    curl_close($ch);
    
    header("Content-Type:text/plain; charset=UTF-8");
    echo "Header size: $header_size<br>\n";
    echo $headers;

    I’ll put that into the diagnostics code for my plugin.

    Thanks for the code

    I wonder if it’s worth putting something like that into the health check plugin?

    • This reply was modified 10 months, 1 week ago by Steve.
    Moderator bcworkz

    (@bcworkz)

    You probably noticed by now, but the <br> tag in the second to last line should be removed since the content type is not HTML.

    It’s not my call, but I would say no to putting it in health-check at this time. Health-check did its job by flagging the error. Actually seeing the headers returned can be determined any number of ways. This is probably a very rare server or network device misconfiguration. If it turns out to be a more common issue, then I could see including something. I’m leery of contributing to feature bloat for a one-off situation.

    Regardless of what I think, you can add a feature request or even contribute to the project on github.

Viewing 8 replies - 1 through 8 (of 8 total)
  • The topic ‘wp_remote_get Response could not be parsed’ is closed to new replies.