Re: [whatwg/streams] In pipeTo spec, the order of checking for shuttingDown disagrees with ref. impl. (#934)

Ah, thanks for explaining that Promise. That is actually one of the test cases that I can probably let fail as in JS-land (which is my informal name for the browser client execution context or… I don't really know the name) I can't set any internal Promise fields anyway. I think I was confused as I'm trying to understand what the use case would be of passing in a mock ReadableStream returning a not-promise. But good to know.

As for uploading files with my adapted fetch function: that is actually one part I didn't do yet. I can do this two ways: 1) read the entire stream, then have fetch do it's thing with the resulting Blob, or 2) actually send data as it comes in. I am leaning towards option 1.

I looked at the fetch spec when I was adding support for the Response body fetch reading and now looking back, I'm interpreting what the way to go is.
a) In the [Request class section](https://fetch.spec.whatwg.org/#concept-body-consume-body) in step 36, it says "extract the body", which for a ReadableStream comes down to "get the stream object."
b) step 39 has a big red issue in it, but wait, there it is:
c) [the transmit body section](https://fetch.spec.whatwg.org/#concept-request-transmit-body), yep send the bytes as they come in. I don't think with public interfaces I can send data in chunks, XHR can't (well, not until it supports ReadableStream…)

I can and will — I overlooked this — add stream uploads to fetch, but only in the "read it all on the client and send it in one go" method. I can't use XHRs or WebSockets to do streamed upload without the browser cooperating, unless there is some other way.

This issue is derailing a bit, I will add a new issue with the test cases. Thanks for the feedback!

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/streams/issues/934#issuecomment-401812433