It looks as though there is a problem with understanding of what chrome is saying. If you do the steps that you did, just look at the response headers:
HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
X-Powered-By: Servlet 2.5; JBoss-5.0/JBossWeb-2.1
Accept-Ranges: bytes
ETag: W/"1406-1328876700000"
Last-Modified: Fri, 10 Feb 2012 12:25:00 GMT
Content-Type: text/html
Transfer-Encoding: chunked
Content-Encoding: gzip
Vary: Accept-Encoding
Date: Thu, 02 Aug 2012 08:18:12 GMT
You see that the content is compressed with gzip.
However, in chrome you will still see:
Your connection to localhost is encrypted with 128-bit encryption.
The connection uses TLS 1.0.
The connection is encrypted using AES_128_CBC, with SHA1 for message authentication and DHE_RSA as the key exchange mechanism.
The connection is not compressed.
This is because chrome is talking about SSL stream-level compression. You can read some here http://www.belshe.com/2010/11/18/ssl-compression-and-you/
Here is a small excerpt:
One aspect of SSL which many people are not aware of is that SSL is capable of compressing the entire SSL stream. The authors of SSL knew that if you’re going to encrypt data, you need to compress it before you encrypt it, since well-encrypted data tends to look pretty random and non-compressible. But even though SSL supports compression, no browsers support it. Except Chrome 6 & later.
Generally, stream-level compression at the SSL layer is not ideal. Since SSL doesn’t know what data it is transporting, and it could be transporting data which is already compressed, such as a JPG file, or GZIP content from your web site. And double-compression is a waste of time. Because of this, historically, no browsers compressed at the SSL layer – we all felt certain that our good brothers on the server side would solve this problem better, with more optimal compression.
To enable this in JBoss/Tomcat you need to use jboss/tomcat natives (openssl).
Rado