Bug ID: 67678
           Summary: Content-Encoding: gzip with Content-Length header
           Product: Tomcat 9
           Version: 9.0.81
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: critical
          Priority: P2
         Component: Connectors
  Target Milestone: -----

This commit

// 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

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:
For additional commands, e-mail:

Reply via email to