Bug 62072

Summary: Add support for request compression
Product: Tomcat 9 Reporter: Rafael Winterhalter <rafael.wth>
Component: CatalinaAssignee: Tomcat Developers Mailing List <dev>
Status: NEW ---    
Severity: enhancement CC: andy.wilkinson, matafagafo
Priority: P2    
Version: unspecified   
Target Milestone: -----   
Hardware: PC   
OS: Linux   

Description Rafael Winterhalter 2018-02-01 17:56:32 UTC 
Tomcat does not currently support compression of requests sent to the server, i.e. requests with a Content-Encoding header.

It is a bit unclear from the specification if this is a part of HTTP but it is mentioned that status code 415 should be sent if a request is sent in an unknown encoding: https://tools.ietf.org/html/rfc7231#section-6.5.13

Other servers such as Undertow (https://issues.jboss.org/browse/UNDERTOW-920) have added it and Jetty is about to add it (https://github.com/eclipse/jetty.project/issues/382).

It would be great if Tomcat could add the same support.
Comment 1 Eugène Adell 2019-07-08 17:12:21 UTC 
Compression can be used with both Content-Encoding or Transfer-Encoding, in practice we see Transfer-Encoding much more than the other as the compression is delegated to the web server, not to the filesystem itself or DB storage (from my understanding Content-Encoding means the ressource is itself in compressed state).

Compression is not always a good idea : it was removed from TLS (1.3) after BREACH/CRIME since it can compromise client-side, and even when SSL is not used it can lead to serious problems compromising server-side (such as https://en.wikipedia.org/wiki/Zip_bomb )

However, I've seen big performance improvements on servers sending compressed data when the homepage is heavy in text/javascript (10 mB)
Comment 2 Christopher Schultz 2019-07-08 22:10:20 UTC 
When the request entity is compressed, the encoding should be specified in the Content-Encoding header, not the Transfer-Encoding header.

Transfer-Encoding could also certainly be supported if Content-Encoding is also supported.

This seems like the kind of thing that SHOULD be supported if possible. Using e.g. gzip to upload data does give a good performance boost. Chips are fast these days -- much faster than data pipes.

[1] https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Encoding
[2] https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Transfer-Encoding
Comment 3 Nicolò Boschi 2020-04-15 16:04:34 UTC 
I'd like to work on that, could someone tell me where the changes need to be
made?
This is my first issue on tomcat
Comment 4 Mark Thomas 2020-04-15 16:43:02 UTC 
Have a look at org.apache.coyote.http11.filters under java/

If I was going to do this I'd Look at how ChunkedInputFilter and ChunkedOutputFilter are used compared to GzipOutoutFilter and use that as a basis for a new GzipInputFilter class and associated plumbing.

This will definitely need lots of test cases. See the equivalent package under test/
Comment 5 Matafagafo 2021-02-23 18:02:18 UTC 
Today I tried to use Apache HttpClient GzipCompressingEntity (https://hc.apache.org/httpcomponents-client-4.5.x/current/httpclient/apidocs/org/apache/http/client/entity/GzipCompressingEntity.html) to send compressed requests to my Web APP running on Tomcat 9, and I stopped here :-(