Uncaught exception on fetch (related to zlib, Z_BUF_ERROR)

[coyotte508]

Version

18.6.0

Platform

Linux pop-os 5.17.15-76051715-generic #202206141358165591911622.04~1db9e34 SMP PREEMPT Wed Jun 22 19 x86_64 x86_64 x86_64 GNU/Linux

Subsystem

undici

What steps will reproduce the bug?

async function test() {
    const x = await fetch("http://www.sinlenoble.fr/solidarite/le-ccas");
    const y = await x.text();
}

test().then(() => process.exit(0), () => process.exit(1))

process.on("unhandledRejection", (r) => console.log("undhanled rejection", r))
process.on("uncaughtException", (r) => console.log("uncaught exception", r))

Output:

(node:18923) ExperimentalWarning: The Fetch API is an experimental feature. This feature could change at any time
(Use `node --trace-warnings ...` to show where the warning was created)
uncaught exception Error: unexpected end of file
    at Zlib.zlibOnError [as onerror] (node:zlib:189:17) {
  errno: -5,
  code: 'Z_BUF_ERROR'
}

How often does it reproduce? Is there a required condition?

Always, but it may go away if the remote site used for testing changes its code/configuration.

What is the expected behavior?

If there is an error with fetch, it should bubble inside the promise to be caught from the caller, instead of triggering an uncaught exception.

What do you see instead?

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

Additional information

This is not the only site that triggered this

[aduh95]

/cc @nodejs/undici

[mcollina]

I confirm this bug @coyotte508. Thanks for reporting!

@aduh95 I suspect this is a problem with some other Node.js v18 Zlib changes.

The following code runs perfectly on Node.js v16, but it fails on Node.js v18:

import { fetch } from 'undici'

const x = await fetch("http://www.sinlenoble.fr/solidarite/le-ccas");
const y = await x.text();

console.log(y)

node:events:491
      throw er; // Unhandled 'error' event
      ^

Error: unexpected end of file
    at Zlib.zlibOnError [as onerror] (node:zlib:189:17)
Emitted 'error' event on Gunzip instance at:
    at emitErrorNT (node:internal/streams/destroy:151:8)
    at emitErrorCloseNT (node:internal/streams/destroy:116:3)
    at process.processTicksAndRejections (node:internal/process/task_queues:82:21) {
  errno: -5,
  code: 'Z_BUF_ERROR'
}

Node.js v18.6.0

cc @ronag

[mcollina]

Here is what that website is doing:

1. the http://www.sinlenoble.fr/solidarite/le-ccas URL issue a redirect to http://www.sinlenoble.fr/solidarite/le-ccas/. This redirect has an empty body but it wrongly reports content-encoding: gzip
2. fetch() and undici try to eagerly read that body
3. an exception is thrown only on Node v18 (but not v16)

[ronag]

Are we missing an error handler?

[mcollina]

@ronag I'm fixing this on the undici side (it's the right behavior anyway), but we should investigate why this is happening for streams. There should be an error handler for that stream.

[mcollina]

Are we missing an error handler?

Yes, I think in some case one of the pipeline refactoring is causing problems:

https://github.com/nodejs/undici/blob/26f60b7b6e612bb831133d7f85914963d1955011/lib/fetch/index.js#L1962-L1986

pipeline should have added one for that.

[mcollina]

Here is our fix: nodejs/undici#1554

[mcollina]

The problem is in undici and it's due to https://github.com/nodejs/node/pull/41954/files#diff-95c23fb6674af85f6f23a374851af6cccf58fb4617d73897df5078ba537a862cR243.

[gbiryukov]

seeing same error but in different context, occurs when server respond with status 200 but sends duplicating headers (which is server bug but native browser fetch can live with it)

  < HTTP/2 200
  < access-control-allow-headers: accept, accept-encoding, authorization, content-type, dnt, origin, user-agent, x-csrftoken, x-requested-with, content-disposition, x-request-id, x-app-version
  < access-control-allow-methods: DELETE, GET, POST, PUT, PATCH, OPTIONS
  < access-control-allow-origin: *
  < access-control-expose-headers: x-request-id
  < access-control-max-age: 86400
+ < cache-control: private, max-age=0
+ < cache-control: private, no-cache, no-store
  < content-encoding: gzip
  < content-length: 105
  < content-type: application/json
  < date: Tue, 22 Nov 2022 23:50:00 GMT
  < expires: Tue, 22 Nov 2022 23:50:00 GMT
  < server: nginx
+ < strict-transport-security: max-age=31536000
+ < strict-transport-security: max-age=31536000

according to the discussion in theory problem also can be with content-length, in this case server returns length of gzipped body (which follows specs), original length is 560

[mcollina]

That's a different bug than this one, can you open a fresh issue and tag me?