https://bz.apache.org/bugzilla/show_bug.cgi?id=64073
Bug ID: 64073
Summary: CompressionConfig does not clear Content-Length header
if already set
Product: Tomcat 9
Version: 9.0.30
Hardware: PC
OS: Mac OS X 10.1
Status: NEW
Severity: normal
Priority: P2
Component: Connectors
Assignee: dev@tomcat.apache.org
Reporter: bclo...@pivotal.io
Target Milestone: -----
This issue happens in the following case:
1. the connector is configured to compress HTTP responses
2. an application sets the following response header "Content-Length: 3000"
3. the CompressionConfig class checks that the request+response qualify for
compression
4. if they do, the response content length is set to "-1" (see:
https://github.com/apache/tomcat/blob/740e15e858993221fab4cbe025f408333255b785/java/org/apache/coyote/CompressionConfig.java#L326)
but the actual "Content-Length" header is never cleared.
5. the HTTP response has then both "Content-Length: 3000" and
"Transfer-Encoding: chunked" headers
It seems to be against the HTTP spec and is actively enforced by popular HTTP
clients, see
https://github.com/netty/netty/commit/8494b046ec7e4f28dbd44bc699cc4c4c92251729
--
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
