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

          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: