I have a kind of MVC architecture and the compressor-code is in the
controller thru' which all requests pass, so it is kind of easy.
For your site it sounds a lot more like a job for 2.3 specific things. I
only mentioned it as I think that there's not enough talk of real speed vs
perceived speed: ie, it's more complex than 'smallest fastest file'.
-----Original Message-----
From: Bartosz Staniszewski [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, March 28, 2001 10:32 AM
To: [EMAIL PROTECTED]
Subject: RE: Compressing Tomcat output.
Hello, AL!
If i uderstand, your code is a servlet body?
But we search for other kind of solution...
We have application running on the web, and we want add gzip functionality
to its all (without some exceptions - small sites, gif and jpg's) contents
without modifications in jsp sources.
As You wrote mod_gzip is a less flexible solution (if i'm right - i didn't
try it). I try to write a request Interceptor for this.
We can't migrate to Tomcat 4.0 as long as it is beta. With valves - new
features of 4.0 version, dynamic compressing of some contents should be
easier.
Thanks,
Stanisz
-----Original Message-----
From: Alistair Hopkins [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, March 27, 2001 4:15 PM
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: RE: Compressing Tomcat output.
We have a conditional compression setup: if some pages are small, it is
better not to compress them as the time the browser takes to decompress
makes the site slower on aggregate, esp with netscape.
The settings to control whether we zip and the threshold at which to zip can
then be adjusted for the most responsive 'feel'
import java.util.zip.*;
.
.
ByteArrayOutputStream bytes;
(put html into bytes)
..............................
bytes.writeTo(out);
out.close();
}
else
{
resource.log.debug("no zip");
bytes.writeTo(response.getOutputStream());
}
Works well.
AL
