Bug 64431

Summary:	Enable response compression by default
Product:	Tomcat 10	Reporter:	Craig <candrews>
Component:	Connectors	Assignee:	Tomcat Developers Mailing List <dev>
Status:	RESOLVED WONTFIX
Severity:	enhancement	CC:	candrews
Priority:	P2
Version:	unspecified
Target Milestone:	------
Hardware:	PC
OS:	Linux

Description Craig 2020-05-13 14:59:51 UTC

In Tomcat 10, I believe that compression should be enabled by default for the HTTP connector. In other words, change the default value of Connector#compression from "off" to "on" as documented at:
https://tomcat.apache.org/tomcat-10.0-doc/config/http.html

I don't believe that there's any (significant) downside to enabling compression by default, and I believe doing so aligns with the best experience for Tomcat's users. Years ago, the extra CPU consumption of compression may have been a concern, but I think the time for that worry has passed - the reduced network transfer is far more important for the almost all situations. The default values of "compressionMinSize", "compressibleMimeType", and "noCompressionUserAgents" ensure that compressing is done in a useful, safe way.

Comment 1 Remy Maucherat 2020-05-13 15:17:30 UTC

I'd likely vote no to this proposal. It is not a bug, anyway.

Comment 2 Craig 2020-05-13 15:27:58 UTC

(In reply to Remy Maucherat from comment #1)
> I'd likely vote no to this proposal.

For posterity, why not?

>It is not a bug, anyway.

I filed it as an "enhancement" not a bug - was that not the right thing? If not, I apologize!

Comment 3 Christopher Schultz 2020-05-13 17:00:16 UTC

(In reply to Craig from comment #2)
> (In reply to Remy Maucherat from comment #1)
> > I'd likely vote no to this proposal.
> 
> For posterity, why not?

CRIME, BREACH.

I'm in favor of HTTP compression for static files (e.g. CSS, javascript, maybe SVG), but not for dynamically-generated content.

Comment 4 Craig 2020-05-13 19:30:08 UTC

> 
> CRIME, BREACH.
> 
CRIME is a vulnerability that applies to TLS compression - I'm not suggesting here that TLS compression be used (it was actually removed in TLS 1.3). So I don't believe CRIME is relevant.

BREACH is relevant... There are mitigations (such as SameSite cookies), but there's no guarantee that applications running Tomcat have implemented them. So I see your point :)

Roes Tomcat have any mitigations for BREACH in place today? It seems Tomcat doesn't do any kind of random response padding (such as with empty response chunks or randomly sized response chunking).

Comment 5 Craig 2020-05-29 01:28:57 UTC

I don't think BEAST is still relevant, see https://blog.qualys.com/ssllabs/2013/09/10/is-beast-still-a-threat for a details explanation.

So I still suggest that Tomcat change the default to enable HTTP response compression.

Comment 6 Mark Thomas 2020-06-09 20:21:46 UTC

I have no strong view either way (although I am open to being persuaded one way or the other). I've asked the user community for their views.

Comment 7 Mark Thomas 2020-06-15 18:55:10 UTC

There wasn't much community feedback, but the feedback that there was was that it would be best to leave the compression setting as is. Reasons mentioned included:
- interaction with some clients (still!)
- behaviour behind a reverse proxies generally
- interaction with CDNs specifically

I am therefore resolving this as WONTFIX.