Tomcat 7 GZIP compression not working
Asked Answered
T

6

33

I have added the following lines in tomcat's conf/server.xml file to enable gzip compression but its not working. Pages are still uncompressesd.

 <Connector port="8080"
         compression="on"
         compressionMinSize="2048"
         noCompressionUserAgents="gozilla, traviata"
         compressableMimeType="text/html,text/xml,text/plain,text/css,
         text/javascript,text/json,application/x-javascript,
         application/javascript,application/json"/>

Any idea?

Tripe answered 20/5, 2013 at 16:7 Comment(3)
have never seen such form, will be interesting if some solution appeared. Just for you information - on our project we use following way blog.max.berger.name/2010/01/jetty-7-gzip-filter.htmlFeuilleton
Is your Tomcat instance fronted by Apache on port 80 or is Tomcat accessed directly on port 8080?Sagittarius
hi david..u are right..it is fronted by apache on port 80 and that is the reason I get uncompressed files...when I access my tomcat on port 8080, i get compressed files....thanks for pointing me in the right direction..Tripe
S
37

If Tomcat is fronted by Apache on port 80, you will need to enable compression in Apache itself. The compression in Tomcat will only work if you access it directly on port 8080.

Sagittarius answered 21/5, 2013 at 14:58 Comment(0)
M
15

On Windows, I encountered this behaviour while trying to temporarily enable content compression in my development environment to gain a rough understanding of the total payload of a page in my application.

I can confirm that ESET NOD32 Antivirus does behave in the way that @bugs_ describes in his answer to this question and I can also confirm that running Fiddler4 has the same effect. However, both closing Fiddler and disabling NOD32's HTTP scanning did not solve the problem, to do that, I had to disable the use of 'sendfile' in my connector as follows:

<Connector port="8080" protocol="HTTP/1.1"
           connectionTimeout="20000"
           compression="on" compressionMinSize="8192" useSendfile="false"
           compressableMimeType="text/html,text/xml,text/plain,text/css,text/javascript,application/javascript"
           redirectPort="8443" />

The important attribute, here, is useSendfile="false"

I am using Apache Tomcat 8, under Windows. The Tomcat documentation (http://tomcat.apache.org/tomcat-8.0-doc/config/http.html) says the following about useSendfile:

Use this attribute to enable or disable sendfile capability. The default value is true. Note that the use of sendfile will disable any compression that Tomcat may otherwise have performed on the response.

And this about compression:

There is a tradeoff between using compression (saving your bandwidth) and using the sendfile feature (saving your CPU cycles). If the connector supports the sendfile feature, e.g. the NIO connector, using sendfile will take precedence over compression. The symptoms will be that static files greater that 48 Kb will be sent uncompressed. You can turn off sendfile by setting useSendfile attribute of the connector, as documented below, or change the sendfile usage threshold in the configuration of the DefaultServlet in the default conf/web.xml or in the web.xml of your web application.

Miscreant answered 26/3, 2016 at 17:58 Comment(1)
In my case was turning turning ESET enough. Because my tomcat do not serve files from disk.Cordwood
C
5

In my case it didn't worked because of Antivirus (ESET, Windows)

It was binded somewhere before browser. It unpacked body and remove "Content-Encoding" header. For browser response looked like normal not compressed response. Even in Fiddler it was already decompressed.

Https responses were working, but http resposes were decompresed by ESET.

It is not enough. Turn ESET off. I had to go to "advanced settings" -> "Web access protection" -> "HTTP, HTTPS" and turn it off there

If you serve files from hard drive you may need add option useSendFile="false" into connector.

Cordwood answered 24/3, 2016 at 16:25 Comment(1)
I wish I knew that 2 weeks ago instead of loosing interminable hours trying to figure out what I'm doing wrong. Cheers!Gaffe
M
4

I was testing similar server.xml changes in my local development environment and was frustrated that it was not working either.

My issue was that I was making edits to my local Tomcat installation (C:\apache-tomcat-8.0.5) that I selected when using the Servers window -> (right-click) -> New -> Server dialog in Spring Tool Suite.

However, when published, the actual tomcat directory being used was located in (workspace folder)\.metadata\.plugins\org.eclipse.wst.server.core\tmp0.

You can check the published location by right-clicking the server and choosing "Browse Deployment Location..."

enter image description here

From there you can update the appropriate server.xml file, or you could delete and re-add the server.

Marcasite answered 22/6, 2014 at 23:48 Comment(0)
G
2

11 years later, and nobody saw the typo.

The op used compressableMimeType but there's a typo. It must be compressibleMimeType, with an i, not an a, as per the Tomcat 7 doc

Ghislainegholston answered 16/1, 2024 at 10:24 Comment(1)
TY for pointing this out. I believe I've been chasing this in our environment.Hydrotherapeutics
V
0

Maybe set compression="force" instead of compression="on"

Verbosity answered 27/6, 2022 at 6:43 Comment(0)

© 2022 - 2025 — McMap. All rights reserved.