Re: [whatwg/fetch] Request body streams should use chunked encoding (#966)

From a practical standpoint, if a significant enough number of users are on browsers that don't implement a "standard", it's not really a standard, and developers will generally either not use it, or if they do use it, ensure they have some sort of fallback logic, unless they can compel their users to use a particular browser.

Switching a half-duplex API with hundreds of bits dangling off of it with a full-duplex API, things can fall apart badly, so we're talking a large investment of time in working through all that.  It also adds a lot of new opportunities for implementation divergence, as it touches so many HTTP-layer things.

There are things like auth (you get a challenge in the middle of a streaming upload), to socket pool limits, to what to do if we get a 4xx response while still uploading a stream, to keeping streaming uploads with completed response bodies alive, to what these look like to the WebRequest extension API, request events will no longer be in the order that consumers expect them to be in, etc.  Alternatively, a different set of internal APIs could be introduced for just this case, but then they'd need to plug in very differently (below the layer that hooks up auth, cookies, etc), which would present its own set of issues around duplicating behavior in two very different codepaths.

Of course, restricting it to H2, you *still* have all those problems, browsers go with different internal APIs, which brings a whole new host of problems, in terms of getting them to behave like requests that follow the current path.  So I'm not actually sure restricting things to H2 makes things much simpler.  The code unique to H1 isn't exactly all that complicated, so even having a second copy of it just for this use case shouldn't be too bad - it's just dealing with everything else between the lower HTTP layer and the web page that would be a major investment.

Anyhow, I don't want to give the impression I'm speaking for anyone who has the power to determine whether this gets done in Chrome or not (I'm not even on the network stack team any more), but it would be a pretty major investment in terms of engineering time.  But I think it would be good to see if there's buy-in from someone who says, and has the power to say, "yes, I'd be willing to devote 3 to 18 months of engineering time to be sure this gets done", if folks on the Chrome team think this is an API worth supporting.

-- 
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/966#issuecomment-555837984