Bug 60276

Summary: upgrade HTTP/2 can't use gzip compress.
Product: Tomcat 8 Reporter: cnsilvan <cnsilvan>
Component: ConnectorsAssignee: Tomcat Developers Mailing List <dev>
Status: RESOLVED FIXED    
Severity: enhancement    
Priority: P2    
Version: 8.5.6   
Target Milestone: ----   
Hardware: PC   
OS: All   

Description cnsilvan 2016-10-19 06:10:06 UTC
Gzip compress is work when only use apr.But it doesn't work after upgrade Http/2;
Comment 1 Remy Maucherat 2016-10-19 06:40:28 UTC
I don't understand, can you explain the issue more thoroughly ?
Comment 2 cnsilvan 2016-10-19 07:09:57 UTC
In server.xml,like this:

<Connector .....			compressableMimeType="text/html,text/javascript"
compression="on" 
compressionMinSize="2048" 
noCompressionUserAgents="gozilla, traviata"
port="8443" 
protocol="org.apache.coyote.http11.Http11AprProtocol"
......... >
<UpgradeProtocol className="org.apache.coyote.http2.Http2Protocol"/>
<SSLHostConfig
	........../>
	</SSLHostConfig>
</Connector>

The compression="on" doesn't work when use this config.
But if I remove "UpgradeProtocol" element ,it works;


Simply put, when using http / 2, the compression function is not available.
Comment 3 cnsilvan 2016-10-19 07:12:41 UTC
(In reply to Remy Maucherat from comment #1)
> I don't understand, can you explain the issue more thoroughly ?

In server.xml,like this:

<Connector .....			compressableMimeType="text/html,text/javascript"
compression="on" 
compressionMinSize="2048" 
noCompressionUserAgents="gozilla, traviata"
port="8443" 
protocol="org.apache.coyote.http11.Http11AprProtocol"
......... >
<UpgradeProtocol className="org.apache.coyote.http2.Http2Protocol"/>
<SSLHostConfig
	........../>
	</SSLHostConfig>
</Connector>

The compression="on" doesn't work when use this config.
But if I remove "UpgradeProtocol" element ,it works;


Simply put, when using http / 2, the compression function is not available.
Comment 4 Remy Maucherat 2016-10-19 07:55:00 UTC
Ok. I would say it is unlikely integrated compression is implemented in HTTP/2 as it was in the HTTP/1.1. We'll see, but it's probably a good idea to plan to migrate to a different solution for compression.

Right now, there's also no provision to pull configuration from the Connector as well, the UpgradeProtocol element is independent.
Comment 5 cnsilvan 2016-10-19 09:58:52 UTC
(In reply to Remy Maucherat from comment #4)
> Ok. I would say it is unlikely integrated compression is implemented in
> HTTP/2 as it was in the HTTP/1.1. We'll see, but it's probably a good idea
> to plan to migrate to a different solution for compression.
> 
> Right now, there's also no provision to pull configuration from the
> Connector as well, the UpgradeProtocol element is independent.

Nginx can use gzip compression with http/2 module.
So I think, tomcat may also support.(sad...)
Maybe tomcat will support in the future...
Comment 6 Konstantin Kolinko 2016-10-19 13:26:02 UTC
I think that using compression with dynamic data (as in your configuration) is insecure. There are well-known CRIME and BREACH attacks. See

https://en.wikipedia.org/wiki/CRIME

Tomcat 8.5 and 9 can be configured to serve pre-compressed static files. This is configured with init-param "precompressed" of DefaultServlet.

http://tomcat.apache.org/tomcat-8.5-doc/default-servlet.html
Comment 7 cnsilvan 2016-10-20 09:22:43 UTC
(In reply to Konstantin Kolinko from comment #6)
> I think that using compression with dynamic data (as in your configuration)
> is insecure. There are well-known CRIME and BREACH attacks. See
> 
> https://en.wikipedia.org/wiki/CRIME
> 
> Tomcat 8.5 and 9 can be configured to serve pre-compressed static files.
> This is configured with init-param "precompressed" of DefaultServlet.
> 
> http://tomcat.apache.org/tomcat-8.5-doc/default-servlet.html

thank u!
Comment 8 Eduardo Guadalupe Quintanilla 2016-11-09 00:50:48 UTC
I had a similar issue, in my case it worked after adding 
useSendfile="false".
Comment 9 Mark Thomas 2017-12-01 12:01:06 UTC
Fixed in:
- trunk for 9.0.3 onwards
- 8.5.x for 8.5.25 onwards
Comment 10 pc8888 2018-01-27 05:30:50 UTC
tomcat 8.5.27, this problem is still not fixed.

Removed <UpgradeProtocol className="org.apache.coyote.http2.Http2Protocol"/> and gzip works again.


<Connector .....		
compression="on" 
port="443" 
protocol="org.apache.coyote.http11.Http11AprProtocol"
......... >
<UpgradeProtocol className="org.apache.coyote.http2.Http2Protocol"/>
<SSLHostConfig
	........../>
	</SSLHostConfig>
</Connector>
Comment 11 Remy Maucherat 2018-01-27 06:26:55 UTC
Please do not reopen the report. Please post on the user list if you need further assistance.
Comment 12 Paul 2018-05-01 08:50:13 UTC
Hi 

I am trying to setup http2 with compression I agree this still does not work 

Not sure what this previous comment means
Please do not reopen the report. Please post on the user list if you need further assistance.

It still broken so why should we not reopen this ticket
Comment 13 Paul 2018-05-01 08:50:40 UTC
Hi 

I am trying to setup http2 with compression I agree this still does not work 

Not sure what this previous comment means
Please do not reopen the report. Please post on the user list if you need further assistance.

It still broken so why should we not reopen this ticket
Comment 14 Mark Thomas 2018-05-01 11:07:58 UTC
This feature is not broken. It was implemented at the end of last year and has been confirmed to be working as intended on multiple occasions since then.

To expand on Remy's previous comment.
Do not re-open this report means exactly that. Do not re-open this report.
This report is the enhancement request to add compression support to HTTP/2. That support has been added so this issue has been resolved. That you can't get it to work does not mean that the feature is broken. Given that:
- there are no relevant code changes since the feature was added
- it has been confirmed working multiple times
the more likely explanation is a configuration issue, not a bug.

Looking at the configuration provided in comment #10, that report at least is clearly a configuration issue.

Configuration issues are support questions and Bugzilla is not a support forum. Hence re-opening a bug in order to obtain configuration help is not acceptable behaviour in this community.

The correct place to seek configuration assistance is the users mailing list. Hence the second part of Remy's comment.