Uploaded image for project: 'Magnolia'
  1. Magnolia
  2. MAGNOLIA-3821

magnolia gzip compressed cache sometimes produces hieroglyphics on user browser

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Critical
    • Resolution: Fixed
    • Affects Version/s: 4.4.4
    • Fix Version/s: 4.4.10, 4.5.7
    • Component/s: cache
    • Security Level: Public
    • Labels:
      None
    • Environment:
      Linux RH 5.7 + Tomcat 6.0.32 + Apache 2.2.19 (ajp)

      Description

      After upgrading magnolia 4.3.8 to magnolia 4.4.4 we noticed that if a user refresh a page on the browser sometimes she receives a malformed page or "hieroglyphics".

      After a long analysis we discovered that:

      • the malformed page is caused by a css that is transmitted to the browsers compressed with gzip instead of plain text. Using a sniffer we notices that the server, when send the compressed content to the browser, don't set a content encoding header.
      • the hieroglyphics are a the html page compressed sent to the browser as plain text

      All works fine if the user browse the page bypassing apache, directly to tomcat on port 8080.

      To solve this issue we deleted all nodes under:
      modules/cache/config/compression/voters/content type/allowed

      Best regards,
      Damiano

        Issue Links

          Expenses

            Activity

            Hide
            gjoseph Grégory Joseph added a comment -

            All works fine if the user browse the page bypassing apache, directly to tomcat on port 8080.

            So uhm... would this be an Apache configuration issue then ? Are the headers correct when you access Tomcat directly ?
            (I suspect they might not be, and Apache thus gets the wrong idea and re-compresses the already gzipped data)

            Show
            gjoseph Grégory Joseph added a comment - All works fine if the user browse the page bypassing apache, directly to tomcat on port 8080. So uhm... would this be an Apache configuration issue then ? Are the headers correct when you access Tomcat directly ? (I suspect they might not be, and Apache thus gets the wrong idea and re-compresses the already gzipped data)
            Hide
            llozes@hotetec.com Leo Lozes added a comment -

            I think we just had the same issue today.

            The problem we had was scrambled content at the end of the page (after the </html> tag), only in Chrome, and only in the public instances (without logging).

            After talking to Christian Ringele, he thought it was something that had to do with cache and gzip. He was right, we disabled the gzip filter and everything worked (anyway we have the compression enabled on Apache).
            Damiano, what you did seems to be the other solution, disabling the cache, so it really seems to be a problem between cache and gzip

            And Apache has nothing to do with it, because we also reproduced this issue in our test environment, and there's no Apache there.

            Show
            llozes@hotetec.com Leo Lozes added a comment - I think we just had the same issue today. The problem we had was scrambled content at the end of the page (after the </html> tag), only in Chrome, and only in the public instances (without logging). After talking to Christian Ringele, he thought it was something that had to do with cache and gzip. He was right, we disabled the gzip filter and everything worked (anyway we have the compression enabled on Apache). Damiano, what you did seems to be the other solution, disabling the cache, so it really seems to be a problem between cache and gzip And Apache has nothing to do with it, because we also reproduced this issue in our test environment, and there's no Apache there.
            Hide
            had Jan Haderka added a comment -

            More details on how to reproduce the problem from duplicate report:
            Open in chrome (not logged in, needs to be served from the cache) the contact form page

            Only happens in chrome, works in firefox and safari.

            workarounds:
            1. Disable the gzip filter, problem gone.
            2 or: server the form not form cache by adding query parameter to the url, problem gone.
            Seems its the combination that the cahch gzipes, and the gzip filter gzipes somehow also, or at least manipulates the http header wrong.

            Issue has been confirmed also on 4.4.7. and 4.5.2

            Jan: in 4.5 any page using form should be excluded from the cache automatically. Can anyone confirm that it still happens after flushing Magnolia cache and making sure there are no stale copies of the page in cache?

            Show
            had Jan Haderka added a comment - More details on how to reproduce the problem from duplicate report: Open in chrome (not logged in, needs to be served from the cache) the contact form page Only happens in chrome, works in firefox and safari. workarounds: 1. Disable the gzip filter, problem gone. 2 or: server the form not form cache by adding query parameter to the url, problem gone. Seems its the combination that the cahch gzipes, and the gzip filter gzipes somehow also, or at least manipulates the http header wrong. Issue has been confirmed also on 4.4.7. and 4.5.2 Jan: in 4.5 any page using form should be excluded from the cache automatically. Can anyone confirm that it still happens after flushing Magnolia cache and making sure there are no stale copies of the page in cache?
            Hide
            rgibson Rory Gibson added a comment -

            What are the possible consequences of disabling GZip in magnolia in 4.4.6? Will it make a big difference performance wise?

            Show
            rgibson Rory Gibson added a comment - What are the possible consequences of disabling GZip in magnolia in 4.4.6? Will it make a big difference performance wise?
            Hide
            rgibson Rory Gibson added a comment -

            We are having this issue when without using Apache/httpd. We only use Tomcat on some of our internal servers and the issue is intermittently appearing on Chrome.

            Do we know if the problem afflicts only certain types of files? It is hard to find this out by testing because the problem appears intermittently.

            Show
            rgibson Rory Gibson added a comment - We are having this issue when without using Apache/httpd. We only use Tomcat on some of our internal servers and the issue is intermittently appearing on Chrome. Do we know if the problem afflicts only certain types of files? It is hard to find this out by testing because the problem appears intermittently.
            Hide
            mdivilek Milan Divilek added a comment -

            If you start see this issue. Instead disabling whole GZip compression like a workaround you can add Chrome into rejected user agents for compression.
            This you can do in Configuration->module/cache/config/compression/voters/userAgent/rejected. For example add property named "01" with value ".Chrome/18." you disallowed compression for Chrome v.18 or value ".Chrome." which disallow compression for all Chrome versions.

            http://documentation.magnolia-cms.com/modules/cache.html#Compression

            Show
            mdivilek Milan Divilek added a comment - If you start see this issue. Instead disabling whole GZip compression like a workaround you can add Chrome into rejected user agents for compression. This you can do in Configuration->module/cache/config/compression/voters/userAgent/rejected. For example add property named "01" with value ". Chrome/18. " you disallowed compression for Chrome v.18 or value ". Chrome. " which disallow compression for all Chrome versions. http://documentation.magnolia-cms.com/modules/cache.html#Compression

              People

              • Assignee:
                mdivilek Milan Divilek
                Reporter:
                dbianchi Damiano Bianchi
              • Votes:
                3 Vote for this issue
                Watchers:
                3 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved:
                  Date of First Response:

                  Development