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?
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.
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.
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.
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..."
From there you can update the appropriate server.xml file, or you could delete and re-add the server.
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
Maybe set compression="force" instead of compression="on"
