https://bz.apache.org/bugzilla/show_bug.cgi?id=67678
Bug ID: 67678
Summary: Content-Encoding: gzip with Content-Length header
present
Product: Tomcat 9
Version: 9.0.81
Hardware: PC
OS: Linux
Status: NEW
Severity: critical
Priority: P2
Component: Connectors
Assignee: [email protected]
Reporter: [email protected]
Target Milestone: -----
This commit
https://github.com/apache/tomcat/commit/eca8f44c766c380c0d117dc7eca9d933aea71c38
moved:
// Check for compression
boolean useCompression = false;
if (entityBody && sendfileData == null) {
useCompression = protocol.useCompression(request, response);
}
fragment to after "Content-Length" header is set in the response.
However protocol.useCompression() call has side effect -
org.apache.coyote.CompressionConfig#useCompression() calls
org.apache.coyote.Response#setContentLength(-1).
So eca8f44c766c380c0d117dc7eca9d933aea71c38 should be reverted.
I detected the problem with my Pax Web integration tests where gzip encoding is
forced (compression="force" on <Connector>)
In Tomcat 9.0.80 I had these response headers:
HTTP/1.1 200
Set-Cookie: JSESSIONID=7B83AADC72EA77BFCF307D24EE588129; Path=/war; HttpOnly
vary: accept-encoding
Content-Encoding: gzip
Content-Type: text/html;charset=ISO-8859-1
Transfer-Encoding: chunked
Date: Wed, 11 Oct 2023 08:02:04 GMT
Connection: close
while in 9.0.81 it's:
HTTP/1.1 200
Set-Cookie: JSESSIONID=FC38F619FC830EFD036FA17C39D68942; Path=/war; HttpOnly
Content-Type: text/html;charset=ISO-8859-1
Content-Length: 313
vary: accept-encoding
Content-Encoding: gzip
Date: Wed, 11 Oct 2023 07:57:36 GMT
Connection: close
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
