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

(sorry about the delay, with all the WFH stuff going-on now ...)

I am happy to implement any experiments Yutaka mentioned.

===

I'd also like to point out that with H2, the value of request-streaming is actually less than with H1, v.s. parallel on-demand POSTs, which
1) are multiplexed, with headers compressed;
2) may be sent over multiple TCP connections;
3) are able to ack the delivery of client-sent data immediately while with streaming, any amount of data could be lost when the HTTP transaction is aborted.

There are certainly use cases with very high message rates that will benefit from (short-lived) request-streaming due to reduced overhead for processing individual requests.

===

Re: fallback, agreed that fallbacks are always needed even when both H1 and H2 are supported. 

There are three compatibility issues: 1) proxies buffering HTTP bodies; 2) proxies not supporting H2; and 3) servers not supporting H1 chunked-encoding or H2.

There is no fail-fast for 1), independently of H1 or H2. The fallback solution is often complicated.

2) will fail-fast by the proxy, but unknown at the design time (of the web app).

3) will fail-fast by the server due to the lack of Content-Length etc, and known at the design time. This is the same situation as servers not supporting H2.

With HTTPS, I believe 2) is a much more common issue than 1). Restricting request-streaming to H2 doesn't avoid 1) either.

3) is a design-time issue for web apps. However, I don't know the scale of the problem for those "file-uploading" end-points that don't author any JS library for their clients. We won't be able to run any experiment for them either.



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