Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Found this in my dblog:
Warning: gzinflate(): data error in httprl_decode_data() (line 1974 of \sites\all\modules\contrib\httprl\httprl.module).
Comment | File | Size | Author |
---|---|---|---|
#9 | httprl-2281873-8-skip-decode-on-inflate-error.patch | 1.38 KB | mikeytown2 |
Comments
Comment #1
duckydan CreditAttribution: duckydan commentedI 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).
Comment #2
serg2 CreditAttribution: serg2 commentedI 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 :
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.
Comment #3
btopro CreditAttribution: btopro commentedseeing this too, not sure that there are other issues at play but can confirm this is happening
Comment #4
hass CreditAttribution: hass commentedMaybe caused by the chunking"
Comment #5
gabor_h CreditAttribution: gabor_h commentedI 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.
Comment #6
serg2 CreditAttribution: serg2 commentedJust 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.
Comment #7
gabor_h CreditAttribution: gabor_h commentedIn 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.
Comment #9
mikeytown2 CreditAttribution: mikeytown2 commentedPatch should fix the issue by not trying to decompress it if that fails.