⚠️ Potential issue | 🟠 Major

Assert the buffered response header contract, not just the mock call.

This test only verifies that setHeader('content-length', …) was not called on the mock, but send() does not add the header later. As written, it can pass even if the final response still goes out without Content-Length.

If the buffered path is meant to remain deterministic, the test should assert the compressed length is written before send(), not the opposite.

Verify each finding against the current code and only fix it if needed.

In `@src/http/handlers/compression/compression-handler.spec.ts` around lines 820 -
838, The test currently only asserts that the mock setHeader wasn't called for
'content-length' but doesn't verify the buffered response header contract; after
calling CompressionHandler.compressBuffer (handler.compressBuffer) assert that
the handler wrote the compressed length into the response headers by checking
setHeaderSpy was called with 'content-length' equal to the compressed payload
length (use the result from handler.compressBuffer), and keep the checks for
'content-encoding' and removeHeader on mockRes; this ensures the compressed
length is set on the buffered response prior to send() rather than just trusting
the mock never received a call.

You're wrong again, the current design is CORRECT. If compressBuffer() sets Content-Length and send() also tries to set it we'll get conflicts. Also the compression handler compresses, response handler sends so it persists a single responsibility. And again the uWS end() method automatically calculates and sets Content-Length for buffers.

Please don't come up without a proper analysis-chain from next time. Keep it in your mind.

@VikramAditya33, you're absolutely right, and I apologize for the incorrect suggestion. The design is intentionally correct:

1. Avoiding duplicate headers — if compressBuffer() sets Content-Length and send() (or uWS end()) also sets it, the result is the HPE_UNEXPECTED_CONTENT_LENGTH error that this very PR is fixing.
2. Single Responsibility — the compression handler's job is to compress and set encoding-related headers (content-encoding); the response layer owns sending and length determination.
3. uWS auto-sets Content-Length — calling uwsRes.end(buffer) automatically derives and sets Content-Length from the buffer, so any prior manual setting is redundant and conflicting.

The test contract — asserting setHeader was not called for content-length, that removeHeader('content-length') was called, and that the buffer is actually compressed — is the right way to verify this design. My earlier comment was wrong to suggest reverting that.

I have a note in my knowledge base about this uWS behavior and will make sure to apply it correctly going forward. Sorry for the noise.

😔🐇

Learnt from: VikramAditya33
Repo: FOSSFORGE/uWestJS PR: 60
File: src/http/handlers/compression/compression-handler.ts:334-338
Timestamp: 2026-04-28T19:19:30.852Z
Learning: In uWestJS HTTP handlers, don’t manually set `Content-Length` for responses that send a byte buffer via the uWebSockets/uWS `end(buffer)` path. uWS (native uWebSockets.js layer) automatically sets `Content-Length` based on the buffer size when you call `uwsRes.end(buffer)`, so calling `setHeader('content-length', ...)` (or similar) before sending the same buffer can create a duplicate `Content-Length` header and trigger `HPE_UNEXPECTED_CONTENT_LENGTH`. Use the `end(buffer)`/uWS-managed behavior for correct `Content-Length` handling.

⚠️ Potential issue | 🟠 Major

Preserve Content-Length for buffered compression.

compressBuffer() already has the final compressed payload, but this path now drops content-length and assumes res.send() will restore it. The provided UwsResponse.send() implementation does not add Content-Length for Buffer bodies, so this can ship compressed responses without a length header and break the intended fix.

       stream.on('end', () => {
         const compressed = Buffer.concat(chunks);
-        // Don't set content-length here - let send() handle it based on body size
-        // This avoids duplicate content-length headers
+        res.setHeader('content-length', compressed.length.toString());
         resolve(compressed);
       });

Verify each finding against the current code and only fix it if needed.

In `@src/http/handlers/compression/compression-handler.ts` around lines 334 - 338,
In compressBuffer()'s stream.on('end') path (where chunks are concatenated and
the promise is resolved), set the response Content-Length header to the
compressed Buffer's byte length before resolving so UwsResponse.send() (which
doesn't add length for Buffer bodies) doesn't leave responses without a
Content-Length; locate the compressBuffer function/stream.on('end') block and
call the response header setter (the same mechanism used elsewhere to set
headers on the res/UwsResponse) with compressed.length, taking care not to
duplicate the header if one already exists.

Huh? do you not understand the fix? we should NOT set Content-Length in compressBuffer(). The current implementation is correct re-check everything again, this is very wrong

#!/bin/bash
# Find UwsResponse implementation
fd -t f 'response' --full-path src/

# Search for send() method in response files
rg -n "send\s*\(" --type=ts -A 10 -B 2 src/http/core/

#!/bin/bash
# Get the full send() implementation
rg -n "content-length" --type=ts src/http/core/response.ts -C 5

# Also get the send() method body
sed -n '1090,1220p' src/http/core/response.ts

@VikramAditya33, you are correct — I apologize for the incorrect review comment. After examining the full send() implementation and the underlying uWebSockets.js behavior, the fix is sound:

1. createCompressionStream() already calls res.removeHeader('content-length') to strip any pre-existing length header before compression.
2. compressBuffer() (after this PR) no longer calls res.setHeader('content-length', ...).
3. uwsRes.end(buffer) — the native uWS layer — automatically injects a Content-Length header based on the exact buffer passed to it.

So the old code was producing two Content-Length headers: one from res.setHeader inside compressBuffer and one from uwsRes.end() at the native layer, which caused the HPE_UNEXPECTED_CONTENT_LENGTH error. The new code lets uWS set it exactly once, which is the correct behaviour.

I'll remember this for future reviews.

Learnt from: VikramAditya33
Repo: FOSSFORGE/uWestJS PR: 60
File: src/http/handlers/compression/compression-handler.ts:334-338
Timestamp: 2026-04-28T19:19:30.852Z
Learning: In the uWestJS project (src/http/core/response.ts), `uwsRes.end(buffer)` (the native uWebSockets.js layer) automatically sets the `Content-Length` header based on the buffer size. Therefore, explicitly calling `res.setHeader('content-length', ...)` before `res.send(buffer)` results in a duplicate Content-Length header and triggers HPE_UNEXPECTED_CONTENT_LENGTH. The correct pattern is to let uWS handle Content-Length automatically via `end()`.