How do I troubleshoot responses with WP HTTP API?

2 Views

I make a GET call to API, call is supposed to return no data:

  • browser (and sniffer) give me 200-OK response with null text as body;
  • wp_remote_get() gives me 200-OK response with string of binary garbage as body.

Other API requests (that are supposed to and do return non-empty data) work perfectly fine.

Read More

Where to start poking HTTP API to figure out why it ends up with garbage?

Here is dump of full response data: 

array
  'headers' => 
    array
      'date' => string 'Tue, 22 Feb 2011 16:51:03 GMT' (length=29)
      'server' => string 'Apache/2.2.3 (Red Hat)' (length=22)
      'x-powered-by' => string 'PHP/5.2.16' (length=10)
      'content-encoding' => string 'deflate' (length=7)
      'vary' => string 'Accept-Encoding' (length=15)
      'content-length' => string '17' (length=2)
      'connection' => string 'close' (length=5)
      'content-type' => string 'application/json; charset=utf-8' (length=31)
  'body' => string 'x��+��������_' (length=17)
  'response' => 
    array
      'code' => int 200
      'message' => string 'OK' (length=2)
  'cookies' => 
    array
      empty
Post Views: 2

Related posts

Leave a Reply

2 comments

  1. We tracked it down to content-encoding’ => string ‘deflate’ (length=7) being at fault.

    WP_HTTP is adding in a deflate header for no reason and un gzip compressing the results.
    It only happens when the body of the response is under a certain string length.

    Very annoying when all you want isa 1 or a 0.

    A query to WP_Hackers hasn’t resulted in a fix.
    Might have to chase it up further…..

  2. [update] Support for compression method, used by MailChimp, had been implemented in WP core in version 3.3.

    This issue came up again and this time I was able to reproduce and troubleshoot it.

    WordPress declares that is expects deflated data with high priority, but for some reason it cannot inflate some responses – they are not recognized by either gzinflate() or WP_Http_Encoding::compatible_gzinflate().

    In my specific case there seems to have been two extra bytes at start that caused this. Figured out from comments to gzinflate() docs that are also source of WP_Http_Encoding::compatible_gzinflate(), but apparently that function is not perfect.

    Crude quick fix that checks if response holds JSON data and tries to correct compression issue otherwise:

    add_filter('http_response', 'mailchimp_http_response_inflate_fix', 10, 3);

function mailchimp_http_response_inflate_fix($response, $args, $url) {

    if( false === strpos($url, 'sts.mailchimp.com') )
        return $response;

    $json = json_decode($response['body']);

    if( is_null($json) ) {

        $inflate = @gzinflate(substr($response['body'], 2));

        if( false !== $inflate )
            $response['body'] = $inflate;
    }

    return $response;
}