Mailing-List: contact tomcat-user-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Users List" <tomcat-user@jakarta.apache.org>
Received-SPF: pass (hermes.apache.org: local policy)
Message-Id: <200505201614.j4KGEm528698@raq2.mylinuxisp.com>
Reply-To: <bj.guillot@intermedix.org>
From: "B.J. Guillot" <bj.guillot@intermedix.com>
To: <tomcat-user@jakarta.apache.org>
Subject: Problems with gzip compression with Apache/Tomcat cluster and Firefox
Date: Fri, 20 May 2005 11:14:52 -0500
Organization: Intermedix
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0000_01C55D2D.2810D370"
Thread-Index: AcVdVw2WOuGUTX3gQs+hUA/IQ8fG6g==

------=_NextPart_000_0000_01C55D2D.2810D370
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

We have recently been experimenting with enabling gzip/deflate compression
via our Apache/Tomcat cluster, but have encountered some problems with the
way the compression works with the Firebox browser.

 
When Firefox brings up a compressed page for the first time, it looks fine.
If they reload a static html page, bizarre things start to happen.  In some
cases, garbage just gets displayed on screen (looks like the actual gzip
encoded stream), and other times Firefox displays a dialog box asking if you
want to download the html files.  When IE is used, it works fine.

 
Some background: Running two-node Tomcat 5.5.4 cluster using JK2 2.0.4
protocol to communicate back to Apache2 2.0.52 for load balancing.  Browsers
tried were Firefox 1.0.3 and Internet Explorer 6.0.

 
If I use Tomcat's gzip compression alone with Firefox, it works fine.  It's
only when we through in Apache and JK2 into the mix with the cluster that
Firefox displays charged.  It seems to be an issue related to the way that
compressed pages get cached.

 
I'm not sure if the problem lies with Tomcat, Apache, JK2, or Firefox
itself.  Can anyone provide some pointers?  Thanks.

 
Regards,

B.J. Guillot

 
------=_NextPart_000_0000_01C55D2D.2810D370--