Requests::decompress falsely determines content is not compressed

[dustinrue]

https://github.com/rmccue/Requests/blob/master/library/Requests.php#L823

That function attempts to poke at the data to see if it is actually compressed or not. On a Ubuntu 16.04 system without php-curl installed the fsockopen transport is used instead of curl. When accessing content that is return using encoding deflate or gzip (what I tested) this routine falsely determines that the content is NOT compressed and returns the compressed data leading to failures in dependent software.

My environment consists of the following:

• WordPress 4.9.1
• ElasticPress 2.4
• Ubuntu 16.04 with PHP 7.0 (without php-curl installed)
• ElasticSearch 5.2.2
• WP-CLI 1.4

Once configured, using wp elasticpress stats will report that it was unable to contact the ElasticSearch server. This is due to the data coming back compressed (using deflate directly out of ElasticSearch) but being determined as not compressed despite actually being compressed. Not performing the check or installing php-curl on the system will resolve the issue.

[soulseekah]

Here's a sample I was able to reproduce: 301.gz from Elasticsearch 5.x

Elasticpress encodes the data using deflate (zlib-encoded) but with a 3 compression level (see elastic/elasticsearch@b6a3952#diff-fc41ed568e8f9fe5f2ffd4a2d410295aR53) resulting in a header with bytes 785e which are disregarded by the Requests::decompress method, which only looks for 789c, 1f8b magic bytes.

We have to support 7801, 785e, 789c and 78da as four valid deflated data markers. https://stackoverflow.com/a/43170354/482864

Patch incoming.