workaround for gzdecode()

[GoogleCodeExporter]

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.

Original issue reported on code.google.com by is2cool...@gmail.com on 20 Mar 2013 at 6:36

[GoogleCodeExporter]

Thanks for your report.
What PHP version are you using?
Unfortunately, the manual does not clearly say which versions include gzdecode 
and which don't.

@Drednaut, could you please have a look at this?

I think the workaround is valid, as the difference between gzencode and 
gzdefalte only seems to be that gzencode adds a header.

Maybe we should use gzdeflate and gzinflate and if we output it to the browser, 
add the header manually at the beginning (to make IE happy and not use deflate 
directly)?

Original comment by crazy4ch...@gmail.com on 20 Mar 2013 at 7:24

[GoogleCodeExporter]

Original comment by crazy4ch...@gmail.com on 20 Mar 2013 at 7:27

• Added labels: Target-1.9.4.1

[GoogleCodeExporter]

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.

Original comment by crazy4ch...@gmail.com on 20 Mar 2013 at 7:28

• Added labels: Type-Defect
• Removed labels: Type-Enhancement

[GoogleCodeExporter]

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_http
request/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.

Original comment by dreadnaut on 20 Mar 2013 at 9:00

[GoogleCodeExporter]

> 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.

Original comment by crazy4ch...@gmail.com on 20 Mar 2013 at 9:33

[GoogleCodeExporter]

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.

Original comment by dreadnaut on 20 Mar 2013 at 10:39

[GoogleCodeExporter]

> 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.

Original comment by is2cool...@gmail.com on 21 Mar 2013 at 8:10

[GoogleCodeExporter]

@is2cool4me: out of curiosity, which browser are you using? Are you using a 
proxy?

Original comment by dreadnaut on 21 Mar 2013 at 12:12

[GoogleCodeExporter]

Attached is a patch to revert compression.

Original comment by dreadnaut on 21 Mar 2013 at 1:04

Attachments:

• nozlib.diff

[GoogleCodeExporter]

Original comment by dreadnaut on 21 Mar 2013 at 1:05

• Changed state: Started

[GoogleCodeExporter]

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.

Original comment by crazy4ch...@gmail.com on 21 Mar 2013 at 1:09

[GoogleCodeExporter]

IMO not worth it, since resources should be cached by the browser, but I'll 
take a look at it post-#190.

Original comment by dreadnaut on 21 Mar 2013 at 1:11

[GoogleCodeExporter]

> @is2cool4me: out of curiosity, which browser are you using? Are you using a 
proxy?

Firefox 19.0.2 without proxy.

Original comment by is2cool...@gmail.com on 21 Mar 2013 at 3:59

[GoogleCodeExporter]

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.

Original comment by dreadnaut on 21 Mar 2013 at 4:03

[GoogleCodeExporter]

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

Original comment by crazy4ch...@gmail.com on 21 Mar 2013 at 4:28

[GoogleCodeExporter]

> 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..

Original comment by is2cool...@gmail.com on 21 Mar 2013 at 4:43

[GoogleCodeExporter]

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.

Original comment by dreadnaut on 21 Mar 2013 at 5:10

[GoogleCodeExporter]

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?

Original comment by crazy4ch...@gmail.com on 21 Mar 2013 at 5:15

[GoogleCodeExporter]

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.

Original comment by dreadnaut on 21 Mar 2013 at 5:17

[GoogleCodeExporter]

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..

Original comment by is2cool...@gmail.com on 21 Mar 2013 at 5:45

[GoogleCodeExporter]

I've found the problem: busybox (1.19.4) httpd. I have disabled the support for 
GZIP in busybox httpd, so headers are ignored..

Original comment by is2cool...@gmail.com on 21 Mar 2013 at 6:03

[GoogleCodeExporter]

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

Original comment by dreadnaut on 22 Mar 2013 at 3:31

[GoogleCodeExporter]

> I haven't committed it because there is no directory in repo yet.
Now there is.

Original comment by crazy4ch...@gmail.com on 22 Mar 2013 at 4:21

[GoogleCodeExporter]

This issue was closed by revision r381.

Original comment by dreadnaut on 22 Mar 2013 at 4:25

• Changed state: Fixed

[GoogleCodeExporter]

Thanks, committed!

Original comment by dreadnaut on 22 Mar 2013 at 4:25

[GoogleCodeExporter]

It relies on the zlib extension.

Original comment by market...@chinshare.com on 15 Sep 2014 at 9:16