Problems getting tomcat 7 to use gzip compression

Question

Tomcat 7 (unsure if this is a problem on other versions) seems to intermittently fail to apply gzip compression.

I find that it wont work for a particular start/deployment but then stopping and starting the service may cause it to start working again.

So it either seems to work or not based on a particular start. This has been driving me crazy for basically a full day and a half now and I was mucking around with configs etc but with no changes I can repeatedly (must have checked this about 20-30 times now just to ensure I'm not imagining things (It's been a long day!)) get it work/not work just by stopping and starting the tomcat service. The probability of it gzipping stuff is approximately 50% - at first I thought it was reliably following a work/doesn't work pattern but occasionally you'll get it working a few times in a row.

I've been through the logs with a fine toothcomb and there's nothing indicating there being something wrong with any of the start ups.

Interestingly I have a different server where it doesnt work at all with the same basic configuration (which I've been diffing all day to rule out the different variables there). The only real difference left is that one has a lot more apps on it (its our build server, whereas the other one is my machine), which leads me to wonder if there's some kindof race that gets negatively effected by having a lot of apps to load.

I've also experimented with using NIO (the non blocking connector) and useSendfile="false" (which is ignored if using the normal blocking one as the catalina logs will inform you) but this seems to suffer from the same problem.

Really stumped by this.

Some of the resources/things I've tried:

• use force value for compression
• the tomcat 7 docs
• useSendfile=false

also none of the above help me understand the difference between the two machines. On the build server we are using dynamic loading for the most part whereas on my machine I just use hard coded Contexts. I feel like I've ruled that out though as I set up a hard coded context on the server which also didnt work.

Another thing I've noticed come up a lot is people talking about using apache and tomcat together and then needing to do the compression in apache. We aren't doing that! It's just tomcat.

EDIT

I've just stumbled across this post which prompted my to try the compression using a browser on the server... the compression is working on there! Not sure what to make of that!

EDIT

on further reflection the browser I used on the server was chrome as firefox isn't installed - it's possible that this reliably reports what is going on with the headers... I think I'm going to stick to curl + wireshark in the future though!

Answer 1

As Victor mentioned in the Firefox bug you filed, Firefox's Network tab has been displaying only the uncompressed size (under the "Size" column). In Firefox 37 (currently Nightly), you can see the compressed size (under the new "Transferred" column).

Answer 2

Ok. Just done some more diagnostics after it looked like it was working on local host on the server.

Its worth mentioning that I was using firefox's normal network tab, along with firebug and yslow (you need firebug to use yslow). These were all intermittently reporting that compression was not on.

Using curl it turned out it was reliably reporting compression as on.

I then subsequently snooped what the browser was doing using wireshark which confirmed that compression was on (you can see the compressed nonsense and everything) whilst for the same requests firefox + yslow was saying it wasn't.

No idea what's going on here but it appears to just be an error with the tools.

The bottom line is don't trust yslow and firebug... they will lie to you! They are useful for loads of other stuff but not for detecting whether compression is switched on or not. It's also possible that this is just a problem with yslow in firefox - presumably it just looks at what firefox (incorrectly) says about the request