Re: [streams] Getting errored/closed reader, Auto-releasing reader, Forcible cancel() on a stream (#297)

We just had more discussion about cancelling fetch(). In https://github.com/whatwg/streams/issues/297#issuecomment-78954538, Yutaka meant that we should have some method to stop receiving HTTP response body. It could be any of res.cancel(), res.body.cancel() and reader.cancel(). He thought having three points is bad and wondered what we should have.

Sorry, I forgot but `text()`, `json()`, etc. are on `res`, not `res.body`. I'm fine with having a `.cancel()` on `res` to address this issue. It makes the stream errored by terminating the ongoing fetch algorithm.

I'm also fine with your (Domenic's) canceller approach.

Regarding the Fetch API, we also need a method to terminate the fetch algorithm while the promise is not yet fulfilled (response headers are not yet available). So, my gut feeling is that we shouldn't have two termination methods but only one that is available from the time we start the fetch algorithm. Yutaka and I also discussed this a little. `Request` is an object that represents HTTP request but not what represents **ongoing** HTTP fetch. It can be used for multiple different `fetch()` calls. So, such a cancellation method should live on the promise or something else. The promise is abstraction of a result. Here **result** is `Response` which becomes available once the HTTP headers are received. So, it seems a bit strange if we give it a power to cancel receiving HTTP body.

So, I like the canceller revealing approach. My preference on `single method` over `X to cancel receiving header, and Y on Response to cancel receiving body` is slight. Maybe I could live with `two canceller` approach is we can define it cleanly.

---
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/streams/issues/297#issuecomment-81410226