Response.body is not a ReadableStream when constructed from a string or buffer.

[adamfaulkner-at]

Response.body should always be a ReadableStream, however, when a Response is constructed from something else, like a string or a Buffer, a `Buffer is used.

Reproduction

Steps to reproduce the behavior:

Using the REPL:

> var {Response} = require('node-fetch')
undefined
> var r = new Response('asdf');
undefined
> r.body
<Buffer 61 73 64 66>

Expected behavior

The spec says that the body is of type ReadableStream: https://fetch.spec.whatwg.org/#concept-body

So, I'd expect to receive a ReadableStream as the body, instead of a Buffer.

When I try this same snippet of code in a browser, I get the following:

> var r = new Response('asdf')
undefined
> r.body
ReadableStream { locked: false }

Your Environment

software	version
node-fetch	2.6.2
node	12.20.1
npm	6.14.10
Operating System	MacOS 11.6

Additional context

This is particularly problematic when I'm trying to test my code using fetch-mock, as the default behavior results in Buffers everywhere.

[jimmywarting]

This have always been like this in v2 due to lack of whatwg:stream support in NodeJS
So we never got around into implementing it and will probably never be supported in v2 as it's maintainess and bug fixes only now.

Beside, response.body have mostly always been a node:stream b/c of this. So what we have done in v3 is that we converted all the kinds of body it gets and normalizes it into a node:stream now (#924)
This makes the transition easier later when we make the switch from node:stream to whatwg:stream in v4

And it's going to be a major breaking change when we do.

So my advice: use v3 if you want to do any conversion hack with Response
the exception is: it will be a node:stream instead so best to use for await (let chunk of body)

[adamfaulkner-at]

Thanks for the response! It's totally fair that you're not going to fix this in v2.

We'll see about upgrading to v3 in the long term. I'll probably use a wrapper in my code to coerce everything into a stream when constructing a Response.

Putting aside compliance with the spec, It's not clear to me how Response is intended to be used given this bug. Is every function that accepts a Response supposed to inspect the type of the body to determine what to do with it?

[jimmywarting]

Putting aside compliance with the spec, It's not clear to me how Response is intended to be used given this bug.

The fetch api is built up by so many components that implementing everything at once have been tuff, constructing Responses on your own was not the first priority to get fixed. We didn't count on many doing it. but our goal now is to make a fully spec compliant api. #924 did solve half of the issue by converting/normalizing everything into a node:stream - next switch will be to use web streams instead

Is every function that accepts a Response supposed to inspect the type of the body to determine what to do with it?

For now since both whatwg & node streams are both async iterable that yields uint8arrays then the best option would be to use for..of:

for await (const uint8chunk of res.body) {
  // Do something with uint8array
}

Alternative if you always want the res.body to always be a node stream (even when v4 comes out) is to use stream.Readable.from(res.body) but that will be unnecessary in 3.x