The new Response(body) constructor can accept multiple formats, such as ArrayBuffer or a ReadableStream.
Node.js (undici) additionally allows async iterators (nodejs/undici#3540). Since Node.js Readable streams also implement it, using a Node.js readable stream as the body is kinda possible too.
Some libraries (like React’s renderToPipeableStream) return an object that only implements .pipe instead of a full Node.js readable stream, and this no longer works correctly with new Response since constructors since it is not an iterable.
The srvx Node adapter (only when using fast path mode via FastResponse) has a detection that allows piping directly to the Node response stream, but there are other edge cases like #177 that when cloning we also need this normalization.
So far srvx (node adapter utils, FastResponse) and h3 allow pipables but we might want to drop support for this non standard object and instead require users to explicitly use one of the supported body types.
The new Response(body) constructor can accept multiple formats, such as
ArrayBufferor a ReadableStream.Node.js (undici) additionally allows async iterators (nodejs/undici#3540). Since Node.js Readable streams also implement it, using a Node.js readable stream as the body is kinda possible too.
Some libraries (like React’s renderToPipeableStream) return an object that only implements
.pipeinstead of a full Node.js readable stream, and this no longer works correctly withnew Responsesince constructors since it is not an iterable.The srvx Node adapter (only when using fast path mode via
FastResponse) has a detection that allows piping directly to the Node response stream, but there are other edge cases like #177 that when cloning we also need this normalization.So far srvx (node adapter utils, FastResponse) and h3 allow pipables but we might want to drop support for this non standard object and instead require users to explicitly use one of the supported body types.