Make response body streams readable byte streams

[domenic]

Depends on whatwg/streams#1130. Closes #267.

• At least two implementers are interested (and none opposed):
  • I think most implementers have expressed interest, but I'm not sure it's on anyone's near-term plan to implement this, so we may want to leave this PR open for a while...
• Tests are written and can be reviewed and commented upon at:
  • TODO
• Implementation bugs are filed:
  • Chrome: TODO
  • Firefox: TODO
  • Safari: TODO

(See WHATWG Working Mode: Changes for more details.)

---

Preview | Diff

[MattiasBuelens]

We're also blocked by whatwg/streams#1114. When "clone a body" tees a stream, the result must also be a readable byte stream.

[annevk]

There is an existing problem that this needs to queue a task. I can PR that, but this will have to be rebased then.

[domenic]

Re-reading this section it feels like most of the section needs to take place in a task. (I.e., everything dealing with stream.) Just the reading of the bytes from the network needs to be done in parallel.

[annevk]

I personally prefer not using commas before and if there are only two "simple" things.

What I don't understand here is that you still get a fresh view if the BYOB view cannot be written into due to its size. Wouldn't an error or request for a new view be more appropriate? If the idea is to avoid allocations presumably you would not want such allocations to nevertheless happen silently sometimes?

[annevk]

Suggested change

	non-null, and <var>bytes</var>'s <a for="byte sequence">length</a> is less than
	non-null and <var>bytes</var>'s <a for="byte sequence">length</a> is less than

[annevk]

Suggested change

	<a for=ReadableStream>current BYOB request view</a>, and <a for=ArrayBufferView>write</a>
	<a for=ReadableStream>current BYOB request view</a> and <a for=ArrayBufferView>write</a>

[domenic]

What I don't understand here is that you still get a fresh view if the BYOB view cannot be written into due to its size. Wouldn't an error or request for a new view be more appropriate? If the idea is to avoid allocations presumably you would not want such allocations to nevertheless happen silently sometimes?

Interesting. This is the first time we're hearing this feedback.

I'm not sure how these ideas would work. If you ask for a 1 KiB buffer, and Fetch is unable to restrict what it pulls from the network to less than 16 KiB, you'd get an error... and then what would you do? At that point Fetch has 16 KiB in memory in a new buffer. The only things we can do are:

• Give you the first 1 KiB of the 16 KiB buffer, and next time you ask give you (the requested portion of) the remaining 15 KiB; or
• Give you the entire 16 KiB buffer anyway.

The first option is more friendly toward people who are using BYOB readers to read specific numbers of bytes, e.g. when parsing a protocol, and so is what we chose.

I don't quite understand what you mean by "request for a new view" as opposed to error.

[annevk]

We discussed this further in https://matrixlogs.bakkot.com/WHATWG/2021-07-19#L105-L119. I'm a bit surprised at all the transfers, but I suppose that is to avoid exposing races.

[domenic]

Superseded by #1593; somehow I forgot this existed when reviewing that :)