Cloudflare Header Modification in 204 Responses Causes API SC Failures

Wappler Version: 6.8
Operating System: Windows 11/Ubuntu
Server Model: Node.js
Database Type: Postgres
Hosting Type: Docker


Expected Behavior

For API responses with a 204 No Content status:

  • The Content-Length header should either be omitted or set to 0.
  • Headers related to body content or compression (e.g., Content-Encoding) should not be present.

Actual Behavior

When a 204 No Content response is proxied through Cloudflare, it modifies the headers by adding a Content-Encoding: gzip header. This behavior causes issues in the current api.js implementation of the Server Connect module used for API Connect calls. Specifically, the module attempts to decompress the response, leading to errors since the response body is empty.

Error Details

Error: unexpected end of file
    at Zlib.zlibOnError [as onerror] (node:zlib:189:17)
    at Zlib.callbackTrampoline (node:internal/async_hooks:128:17) {
  errno: -5,
  code: 'Z_BUF_ERROR'
}

Steps to Reproduce

  1. Add an API Connect step and configure it to call a URL proxied by Cloudflare that returns a 204 No Content response.
  2. Make a request to the API.
  3. Observe the response headers, noting the inclusion of Content-Encoding: gzip and Content-Length.
  4. Notice the decompression error due to the absence of a response body, resulting in gateway timeout.

Suggested Fix

Adjusting the response handling logic in lib/modules/api.js to bypass decompression for empty responses. The following code snippet addresses the issue:

if (res.headers['content-length'] === '0' || !res.headers['content-length']) {
    resolve({
        status: res.statusCode,
        headers: res.headers,
        data: ''
    });
    return;
}

This ensures decompression is skipped for responses without a body, preventing errors like Z_BUF_ERROR and avoiding subsequent 520 Gateway Timeout errors.

3 Likes

If the content-length is 0 then we could indeed skip the whole data parsing and return the empty body. A missing content-length header doesn't mean it is empty, it is often missing with streaming content where the content length is not known at start of the stream. The condition should probably only contain the content-length === '0' check and/or check for statusCode 204.

1 Like

Hi @patrick,

I agree. It makes sense to handle cases where content-length is explicitly 0 or the statusCode is 204, while ensuring we don't misinterpret missing headers from streaming content.

Could you please incorporate this fix in the upcoming release or as part of an inline patch?

Can see this is resolved now via Asset updates.

Thanks @patrick.!! :smiley:

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.