Re: [whatwg/fetch] Clarify semantics of checking done, closed, etc. states of a null body stream (#635)

> As in the 43rd step in https://fetch.spec.whatwg.org/#dom-request, the newly created Request object will use a newly created ReadableStream which is associated with the original stream. Mutating the latter request will not affect the original request.

Ah, right! Thanks for explaining this. There is no problem in the second/third examples, then -- I've edited my issue report to strike out those two headings, and added an explanatory note.

I guess that leaves the null body stream check in section 4.3 (HTTP fetch), step 5.1. Perhaps a better description for this issue might be, "Reconcile body stream nullification in HTTP network-or-cache fetch step 2.2.4 with body transmission interruption in HTTP fetch step 5.1."

Perhaps a request's body's stream should not be nullable at all, or at least not be nullified by the HTTP network-or-cache algorithm? It's nullity never seems to be checked, so the HTTP-redirect fetch algorithm wouldn't change in behavior, but the body transmission interruption step (HTTP fetch 5.1) would start working.

-- 
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/issues/635#issuecomment-346118328