Web Response Compression Examples

Deactivating Compression

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

Configuring Compression

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 setDefaultGZIPEncoding method.

Look at the sample demo properties file: org.projectapollo.demo.Demo.properties