Request/Response constructor with a ReadableStream (not ReadableByteStream)

[tyoshino]

The original question was raised by @yutakahirano

• https://github.com/whatwg/streams/issues/362#issuecomment-112041942
• @domenic's reply https://github.com/whatwg/streams/issues/362#issuecomment-112245733

What we should do when the Request/Response constructor receive a ReadableStream (not ReadableByteStream)?

[domenic]

Probably the most straightforward thing to do is create some sort of wrapper. What type though? Here are three ideas:

• A fake ReadableByteStream implementation whose methods just delegate to the wrapped RS, maybe adding some type checking and/or conversion.
  • This is harder to do if ReadableByteStream is written in JS, but easy to do in C++/IDL bindings
  • Speccing this will either require lots of hand-waving, or will be intrusive to the ReadableByteStream spec, or we will have to spec one of the alternatives and then implementations could use this strategy anyway
• A customized underlying byte source that delegates to the wrapped RS (with type validation).
  • Probably cleanest conceptually
  • Unsure how complicated to spec/implement---would have to write it out.
• Pipe through a type-validating identity transform stream, and then Request/Response expose the readable end

In all cases the result will be not-great. The resulting ReadableByteStream will be "fake". Using its BYOB reader will be slow, not fast.

---

Another alternative would be to allow the body option and .body property to be ReadableStreams. If the author passes one in, we just allow that to be the .body. Later we can error during upload if the chunks are not binary data.

This means that sometimes you will get a Request/Response whose .body does not have a a .getByobReader(). That has pluses and minuses. It means you won't get "false advertising" from a fake RBS. But it also makes writing generic Request/Response processing code harder. But maybe that is good? We fail early if you're doing a stupid thing using your generic processing code?

There's a variant on this where we allow any object at all and just try to use its public API like we would a readable stream. But I think the appetite for that is low, understandably.

---

I don't feel too strongly here.

[domenic]

I think the original concern here is taken care of. However, we still have the potential for responses to have ReadableStreams that contain non-Uint8Array chunks. That means anything on the platform that consumes a Response might in theory have to deal with this.

Right now in practice that is a restricted problem. The only thing that consumes an author-generated Response is service worker's respondWith, which @yutakahirano is taking care of in https://github.com/slightlyoff/ServiceWorker/pull/934.

My inclination is to wait until we have a couple more examples of this pattern and then see if we want a more general solution.

[annevk]

This is superseded by https://github.com/whatwg/fetch/issues/450 I think.