Tomcat Compression Does Not Add a Content-Encoding: gzip in the Header

Question

I am using Tomcat to compress my HTML content like this:

<Connector port="8080" maxHttpHeaderSize="8192"
maxProcessors="150" maxThreads="150" minSpareThreads="25"
maxSpareThreads="75" enableLookups="false" redirectPort="8443"
acceptCount="150" connectionTimeout="20000" disableUploadTimeout="true"
compression="on" compressionMinSize="128" noCompressionUserAgents="gozilla, traviata"
compressableMimeType="text/html"
URIEncoding="UTF-8" />

In the HTTP header (as observed via YSlow), however, I am not seeing

Content-Encoding: gzip

resulting in a poor YSlow score.

All I see is

HeadersPost
Response Headers
Server: Apache-Coyote/1.1
Content-Type:   text/html;charset=ISO-8859-1
Content-Language:   en-US
Content-Length: 5251
Date:   Sat, 14 Feb 2009 23:33:51 GMT

I am running an apache mod_jk Tomcat configuration.

How do I compress HTML content with Tomcat, and also have it add "Content-Encoding: gzip" in the header?

Answer 1

Try using a gzip compression filter:

http://www.onjava.com/pub/a/onjava/2003/11/19/filters.html

Configure it in your web.xml and you should be all set.

Answer 2

Perhaps the compression Tomcat is referring to isn't gzip? It's a stab in the dark, but it might relate to white-space compression, or line trimming.

I would imagine Tomcat would be a bit more explicit in this regard (here's hoping).

We have the gzip filter mentioned by duffmo running in our application, the web.xml looks something like this:

<?xml version="1.0" encoding="UTF-8"?>
<web-app version="2.4" xmlns="http://java.sun.com/xml/ns/j2ee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"  xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee web-app_2_4.xsd">

    <display-name>App-Web</display-name>

    <!-- FILTERS -->

    <!-- Gzip filter -->
    <filter>
        <filter-name>GZIPFilter</filter-name>
        <filter-class>weblogicx.servlet.gzip.filter.GZIPFilter</filter-class>
    </filter>

    [snip]    
</web-app>

Answer 3

Have a look at http://sourceforge.net/projects/pjl-comp-filter/.

Other custom solutions may have memory leaks.

Also, if you are using mod_jk then you are certainly not using the 8080 connector (which supports compression) for those requests.

Answer 4

Tomcat will be doing the compression. However because you are using mod_jk I guess you are getting you requests via Apache on port 80 rather than tomcat on port 8080. As an experiment try getting your page via port 8080 and then checking yslow you should see the correct headers.

I think what is happening is that apache is unzipping the content that it is getting from tomcat via mod_jk and then passing the deflated content on to the browser.

If you wish to use mod_jk then you will need to set up your compression on Apache rather than Tomcat.

Good luck

Answer 5

I had a look at the Tomcat documentation here: http://tomcat.apache.org/tomcat-5.5-doc/config/http.html

It mentions using compression="force" which worked for me. It also says you can set a minimum number. This worked fine for me

<Connector port="8080" compression="256000" />

(compress anything over 256Kb)

The default value for compressableMimeType meant that I didn't need that attribute. Also note that it doesn't list CompressionMinSize attribute.