fix: Drop a handler's Content-Length when a stream is compressed

A compressed stream goes out chunked, and the JDK's chunked branch sets
Transfer-encoding without clearing a Content-Length the handler put on
the response — so both framing headers reached the wire together. Before
this branch a sized stream passed its real length, which made the JDK
overwrite that header, so the conflict is new.

The declared length also describes the uncompressed body, so it is wrong
on the wire regardless of framing. renderEmpty already removed it for
the same reason; renderStream now does too.

Author: thced

src/main/java/com/retailsvc/http/internal/ResponseRenderer.java

@@ -82,6 +82,8 @@ private void renderStream(
     boolean gzip = shouldCompress(exchange, headers, status, contentType, declared);
     if (gzip) {
       headers.set(CONTENT_ENCODING, GZIP);
+      // The coded body goes out chunked, and the JDK leaves a handler-set length in place there.
+      headers.remove(CONTENT_LENGTH);
     }
     exchange.sendResponseHeaders(status, gzip ? CHUNKED : Math.max(declared, CHUNKED));
     try (OutputStream out =

src/test/java/com/retailsvc/http/internal/ResponseRendererTest.java

@@ -397,6 +397,21 @@ void skipsCompressionOnStreamWhenHandlerAlreadySetContentEncoding() throws IOExc
     assertThat(sink.toByteArray()).isEqualTo(payload);
   }
 
+  @Test
+  void stripsHandlerContentLengthWhenStreamIsCompressed() throws IOException {
+    acceptsGzip();
+    byte[] payload = largeText();
+
+    renderer.render(
+        exchange,
+        Response.stream(HTTP_OK, payload.length, TEXT, out -> out.write(payload))
+            .withHeader("Content-Length", String.valueOf(payload.length)));
+
+    assertThat(responseHeaders.getFirst(CONTENT_ENCODING)).isEqualTo("gzip");
+    assertThat(responseHeaders.getFirst("Content-Length")).isNull();
+    assertThat(length.get()).isZero();
+  }
+
   private void acceptsGzip() {
     requestHeaders.add("Accept-Encoding", "gzip, deflate, br");
   }