workaround for gzdecode()

Issue #197 resolved
Former user created an issue

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)

  1. Christopher Kramer
    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)?
    

    Reported by crazy4chrissi on 2013-03-20 19:24:37

  2. Christopher Kramer
    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

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

  4. Christopher Kramer
    > 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

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

  6. Former user 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

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

    Reported by dreadnaut on 2013-03-21 12:12:40

  8. Christopher Kramer
    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

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

  10. Former user 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

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

  12. Christopher Kramer
    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

  13. Former user 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

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

  15. Christopher Kramer
    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

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

  17. Former user 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

  18. Former user 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

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

  20. Christopher Kramer
    > 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

  21. dreadnaut
    This issue was closed by revision r381.
    

    Reported by dreadnaut on 2013-03-22 16:25:20 - Status changed: Fixed

  22. Former user Account Deleted
    It relies on the zlib extension.
    

    Reported by marketing@chinshare.com on 2014-09-15 09:16:07

  23. Log in to comment