Affects: 5.3.7

Upgraded spring from 5.2.15 to 5.3.7.

In 5.3.7 While trying to hit an api with Accept-encoding as gzip. I get a response with header Content-length set to a value. The content length is set to original file size and since the output is compressed the output file size is lesser than the original value and so the server will try to download the entire size specified in content-length which the response wont send and the request will be waiting for the content to download till the keep-alive time and then terminates. We are able to get the response but it is causing a latency issue. The response header should have transfer-encoding set to chunked.

In 5.2.15.RELEASE While trying to hit an api with Accept-encoding as gzip. I get a response with header Transfer-encoding set to "chunked" instead of the header content-length. So the output is delivered in chunks and the connection closes rightly.

Comment From: bclozel

To be able to help you, we need some more information. Please provide a complete, minimal example (something we can unzip or git clone) that we can run to reproduce the problem.

Comment From: venkatsaijanumpally

In 5.2.15

GET http://localhost:7070/employee/static/openapi/swagger-ui-standalone-preset.js

Request Headers Accept-Encoding: gzip User-Agent: PostmanRuntime/7.26.8 Accept: / Postman-Token: 4ebc3cc7-0978-4509-8010-8901c627f997 Host: localhost:7070 Connection: keep-alive

Response Headers Vary: Accept-Encoding Vary: Origin Vary: Access-Control-Request-Method Vary: Access-Control-Request-Headers Last-Modified: Thu, 17 Jun 2021 19:43:00 GMT Accept-Ranges: bytes Content-Encoding: gzip X-Content-Type-Options: nosniff X-XSS-Protection: 1; mode=block Cache-Control: no-cache, no-store, max-age=0, must-revalidate Pragma: no-cache Expires: 0 X-Frame-Options: DENY Content-Type: application/javascript Transfer-Encoding: chunked Date: Mon, 21 Jun 2021 07:17:05 GMT Keep-Alive: timeout=20 Connection: keep-alive

### In 5.3.7

GET http://localhost:7070/employee/static/openapi/swagger-ui-standalone-preset.js

Request Headers Accept-Encoding: gzip User-Agent: PostmanRuntime/7.26.8 Accept: / Postman-Token: 0dcc7029-b351-4522-a061-64c42d02eef1 Host: localhost:7070 Connection: keep-alive

Response Headers Vary: Accept-Encoding Vary: Origin Vary: Access-Control-Request-Method Vary: Access-Control-Request-Headers Last-Modified: Thu, 17 Jun 2021 19:43:00 GMT Accept-Ranges: bytes Content-Encoding: gzip X-Content-Type-Options: nosniff X-XSS-Protection: 1; mode=block Cache-Control: no-cache, no-store, max-age=0, must-revalidate Pragma: no-cache Expires: 0 X-Frame-Options: DENY Content-Type: application/javascript Content-Length: 440694 Date: Mon, 21 Jun 2021 06:25:21 GMT Keep-Alive: timeout=20 Connection: keep-alive

In 5.3.7 we are getting Content-Length: 440694 instead of transfer-encoding.

Comment From: bclozel

Thanks for the additional information. Did you forget to provide a link to your sample application?

Comment From: venkatsaijanumpally

No, I cannot provide that.

Comment From: snicoll

@venkatsaijanumpally we're not asking you to share your actual application but a small sample you'd build that reproduces the problem.

Comment From: spring-projects-issues

If you would like us to look at this issue, please provide the requested information. If the information is not provided within the next 7 days this issue will be closed.

Comment From: bclozel

At this point, we didn't find anything on our side that could explain the problem you're seeing. If anything, we recently fixed an issue that was causing duplicate Content-Length headers, so definitely not adding more.

Are you by any chance using our Resource Handling support and the GzipResourceResolver implementation here? Are those JS files already gzipped on disk and served as is?

How did you enable content compression in your application? What's in charge of compressing the HTTP responses? Of course, a minimal sample application would help us pinpoint the exact problem.

Thanks!

Comment From: venkatsaijanumpally

After debugging Spring code found out that the issue is happening because in Spring newer release ServletServerHttpResponse.java: writeHeaders method has added following code-

long contentLength = this.getHeaders().getContentLength(); if (contentLength != -1L) { this.servletResponse.setContentLengthLong(contentLength); } Because of this code, Content-Length header gets added in the response.

Comment From: bclozel

@venkatsaijanumpally Why isn't this code snippet invalid? Shouldn't Framework write the Content-Length header if that value has been set by the application? The code you're pointing at has been changed to fix the duplicate Content-Length headers, as underlined previously, see #26330.

Could you answer the questions in my previous comment?