https://bz.apache.org/bugzilla/show_bug.cgi?id=69803
--- Comment #4 from gnirmalkuma...@gmail.com --- I wanted to add some more details from our application code in case it helps narrow this down. We use a custom GZIPFilter that buffers the response, compresses it, and then explicitly sets the Content-Length after compression, e.g.: response.setContentLength(bytes.length); response.getOutputStream().write(bytes); This worked fine through Tomcat 9.0.106. After upgrading to 9.0.107/108, we consistently see a mismatch between the Content-Length header and the actual bytes sent, resulting in net::ERR_CONTENT_LENGTH_MISMATCH in Chrome/Edge (but Firefox accepts it). I also noticed in the 9.0.107 release notes the change: Fix: Allow the default servlet to set the content length when the content length is known, no content has been written and a Writer is being used. (markt) Could this change be interacting with our filter’s explicit Content-Length handling and causing the mismatch? Additionally, in one edge case (when the gzip stream is effectively empty), our filter explicitly calls: response.setContentLength(0); Could that also be related under the newer behavior? -- 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
