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

Sorry for the really belated response.

@wenbozhu and I talked about this.We (@wenbozhu  and @yutakahirano ) are happy to restrict the feature to secure contexts, and force CORS preflight for crossorigin requests. However, we want to allow the feature for HTTP/1.1 connections.

The core issue of restricting this feature to HTTP/2 only is that it will force client-side frameworks to implement complicated fallback logic in the runtime, i.e. when HTTP/2 is blocked by forward proxies. The fallback may not even be possible e.g. if the server interfaces don’t support non-streaming “upload”, esp. for API based frontends. That is, those APIs will have to implement two sets of methods, one for accepting streamed upload and one for accepting non-streaming upload (e.g. with multiple POSTs). 

In addition, this will make the fetch/stream API more complicated, to signal when streams are disallowed due to transport versions, unless there is a standard API to query the current HTTP version of an origin … but then the 1st request to an origin will not have this data as the connection is not yet established. Also, proxies may change too, e.g. during network handoff, for a given origin. 

Overall, we just don’t see how this can be deployed for any end-user facing Google services when we don’t control the client-side environments.

Currently we don’t know the impact of client-side intermediates breaking - We don’t know how many servers would break, and how badly they would break. I would like to have a joint experiment with @wenbozhu to see the impact of the breakage by having an origin trial.


-- 
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-586310657