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

Bug #13135 Problem with gzip-encoded sites
Submitted: 2008-02-16 23:42 UTC
From: jeff1985 Assigned: avb
Status: Closed Package: HTTP_Request
PHP Version: 5.2.1 OS: Windows Vista
Roadmaps: 1.4.3    
Subscription  


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 : 49 - 17 = ?

 
 [2008-02-16 23:42 UTC] jeff1985 (Evgeny Anisiforov)
Description: ------------ Sometimes i get an error with the HTTP_Client on sites, that use gzip-compression. The whole response-code is then null, and i cannot read the body. Test script: --------------- $client->get("http://www.losecrash.at/"); $client-> $result = $client->currentResponse(); $code = $result['code']; echo "Code = ".$code; //$code is NULL! Expected result: ---------------- $code is NULL so you can't use HTTP_Client for parsing this site Actual result: -------------- get an error in line 1470 of Request.php: // finally, call the gzinflate() function $unpacked = @gzinflate(substr($data, $headerLength, -8), $dataSize); OK, the gzinflate ist with an @, so you do not really get an error-message, but my debugger says that the problem is here. (out of memory error)

Comments

 [2008-02-17 14:08 UTC] jeff1985 (Evgeny Anisiforov)
here is an another url, that have the same behavior for me: http://www.hunde-familie.de/
 [2008-04-06 08:00 UTC] doconnor (Daniel O'Connor)
This is a HTTP_Request bug <?php require_once 'HTTP/Request.php'; $req = &new HTTP_Request("http://www.losecrash.at/"); $req->setMethod(HTTP_REQUEST_METHOD_GET); var_dump( "HI" ); var_dump( $req->sendRequest() ) ; var_dump( "ARRGH! Never reached ");
 [2008-04-23 12:01 UTC] doconnor (Daniel O'Connor)
This is occuring because of some bad / evil encoding. Line 1464: // unpacked data CRC and size at the end of encoded data $tmp = unpack('V2', substr($data, -8)); $dataCrc = $tmp[1]; $dataSize = $tmp[2]; When var_dumped, $dataSize is int(168624128) - so PHP Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 168624128 bytes) in G:\php\PEAR\HTTP\Request.php on line 1471 Happens. To solve: Maybe check for a $dataSize() > memory limit - currently used memory (unreliable), and bail? Alternatively, don't pass in $datasize to gzinflate; and it will fail more gracefully. From http://au.php.net/gzinflate "The function will return an error if the uncompressed data is more than 32768 times the length of the compressed input" - I think that's a safe assumption to make
 [2008-04-23 12:14 UTC] doconnor (Daniel O'Connor)
Added a patch to allow gzinflate to do its own sanity checks. This *should* be ok, as per previous comments. This patch also removes suppression of gzinflate errors; so problems like this are more readily seeable. This will now cause HTTP Request to raise a PEAR error (correctly) for this site
 [2008-07-21 16:41 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. Thanks for the analysis and the patch! My only gripe: please do not mix whitespace changes and actual bug fixes next time, it is extremely difficult to follow.