Closed GoogleCodeExporter closed 9 years ago
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
Original comment by crazy4ch...@gmail.com
on 20 Mar 2013 at 7:27
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
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
> 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
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
> 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
@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
Attached is a patch to revert compression.
Original comment by dreadnaut
on 21 Mar 2013 at 1:04
Attachments:
Original comment by dreadnaut
on 21 Mar 2013 at 1:05
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
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
> @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
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
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
> 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
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
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
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
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
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
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
> 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
This issue was closed by revision r381.
Original comment by dreadnaut
on 22 Mar 2013 at 4:25
Thanks, committed!
Original comment by dreadnaut
on 22 Mar 2013 at 4:25
It relies on the zlib extension.
Original comment by market...@chinshare.com
on 15 Sep 2014 at 9:16
Original issue reported on code.google.com by
is2cool...@gmail.com
on 20 Mar 2013 at 6:36