Problem uncompressing certain API responses in WordPress

[Rarst]

Hello,

I am developer working on MailChimp STS plugin for WordPress http://wordpress.org/extend/plugins/mailchimp-sts/

I am encountering issue that under certain (seemingly very rare) circumstances STS API response contains deflated data that cannot be re-inflated either by native PHP gzinflate() or WP's fallback compatibility function that tries to correct possible issues (source http://core.trac.wordpress.org/browser/branches/3.2/wp-includes/class-http.php#L1624 )

This seems to only occur for responses that contain very little data (for example single email address in verified list).

From trial and error I determined that data can be made compatible to native gzinflate() by stripping two bytes from the start. I am not sure this is generic solution or specific to the only case in which I could repeatedly reproduce this.

Here is my post on WordPress stack exchange with older question about the issue and newer details http://wordpress.stackexchange.com/questions/10088/how-do-i-troubleshoot-responses-with-wp-http-api/

What encoding STS API is using for deflate? Does this seem like a bug in data itself or maybe some case of headers mismatch that causes response to be interpreted wrongly?

[jesse]

This doesn't really sound like it's an issue on our side, though if
you are requesting encoding, it should be probably be gzip.

For anything more, I need the details of a reproduceable test case.


jesse

On Jul 31, 6:20 pm, Rarst <rar...@gmail.com> wrote:
> Hello,
>

> I am developer working on MailChimp STS plugin for WordPresshttp://wordpress.org/extend/plugins/mailchimp-sts/

>
> I am encountering issue that under certain (seemingly very rare)
> circumstances STS API response contains deflated data that cannot be
> re-inflated either by native PHP gzinflate() or WP's fallback compatibility

> function that tries to correct possible issues (sourcehttp://core.trac.wordpress.org/browser/branches/3.2/wp-includes/class...

> )
>
> This seems to only occur for responses that contain very little data (for
> example single email address in verified list).
>
> From trial and error I determined that data can be made compatible to native
> gzinflate() by stripping two bytes from the start. I am not sure this is
> generic solution or specific to the only case in which I could repeatedly
> reproduce this.
>
> Here is my post on WordPress stack exchange with older question about the

> issue and newer detailshttp://wordpress.stackexchange.com/questions/10088/how-do-i-troublesh...

[Rarst]

So your recommendation is that deflate should not be listed as accepted encoding when making request? Unfortunately this is not something easy to control in WordPress.

My current test case would be something like this (WP 3.2.1):

$data = wp_remote_retrieve_body(wp_remote_get('STS API request that returns very little data, like empty stats for the period'));

The data returned by API in such case is binary and cannot be decoded by either native PHP function (gzinflate() ) or WordPress helper function. Same code for responses that have considerable amount of data seem to work fine.

Feel free to contact me directly via con...@rarst.net if you need more specific examples with our test API key or anything else that I can do to troubleshoot this.