Re: [whatwg/fetch] Formalize reading bodies (#1172)

@annevk commented on this pull request.



> +<p>To <dfn export for=body>fully read</dfn> a <a for=/>body</a> <var>body</var>, given an algorithm
+<dfn export for="body/fully read"><var>processBody</var></dfn>, an optional algorithm
+<dfn export for="body/fully read"><var>processError</var></dfn>, and an optional null or
+<a for=/>global object</a> <dfn export for="body/fully read">taskDestination</dfn> (default null),
+run these steps:
+
+<ol>
+ <li><p>If <var>taskDestination</var> is null, then set <var>taskDestination</var> to the result of
+ <a>starting a new parallel queue</a>.
+
+ <li><p>Let <var>promise</var> be the result of <a>fully reading body as promise</a> given
+ <var>body</var>.
+
+ <li><p>Let <var>fulfilledSteps</var> given a <a>byte sequence</a> <var>bytes</var> be to
+ <a>queue a fetch task</a> to run <var>processBody</var> given <var>bytes</var>, with
+ <var>taskDestination</var>.

@domenic for instance, in theory this shouldn't have to queue a task as there's no way for these fulfilled steps to run without one, but the streams primitives this builds on are not exactly clear about that.

This is a clear case, but I have similar questions about the incremental read above. Thoughts?

Apart from that I think this is largely the correct setup that we can use both for request (to incrementally read and then invoke transmit in the callback) and response bodies (mostly to read). And we can also use this to create a proxy stream for SRI, etc.

-- 
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/fetch/pull/1172#pullrequestreview-592307257