https://bz.apache.org/bugzilla/show_bug.cgi?id=64403
Bug ID: 64403
Summary: HTTP/2 with compression does not unset Content-Length
Product: Tomcat 9
Version: 9.0.34
Hardware: PC
OS: Mac OS X 10.1
Status: NEW
Severity: normal
Priority: P2
Component: Connectors
Assignee: dev@tomcat.apache.org
Reporter: m...@normi.net
Target Milestone: -----
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.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
