Re: [whatwg/fetch] Streaming upload (Issue #1438)

Let's assume we want to send a 10MB file to a server via HTTP. We make a POST request, send it to the server and get a 200 response. Everything is fine.

Here we interpret the 200 as a sign from the server that it received (and processed) the entire request successfully. See [the definition of 200 status code](https://httpwg.org/specs/rfc9110.html#status.200). If the server responded with a 200 response and then it turns out that the server didn't receive the request, it sounds very strange.

This means before responding with a 200 response, the server should receive the entire request, including the request content.

It is true that in some cases the server doesn't need the entire request content to respond (error cases, for example). On the other hand, without special knowledge about the server, the client shouldn't expect that it will get a response without sending all the request content.

This is why [I think the client should explicitly express an intent to initiate a full-duplex communication](https://github.com/whatwg/fetch/issues/1438#issuecomment-1153994853). By default, the client should expect a response after sending the request content. Note that https://datatracker.ietf.org/doc/html/draft-zhu-http-fullduplex#section-4.1 was aware of this.

> Full-duplex streaming is completely controlled by the server
> application, and should only be enabled for those clients that have
> been explicitly identified by the server.
>...
> For non-controlled client applications, the client may advise its
> capability of full-duplex streaming via URL parameters or headers
> (for example, "X-Accept-Streaming: full-duplex;timeout=30").


-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fetch/issues/1438#issuecomment-1157629032
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/fetch/issues/1438/1157629032@github.com>