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?

Was it helpful?

Solution

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.

OTHER TIPS

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.

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>

To improve overall client side performance of J2EE web application, you can try WebUtilities java library.

Here is the link :: http://code.google.com/p/webutilities/.

It provides filter, tag, servlet components to apply various client side performance practices resulting in higher performance rating against PageSpeed/YSlow.

Since version 0.0.4 it helps with following performance practices.

  1. Minimize HTTP requests - can serve multiple JS/CSS files in one request
  2. Client Side Caching - adds proper Cache-Control, Expires header
  3. On the fly JS/CSS minification - using YUICompressor
  4. Compression - supports 2way compression for gzip/deflate/compress encodings
  5. Response Caching at Server - to avoid reprocessing of unchanged resources
  6. Add Character Encoding - to let browser know in advance

It is also highly configurable/customization against MIME, URL or User-Agents.

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.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top