Package home | Report new bug | New search | Development Roadmap Status: Open | Feedback | All | Closed Since Version 1.4.4

Bug #14370 Error on empty gzipped documents
Submitted: 2008-07-19 09:15 UTC
From: njohansson Assigned: avb
Status: Closed Package: HTTP_Request (version 1.4.2)
PHP Version: 4.3.9 OS: RHEL 4.6
Roadmaps: 1.4.3    
Subscription  
Comments Add Comment Add patch


Anyone can comment on a bug. Have a simpler test case? Does it work for you on a different platform? Let us know! Just going to say 'Me too!'? Don't clutter the database with that please !
Your email address:
MUST BE VALID
Solve the problem : 37 + 26 = ?

 
 [2008-07-19 09:15 UTC] njohansson (Nils-Johan Johansson)
Description: ------------ During internal development of an API we detected that doing a HTTP GET request to an Apache webserver returning gzipped content HTTP_Request will return an error when the response body is empty. In our particular case we do not need response bodies as it is an API and we rely solely on the status code. Test script: --------------- The problem is in Request.php on line 1470: $unpacked = @gzinflate(substr($data, $headerLength, -8), $dataSize); If the response body is empty $unpacked will not return an empty result, but a false This will throw the error directly below: if (false === $unpacked) { return PEAR::raiseError('_decodeGzip(): gzinflate() call failed', HTTP_REQUEST_ERROR_GZIP_READ); } Expected result: ---------------- To fix this I temporarily added below line 1470: if ($unpacked === false && $dataSize == 0) { $unpacked = ""; } This will return the response body as an empty string and will not throw an error

Comments

 [2008-07-19 17:19 UTC] avb (Alexey Borzov)
The documentation for gzinflate() states that it only returns false in case of an error: http://ru2.php.net/manual/en/function.gzinflate.php If you think that false is returned incorrectly here please open a bug report for PHP's gzinflate() instead.
 [2008-07-20 11:23 UTC] njohansson (Nils-Johan Johansson)
I do not believe the problem is that gzinflate() returns false erroneously (for example when getting an empty string) This code: <?php $data = ""; $compressed = gzdeflate($data); $uncompressed = gzinflate($compressed); var_dump($compressed); var_dump($uncompressed); var_dump(urlencode($compressed)); var_dump(urlencode($uncompressed)); Returns: string(2) "" string(0) "" string(6) "%03%00" string(0) "" on the same system. So we are not dealing with an empty value at least. I tried fetching an empty gzipped page served from Apache again (basically with PHP code <?php die(); ?> only) and dumped the values above the operation like this: var_dump($data); var_dump($headerLength); var_dump($dataSize); var_dump(urlencode($data)); This was what was returned: string(20) "" int(10) int(0) string(60) "%1F%8B%08%00%00%00%00%00%00%03%03%00%00%00%00%00%00%00%00%00" Clearly the dataSize is 0 bytes, but anyhow the below operation runs: $unpacked = @gzinflate(substr($data, $headerLength, -8), $dataSize); It will run on urlencoded hex %03%00 only which normally works, but the dataSize (0) is what is causing the error: string(0) "" PHP Warning: gzinflate(): length must be greater zero in - on line 4 bool(false)
 [2008-07-21 14:08 UTC] avb (Alexey Borzov)
Ah, OK, thanks for clarification! Looks like we should get rid of $dataSize since it is causing other problems as well, see bug #13135
 [2008-07-21 16:12 UTC] njohansson (Nils-Johan Johansson)
Yes, Daniel O'Connor's suggested patch would definitely solve this bug as well and I agree it is perfectly safe to rely on gzinflate() without passing the data size to it.
 [2008-07-21 16:42 UTC] avb (Alexey Borzov)
This bug has been fixed in CVS. If this was a documentation problem, the fix will appear on pear.php.net by the end of next Sunday (CET). If this was a problem with the pear.php.net website, the change should be live shortly. Otherwise, the fix will appear in the package's next release. Thank you for the report and for helping us make PEAR better. -- Fixed by applying the changes from #13135