[MAGNOLIA-3821] magnolia gzip compressed cache sometimes produces hieroglyphics on user browser Created: 01/Sep/11  Updated: 19/Apr/13  Resolved: 30/Oct/12

Status: Closed
Project: Magnolia
Component/s: cache
Affects Version/s: 4.4.4
Fix Version/s: 4.4.10, 4.5.7

Type: Bug Priority: Critical
Reporter: Damiano Bianchi Assignee: Milan Divilek
Resolution: Fixed Votes: 3
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Linux RH 5.7 + Tomcat 6.0.32 + Apache 2.2.19 (ajp)


Attachments: PNG File Screen shot 2012-05-15 at 11.52.17.png    
Issue Links:
causality
dependency
duplicate
is duplicated by MAGNOLIA-4413 GZip filter breaks cached forms in ch... Closed
is duplicated by MAGNOLIA-4591 GZip filter adds strange binary chara... Closed
is duplicated by MGNLEE-207 Random encoding problems with Apache ... Closed
is duplicated by MAGNOLIA-4670 STK Templates making use of the PUR F... Closed
relation
is related to MAGNOLIA-4413 GZip filter breaks cached forms in ch... Closed
Template:
Acceptance criteria:
Empty
Task DoD:
[ ]* Doc/release notes changes? Comment present?
[ ]* Downstream builds green?
[ ]* Solution information and context easily available?
[ ]* Tests
[ ]* FixVersion filled and not yet released
[ ]  Architecture Decision Record (ADR)
Bug DoR:
[ ]* Steps to reproduce, expected, and actual results filled
[ ]* Affected version filled
Date of First Response:

 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



 Comments   
Comment by Magnolia International [ 10/Nov/11 ]

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)

Comment by Leo Lozes [ 26/Jan/12 ]

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.

Comment by Jan Haderka [ 15/May/12 ]

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?

Comment by Rory Gibson [ 30/May/12 ]

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

Comment by Rory Gibson [ 30/May/12 ]

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.

Comment by Milan Divilek [ 27/Sep/12 ]

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

Generated at Mon Feb 12 03:50:00 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.