Repository navigation
Uncaught exception on fetch (related to zlib, Z_BUF_ERROR) #43868
Description
Activity
/cc @nodejs/undici
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.0cc @ronag
Here is what that website is doing:
- the
http://www.sinlenoble.fr/solidarite/le-ccasURL issue a redirect tohttp://www.sinlenoble.fr/solidarite/le-ccas/. This redirect has an empty body but it wrongly reportscontent-encoding: gzip fetch()and undici try to eagerly read that body- an exception is thrown only on Node v18 (but not v16)
- the
Are we missing an error handler?
Are we missing an error handler?
Yes, I think in some case one of the pipeline refactoring is causing problems:
pipelineshould have added one for that.- added a commit that references this issue
on Jul 18, 2022 Here is our fix: nodejs/undici#1554
The problem is in undici and it's due to https://github.com/nodejs/node/pull/41954/files#diff-95c23fb6674af85f6f23a374851af6cccf58fb4617d73897df5078ba537a862cR243.
- added a commit that references this issue
on Jul 18, 2022 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
fetchcan 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 is560That's a different bug than this one, can you open a fresh issue and tag me?
- added a commit that references this issue
on Dec 26, 2022 - added a commit that references this issue
on Feb 27, 2024 - added 5 commits that reference this issue
on Apr 1, 2026
Version
18.6.0
Platform
Linux pop-os 5.17.15-76051715-generic #202206141358
165591911622.04~1db9e34 SMP PREEMPT Wed Jun 22 19 x86_64 x86_64 x86_64 GNU/LinuxSubsystem
undici
What steps will reproduce the bug?
Output:
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?
Additional information
This is not the only site that triggered this