workaround for gzdecode()
Originally reported on Google Code with ID 197
Some PHP versions does not have gzdecode() function as you can see in http://php.net/manual/es/function.gzdecode.php.
I use this small fix that works fine:
if(!function_exists('gzdecode')) {
function gzdecode($data) {
return gzinflate(substr($data,10,-8));
}
}
I've added to my 1.9.4 and works.
Reported by is2cool4me
on 2013-03-20 18:36:31
Comments (26)
-
-
Reported by
crazy4chrissi
on 2013-03-20 19:27:10 - Labels added: Target-1.9.4.1 -
I consider this a defect as we want to support any php >= 5.2 and version 1.9.4 does not seem to do this.
Reported by
crazy4chrissi
on 2013-03-20 19:28:19 - Labels added: Type-Defect - Labels removed: Type-Enhancement -
This is a very, very large WTF. All gz* functions seem to be available since php 4.0.1/4 and php 5, except gzdecode!? And there's a bug filed in 2003: https://bugs.php.net/bug.php?id=22123 I can't find any definitive information, but gzencode seems available around 5.3.9 and 5.4.6. Unfortunately both are quite distant from 5.2.x :| We can solve this by eiher using gzdeflate/gzinflate and add code to generate header and crc, or we add our implementation of gzdecode. The one above "works" and is minimal, and a nicer one can be found around the internet, for example in this file http://yapeal.googlecode.com/svn-history/r1093/branches/httprequest/ext/eac_httprequest/eac_httprequest.curl.php I am tempted to go for the solution suggested by is2cool4me, mainly because we are compressing data with the gzencode that comes with php which *should* give a consistent result.
Reported by
dreadnaut
on 2013-03-20 21:00:50 -
> This is a very, very large WTF. Agreed. I can live with anything that works. But there is no point in adding a 20 LOC gzdecode function to save 100 Bytes or Resource data. Then it would probably be better to save the data uncompressed and compress it on-the-fly if needed. And we only use gzdecode as a fall-back for stupid/old browsers/software, so no need for a perfect and nice solution. It should work. But please test if it definitely works. Because normally (with a browser accepting gzip data), phpLiteAdmin would not call gzdecode, so if the implementation is not correct, this would not be spotted. So we have to force PLA to use gzdecode either by changing the if or sending a request with an appropriate accept-header.
Reported by
crazy4chrissi
on 2013-03-20 21:33:41 -
Well, it's more like 5-6KB that we are saving with gzipping. I'll test the code above with a few browsers and syntetic requests tomorrow, and if it works I'll commit it right away.
Reported by
dreadnaut
on 2013-03-20 22:39:04 -
Account Deleted > What PHP version are you using? Tested in 5.2.11 and 5.3.3, none with gzdecode(). I've used previously this workaround in a PHP to PHP and works consistent, but of course a whole implementation will be better "compatibility" solution. The nicer example version of @dreadnaut is also used in many other solutions. I've see this code arround internet looking for a solution.
Reported by
is2cool4me
on 2013-03-21 08:10:50 -
@is2cool4me: out of curiosity, which browser are you using? Are you using a proxy?
Reported by
dreadnaut
on 2013-03-21 12:12:40 -
Attached is a patch to revert compression.
Reported by
dreadnaut
on 2013-03-21 13:04:26<hr> * Attachment: nozlib.diff
-
Reported by
dreadnaut
on 2013-03-21 13:05:26 - Status changed:Started
-
Thanks, dreadnaut for solving this fast. I am thinking about whether it makes sense to compress the data (on-the-fly) iff zlib is installed. This wouldn't make phpliteadmin.php smaller, but might save some kb of download size. But I'm not sure if that's worth it, as on-the-fly compression needs cpu and thus time.
Reported by
crazy4chrissi
on 2013-03-21 13:09:44 -
IMO not worth it, since resources should be cached by the browser, but I'll take a look at it post-#190.
Reported by
dreadnaut
on 2013-03-21 13:11:45 -
Account Deleted > @is2cool4me: out of curiosity, which browser are you using? Are you using a proxy? Firefox 19.0.2 without proxy.
Reported by
is2cool4me
on 2013-03-21 15:59:19 -
That's strange then, since Firefox normally sends the header 'Accept-encoding: gzip, deflate'. And if the header is there, PLA will *not* call gzdecode but send the compressed data directly to the browser. If you have the chance, can you investigate more and check whether the correct headers are being transmitted? Something like var_dump($_SERVER); will give you the needed details.
Reported by
dreadnaut
on 2013-03-21 16:03:20 -
I guess some anti virus software or a stupid provider is then the cause. Some antivir SW that can cause the accept-encoding header to vanish: CA Internet Security Suite, Norton Internet Security, McAfee, Zone Alarm. Source: http://stackoverflow.com/questions/2645883/accept-encoding-headers-being-sent-by-browser-but-not-received-by-server
Reported by
crazy4chrissi
on 2013-03-21 16:28:32 -
Account Deleted > If you have the chance, can you investigate more and check whether the correct headers are being transmitted? Something like var_dump($_SERVER); will give you the needed details. No 'Accept-encoding' in headers: array(27) { ["HOME"]=> string(1) "/" ["TERM"]=> string(5) "vt102" ["PATH"]=> string(29) "/sbin:/usr/sbin:/bin:/usr/bin" ["SHELL"]=> string(7) "/bin/sh" ["USER"]=> string(4) "root" ["PATH_INFO"]=> string(0) "" ["REQUEST_METHOD"]=> string(3) "GET" ["REQUEST_URI"]=> string(16) "/php/phpinfo.php" ["SCRIPT_FILENAME"]=> string(20) "/www/php/phpinfo.php" ["SCRIPT_NAME"]=> string(16) "/php/phpinfo.php" ["QUERY_STRING"]=> string(0) "" ["SERVER_SOFTWARE"]=> string(20) "busybox httpd/1.19.4" ["SERVER_PROTOCOL"]=> string(8) "HTTP/1.0" ["GATEWAY_INTERFACE"]=> string(7) "CGI/1.1" ["REMOTE_ADDR"]=> string(12) "192.168.0.16" ["REMOTE_PORT"]=> string(5) "50087" ["HTTP_USER_AGENT"]=> string(72) "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:19.0) Gecko/20100101 Firefox/19.0" ["HTTP_ACCEPT"]=> string(63) "text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8" ["HTTP_ACCEPT_LANGUAGE"]=> string(35) "es-ES,es;q=0.8,en-US;q=0.5,en;q=0.3" ["HTTP_COOKIE"]=> string(165) "pla3412=servicio; pla3412_salt=1; pla3412_1_9_4=5e912e3407a2d8c8f5401f974484b855; pla3412_1_9_4_salt=LcfM8NPDAsOiB13ECz5D; PHPSESSID=867f572ce7d225392925c9fc695d0699" ["REMOTE_USER"]=> string(9) "guadalfeo" ["AUTH_TYPE"]=> string(5) "Basic" ["HTTP_HOST"]=> string(13) "192.168.0.205" ["PHP_SELF"]=> string(16) "/php/phpinfo.php" ["REQUEST_TIME"]=> int(1363882054) ["argv"]=> array(0) { } ["argc"]=> int(0) } Omitted by Firefox by a previous negative attempt? I'm not using apache, I'm using busybox httpd. Can browsers omit under certain circumstances? Internet Explorer 9 also does not report encoding: array(26) { ["HOME"]=> string(1) "/" ["TERM"]=> string(5) "vt102" ["PATH"]=> string(29) "/sbin:/usr/sbin:/bin:/usr/bin" ["SHELL"]=> string(7) "/bin/sh" ["USER"]=> string(4) "root" ["PATH_INFO"]=> string(0) "" ["REQUEST_METHOD"]=> string(3) "GET" ["REQUEST_URI"]=> string(16) "/php/phpinfo.php" ["SCRIPT_FILENAME"]=> string(20) "/www/php/phpinfo.php" ["SCRIPT_NAME"]=> string(16) "/php/phpinfo.php" ["QUERY_STRING"]=> string(0) "" ["SERVER_SOFTWARE"]=> string(20) "busybox httpd/1.19.4" ["SERVER_PROTOCOL"]=> string(8) "HTTP/1.0" ["GATEWAY_INTERFACE"]=> string(7) "CGI/1.1" ["REMOTE_ADDR"]=> string(12) "192.168.0.13" ["REMOTE_PORT"]=> string(5) "49278" ["HTTP_USER_AGENT"]=> string(70) "Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; WOW64; Trident/5.0)" ["HTTP_ACCEPT"]=> string(37) "text/html, application/xhtml+xml, */*" ["HTTP_ACCEPT_LANGUAGE"]=> string(5) "es-ES" ["REMOTE_USER"]=> string(9) "guadalfeo" ["AUTH_TYPE"]=> string(5) "Basic" ["HTTP_HOST"]=> string(13) "192.168.0.205" ["PHP_SELF"]=> string(16) "/php/phpinfo.php" ["REQUEST_TIME"]=> int(1363882991) ["argv"]=> array(0) { } ["argc"]=> int(0) } I have Comodo Antivirus/Firewall. I've deactivated and the response is the same, no headers..
Reported by
is2cool4me
on 2013-03-21 16:43:56 -
I've opened netcat locally and tried to connect with Fx and IE, and both try first with an HTTP/1.1 request (which busybox seems to support) which includes the Accept-encoding header: GET / HTTP/1.1 Accept: text/html, application/xhtml+xml, */* Accept-Language: it-IT User-Agent: Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.1; Trident/6.0) Accept-Encoding: gzip, deflate Host: localhost:123 Seeing HTTP/1.0 and no header, I feel like blaming Comodo, but I'm not certain. We're removing compression in any case, so it's not a big problem.
Reported by
dreadnaut
on 2013-03-21 17:10:05 -
Hmm that's strange. The server (192.168.0.205) is in your (192.168.0.13) local LAN, right? So we can be sure that no stupid ISP is in the way. With Antivir & Firewall disabled, I can't see a reason why both browsers don't send the accept-encoding header. > Omitted by Firefox by a previous negative attempt? Hmm. I am not 100% sure, but I doubt this can be the reason. If you are as interested as we are: You could try to fetch the Headers sent by the browser, e.g. in Firefox with the Firebug extension (in the Network panel), or with "live HTTP headers". Should look something like this: Accept text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Encoding gzip, deflate Accept-Language de-de,de;q=0.8,en-us;q=0.5,en;q=0.3 Connection keep-alive Host 192.168.0.205 User-Agent Mozilla/5.0 (Windows NT 6.1; rv:19.0) Gecko/20100101 Firefox/19.0 Maybe some (AV?) software also installs add-ons into browsers that removes the header?
Reported by
crazy4chrissi
on 2013-03-21 17:15:37 -
No need to install Firebug actually. Just press Ctrl-Shift-K, make sure "Net" is selected, and repeat the request. You can get the details clicking on the log line.
Reported by
dreadnaut
on 2013-03-21 17:17:51 -
Account Deleted I've tested with Firebug and with Firefox console. For better test, I've added to PLA as the first function to execute a dummy header to show the content of HTTP_ACCEPT_ENCODING and the test gives error (not set). Headers show that HTTP_ACCEPT_ENCODING is sent by Firefox but not received by the server. I've tested with www.microsoft.com and headers show that are sent and server response with 'Content-Encoding: gzip', so headers are in the limbo.. I'll do local test with httpd and curl..
Reported by
is2cool4me
on 2013-03-21 17:45:05 -
Account Deleted I've found the problem: busybox (1.19.4) httpd. I have disabled the support for GZIP in busybox httpd, so headers are ignored..
Reported by
is2cool4me
on 2013-03-21 18:03:02 -
I see, ignored and not passed to php. Problem "solved" then. Chris, I consider the patch in Comment #9* ready for 1.9.4.1 —I haven't committed it because there is no directory in repo yet. [*] http://code.google.com/p/phpliteadmin/issues/detail?id=197#c9
Reported by
dreadnaut
on 2013-03-22 15:31:22 -
> I haven't committed it because there is no directory in repo yet. Now there is.
Reported by
crazy4chrissi
on 2013-03-22 16:21:26 -
This issue was closed by revision r381.
Reported by
dreadnaut
on 2013-03-22 16:25:20 - Status changed:Fixed
-
Thanks, committed!
Reported by
dreadnaut
on 2013-03-22 16:25:32 -
Account Deleted It relies on the zlib extension.
Reported by
marketing@chinshare.com
on 2014-09-15 09:16:07 - Log in to comment
Reported by
crazy4chrissi
on 2013-03-20 19:24:37