WordPress Development Stack Exchange is a question and answer site for WordPress developers and administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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.

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

Here is dump of full response data:

  'headers' => 
      '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' => 
      'code' => int 200
      'message' => string 'OK' (length=2)
  'cookies' => 
share|improve this question
Doesn't the wp http api returns a WP_Error on failure? – Bainternet Feb 22 '11 at 16:44
It does. But in this case it's not failure - it's valid (I think) response, whose body gets garbled by WP for some reason. – Rarst Feb 22 '11 at 16:50
It might help if we knew what you were GETing so we could reproduce ... – EAMann Feb 22 '11 at 18:02
@EAMann private API key so can't post it. – Rarst Feb 22 '11 at 18:36
In that case, I'd try just walking through the wp_remote_get() routine and checking what data it's got. I don't see anywhere in the code where it generates extra cruft like you're seeing ... and without the ability to test it myself, that's the best I can give you. – EAMann Feb 22 '11 at 19:24

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.....

share|improve this answer
Thank you for confirmation. Any idea on how to reliably replicate it? – Rarst May 7 '11 at 22:01
up vote 2 down vote accepted

[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;
share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.