Web Response Compression Examples
WRRLC can increase the performance of the client by
compressing the dynamic data stream coming out of the servlet. The
compressed data is then transfered over the network and decompressed
automatically in the remote users' browser.
Compressing the data stream on the server does take additional CPU time,
often the trade of is well worth the increased client performance. You must
customize when compression is performed by using the setGZIPEncoding method
on the HTTPResponse class. Often it may not make sense to compress
data streams coming out of the servlet which are not HTML based. For
example, if the servlet is returning an image/gif, gzip compression
is not effective. There is no reason for the server to waste it's
time compressing this stream. Also very large streams may take unfair
amounts of CPU power to compress, and you may wish to deactivate
compression for these responses.
See the demo site for Compression being deactived for MS word files: ResultsBroker.java
I have used GZIP Encoding in a production environment for nearly
two years, and have run into few problems. There are however a few browsers
which need to have GZIP turned off due to bugs in the browser. The HTTPResponse
allows you to define a list of strings, if the browser AGENT string matches a substring
search then GZIP encoding will be deactivated, even if the browser claims GZIP compliance.
The vector of substrings can be set individually on a HTTPResponse using the setNoGZIPSubstring(Vector)
method, or for all HTTPResponses using the addBadGZIPBrowserMatch method on the PageManager.
It is also possible to set the default for using GZIP encoding using the PageManager's
Look at the sample demo properties file: org.projectapollo.demo.Demo.properties