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: dev@tomcat.apache.org Reporter: gr.grzy...@gmail.com 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: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org