[MAGNOLIA-2334] GZip encoding of js and css resources doesn't work reliably with IE6 Created: 20/Aug/08  Updated: 23/Jan/13  Resolved: 20/Jan/09

Status: Closed
Project: Magnolia
Component/s: cache
Affects Version/s: 3.6.1
Fix Version/s: 4.0, 3.6.4, 3.6.5

Type: Bug Priority: Major
Reporter: Will Scheidegger Assignee: Jan Haderka
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows XP Professional, Internet Explorer 6 SP2


Attachments: JPEG File image001.jpg    
Issue Links:
dependency
depends upon MAGNOLIA-2495 Selectively switch off the gzip compr... Closed
relation
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   

When trying to load a page served by Magnolia 3.6.1 on a computer in the departments of the Canton of Bern (and also Basel Land) the browser is only displaying hieroglyphs instead of the page (public as well as admin pages). Only the standard login page is displayed correctly.

It's not a character encoding problem: You cannot look at the source code with a few mangled characters. It's nothing but hieroglyphs (see attached screenshot).
I suspect it to be a problem with page compression - I did not have the chance to try it with compression turned off.



 Comments   
Comment by Jan Haderka [ 20/Aug/08 ]

I think you are running into MAGNOLIA-2177. Content gets served gzipped even tho the client doesn't support it. Although I have no clue why would someone has IE 6 configured to make it not ask_for/accept gzipped content.

Comment by Magnolia International [ 20/Aug/08 ]

Will,
If you had the chance to capture the request/response headers it would help tremendously. (for at least 3 different cases: 1)page is not cached yet, 2)page is cached on server but not on browser 3) page is in browser cache)

Could you also detail the network configuration? Proxies, ... ?

Comment by Will Scheidegger [ 26/Aug/08 ]

Grégory

I was able to convince the IT guys @ the Canton of Bern to install debugbar and run the tests for me. Here are the results:

  • case 1: Page is not cached yet: Hieroglyphs!
  • case 2: Page is in the cache: It displays alright
    (did not test case 3)

Astonishingly the installed IE does seem to accept gzipped content. The request + response headers for a sample page were:
-----------------------------------------------------------------------
GET /web/vicem/de.html HTTP/1.1
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/vnd.ms-excel, application/vnd.ms-powerpoint, application/msword, application/x-shockwave-flash, /
Accept-Language: de-ch
Accept-Encoding: gzip, deflate

HTTP/1.0 200 OK
Pragma:
Content-Encoding: gzip
Content-Length: 1717
Content-Type: text/html;charset=UTF-8
X-Cache: MISS from proxy.be.ch
Expires: Sun, 21 Apr 2047 18:58:12 GMT
Last-Modified: Tue, 26 Aug 2008 09:06:04 GMT
-----------------------------------------------------------------------

Now for the customer that triggered the issue this won't help much because we had to deactivate the cache there since nearly every single page is customized for the current user. So it really seems like it must have something to do with MAGNOLIA-2177. Maybe the content headers are not set correctly when the page is delivered the first time?

Does this info help in any way? Would you like me to run an other test?

Will

Comment by Todd Farrell [ 17/Sep/08 ]

We have experienced this same issue where IE appears to display gzipped content but we've also had problems where stylesheets were being retrieved in a gzipped format and not being interpreted correctly.

A similar investigation looking at the HTTP headers revealed that our corporate proxy server (apparently an aging version of Microsoft ISA) was returning gzipped content to IE even though IE did not actually send an Accept: gzip type header – this seems to confuse IE but not the other browsers.

I note that your request/response + headers suggest a transparent proxy might be in use (X-Cache: MISS from proxy.be.ch) – in our case it is a browser configured proxy server via group policy.

What we found was when users access the site directly (not through the proxy), the pages rendered fine in IE. However, when accessing the site through the corporate proxy server, there were intermittent problems.

Since this only appeared to be affecting internal staff (external users who aren't required to use the corporate proxy server have not reported any issues), our current workaround is a group policy setting that forces IE to exclude the relevant domain names from being proxied. We're also planning to upgrade to a more recent version of ISA to see whether that helps.

Another indicator that it might not be a problem with Magnolia is that Atlassian Confluence also displays similar issues with stylesheets not being applied to pages when it is accessed via our corporate proxy server.

I have no conclusive evidence either way though – it's very hard to reproduce since it happens intermittently for us – hope this helps!

Comment by Magnolia International [ 17/Sep/08 ]

Thanks Todd, useful info ! Is there any chance you'd have a more precise reference to Confluence's issue? I assume it must be on their Jira too ...

Comment by John Kalstrom [ 26/Nov/08 ]

Boris, we are seeing IE6 JS and CSS truncation problems, only when going through Apache, on our new product that is using 3.6.3. The problems go away when we disable compression. (GZipFilter and in cache executor/store/cacheContent/compressible) Currently the site URL is http://test.ereceptionist.co.uk

Other production products (efaxcorporate.com, efax.com domestic and international, evoicereceptionist.com (but only logged-in admin)) are using 3.5.4 without any issues.

I know the bug is already Major, but can we get an escalation because we are enterprise?
Site having problems is due to become public visible in a week or so. We are going to have to disable compression, which is unhappy.

Comment by Jan Haderka [ 20/Jan/09 ]

This issue is fixed by MAGNOLIA-2495. IE6 declares support for gzipped JS and CSS, but is known not to work with it reliably. This issue didn't occur prior 3.6, because before we compressed only html. Since Magnolia 3.6 we started to serve even JS and CSS compressed to speed up the delivery of the content. Now with the MAGNOLIA-2495, we will allow selectively disable compression of the content not only based on the content type but also based on the user agent issuing the request. And we deliver default configuration in which when IE6 is detected, content will be sent back uncompressed even if IE6 declares support for the compression. This way delivery of the content to IE6 will be bit slower but should not get scrambled any more.

Comment by Jan Haderka [ 16/Mar/09 ]

some evidence to support the above:
http://www.julienlecomte.net/blog/2007/08/13/ (look for comments from Jan van Diemen)
http://support.microsoft.com/kb/871205

... there is more if you google for it.

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