Bug 64403 - HTTP/2 with compression does not unset Content-Length
Summary: HTTP/2 with compression does not unset Content-Length
Alias: None
Product: Tomcat 9
Classification: Unclassified
Component: Connectors (show other bugs)
Version: 9.0.34
Hardware: PC Mac OS X 10.1
: P2 normal (vote)
Target Milestone: -----
Assignee: Tomcat Developers Mailing List
Depends on:
Reported: 2020-05-01 16:54 UTC by Mike Noordermeer
Modified: 2020-05-04 20:57 UTC (History)
1 user (show)


Note You need to log in before you can comment on or make changes to this bug.
Description Mike Noordermeer 2020-05-01 16:54:15 UTC
When applying GZIP compression, no Content-Length header should be set as the response size cannot be determined in advance. CompressionConfig.useCompression therefore calls response.setContentLength(-1).

The behaviour I am seeing, is that with Http2 and GZIP compression, I still get a Content-Length header, but for the original response size. This causes all kinds of weird quirks in browsers when it comes to caching resources (as the browser cannot reliably determine the resource size, it will no cache the resource).

The Http11Processor.prepareResponse() method first sets up compression, and then sets the Content-Length. The HTTP2 StreamProcessor.prepareResponse() call StreamProcessor.prepareHeaders(...) and that one does this stuff in the wrong order: it first sets the content-length header and then sets up compression.
Comment 1 Mark Thomas 2020-05-04 20:21:50 UTC
Thanks for the report. I'm surprised the clients didn't reject the response entirely.

Fixed in:
- master for 10.0.0-M5 onwards
- 9.0.x for 9.0.35 onwards
- 8.5.x for 8.5.55 onwards
Comment 2 Mike Noordermeer 2020-05-04 20:57:30 UTC
Thanks for the fix!

Yes, I was wondering about that too, IIRC the spec requires clients to drop such invalid responses.