src/http/core/response.ts (2)

852-878: ⚠️ Potential issue | 🟡 Minor | ⚡ Quick win

stream() flushes pending chunks before deciding to compress — produces a mixed-encoding response.

this.flushChunks() runs unconditionally inside the leading atomic(...) (Lines 858-864), which writes any bytes previously buffered by write() calls directly to uWS (and sends headers on the first chunk via writeHead()). Only after that do we evaluate createCompressionStream(...). If a caller did res.write(...); res.stream(readable) with compression enabled, the early bytes go on the wire as plaintext, the compression stream then takes over for the rest, and the client receives a body it cannot decode (and content-encoding either can no longer be set or is set on a partially-plaintext response).

Either decide on compression before flushing (and route any pre-buffered chunks through the compression stream), or document/enforce that write() is not supported before a compressed stream().

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@src/http/core/response.ts` around lines 852 - 878, The stream() method
currently flushes buffered write() chunks via flushChunks() before determining
compressibility, causing mixed-encoding responses; change the order so you call
compressionHandler.createCompressionStream(this.req, this) before invoking
atomic()/flushChunks(), and if a compression stream is returned route any
buffered chunks (from flushChunks()/internal buffer) through the compression
stream and into _streamCompressed(readable, compressStream) rather than writing
them directly to uWS; if no compression stream is returned keep the existing
atomic()/flushChunks() path and call _streamFromReadable(readable, totalSize).

---

1224-1272: ⚠️ Potential issue | 🟠 Major | ⚡ Quick win

send() compression error path can leak corrupt headers and crash the fallback.

Three concrete problems in the compression branch:

1. The .catch(() => { ... }) swallows the original error with no logging, which makes diagnosing real-world compression failures (corrupt stream, brotli not available, etc.) very hard. At minimum log via the configured logger.
2. By the time compressBuffer() rejects, compressionHandler may already have mutated the response (e.g., set content-encoding: gzip or vary: accept-encoding). The fallback then writes the literal plaintext 'Internal Server Error' while content-encoding: gzip is still set, so the client sees a corrupt body. Reset/strip compression-related headers (content-encoding, and any pre-set content-length) before sending the 500.
3. this.status(500) throws if headers have already been sent in the meantime (e.g., concurrent write or the compression handler partially writing). Guard with !this._headersSent like other error paths in this file do.

🛠️ Suggested adjustment

-      this.compressionHandler
-        .compressBuffer(this.req, this, bodyBuffer)
-        .then((compressed) => this._sendInternal(compressed))
-        .catch(() => {
-          this.sending = false;
-          if (!this.finished && !this.aborted) {
-            this.status(500);
-            // Bypass compression for error response to avoid recursion
-            this._sendInternal('Internal Server Error');
-          }
-        });
+      this.compressionHandler
+        .compressBuffer(this.req, this, bodyBuffer)
+        .then((compressed) => this._sendInternal(compressed))
+        .catch((err) => {
+          // Log so failures aren't silently masked
+          // (use the framework logger if you have one wired in here)
+          // eslint-disable-next-line no-console
+          console.error('Response compression failed; falling back to 500', err);
+          this.sending = false;
+          if (this.finished || this.aborted || this._headersSent) return;
+          // Drop any headers the compression handler may have set so the
+          // plaintext fallback isn't tagged as gzip/br/etc.
+          this.removeHeader('content-encoding');
+          this.removeHeader('content-length');
+          this.status(500);
+          this._sendInternal('Internal Server Error');
+        });

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@src/http/core/response.ts` around lines 1224 - 1272, The compression error
path in send() (where compressionHandler.compressBuffer(...) .catch(...))
swallows the error, can leave compression headers set and calls this.status(500)
unsafely; update the catch to log the original error via the configured logger,
clear any compression-related headers (at least 'content-encoding' and
'content-length' and optionally 'vary') before sending the fallback body, guard
the this.status(500) call with if (!this._headersSent) to avoid throwing, and
ensure this.sending is reset appropriately before calling
_sendInternal('Internal Server Error') so state remains consistent (refer to
methods/properties: send, compressionHandler.compressBuffer, _sendInternal,
this.status, this._headersSent, this.sending).