Found this in my dblog:

Warning: gzinflate(): data error in httprl_decode_data() (line 1974 of \sites\all\modules\contrib\httprl\httprl.module).
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

duckydan’s picture

I have the same issue. Any ideas? I am on Acquia with PHP 5.5. On my dev box (Ubuntu 12.04) this works fine (no errors).

serg2’s picture

I am getting this warning too. I tried both 7.x-1.14 and 7.x-1.14+18-dev .
Warning: gzinflate(): data error in httprl_decode_data() (line 2374 of /home/example/public_html/sites/all/modules/httprl/httprl.module).

The code it refers to is :

// Decompress if compressed.
  elseif (isset($result->headers['content-encoding'])) {
    if ($result->headers['content-encoding'] == 'gzip') {
      $result->data = gzinflate(substr($result->data, 10));
    }
    elseif ($result->headers['content-encoding'] == 'deflate') {
      $result->data = gzinflate($result->data);
    }
  }

The warning message is created x 2 when drupal's internal cron is run.

There are various comments at http://php.net/manual/en/function.gzinflate.php about this function and the need to strip part of the result.
My PHP is too weak to actually understand it though...

I am using PHP 5.5. I have other sites using the same server which do not produce the error.

btopro’s picture

seeing this too, not sure that there are other issues at play but can confirm this is happening

hass’s picture

Maybe caused by the chunking"

gabor_h’s picture

I think that the solution is simple: just check whether $result->data is empty or not. If it is empty, then do not call gzinflate, because it will naturally fail.
Why is there no data? Could be for many reasons, but even drupal.org responds with a 'gzip' encoding in the header and sends no data, when a HEAD is sent to the server.

serg2’s picture

Just wanted to add that this causes PHP 5.6 to timeout forever while waiting for headers.

Disabling the module, deleting and reinstaling worked on one site but hasn't on another.

gabor_h’s picture

In addition to check whether $result->data is empty or not, it is necessary to check whether the data has been fully downloaded. If half of the data is downloaded and then the connection is stopped because of a timeout, etc., then attempting to uncompress the data should be avoided.

  • mikeytown2 committed 4898f6a on 6.x-1.x
    Issue #2281873 by mikeytown2: gzinflate(): data error in...
  • mikeytown2 committed 78bc6ad on 7.x-1.x
    Issue #2281873 by mikeytown2: gzinflate(): data error in...
mikeytown2’s picture

Status: Active » Fixed
FileSize
1.38 KB

Patch should fix the issue by not trying to decompress it if that fails.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.