Compressing response from /server/api in Nuxt 4.2.0

[twilit geyser]

In Nuxt 3 I previously used gzipSync from node:zlib to conditionally compress the responses for certain endpoints, but after upgrading it'll result in ERR_CONTENT_DECODING_FAILED on the client.

The content definitely looks like it's gzipped and the header is set.

Does anyone successfully compress responses from the /server/api endpoints in Nuxt 4?

[vivid badger]

Hi @twilit geyser. I'm kapa.ai, your friendly support bot. I will try to answer your question by searching through the knowledge base. :wave:

---

In Nuxt 4.2.0, there is a known issue when manually compressing responses (e.g., using gzipSync or similar) in server routes like /server/api. If you set the Content-Encoding header and send gzipped (or brotli) content, the client may encounter ERR_CONTENT_DECODING_FAILED. This happens because Nuxt (or more specifically, Nitro) may decompress the response internally but does not always update or remove the Content-Encoding header, leading to a mismatch: the client tries to decode already-decoded content, resulting in the error.

This issue has been reported by others, especially when using libraries or handlers that perform their own compression. It also affects proxied responses if the target server returns compressed content. A current workaround is to prevent the target from sending compressed responses by setting the Accept-Encoding header to an empty string in your proxy configuration, but this does not solve the problem for custom compression in your own handlers.

A fix is planned for a future Nuxt/CLI release, as referenced in the discussion:

This issue also occurs when using the devProxy: If the target returns compressed content, proxied responses break with net::ERR_CONTENT_DECODING_FAILED.
...
My current workaround:

export default defineNuxtConfig({
  nitro: {
    devProxy: {
      "/api": {
        ...
        headers: {
          "Accept-encoding": "", // force target to send uncompressed responses
        },
      },
    },
  },
});

this will be resolved in the next release of nuxt/cli via https://github.com/nuxt/cli/pull/1105
context: Github Issue #33598

In summary:
Currently, manually compressing responses in Nuxt 4.2.0 server routes is problematic and leads to client errors. The recommended approach is to avoid manual compression for now and rely on Nitro's built-in compression, or apply the mentioned workaround for proxies. A proper fix is expected in an upcoming release.

Note: you can ask me a follow up question by @ mentioning me again :speech_balloon: