fetch() upload streaming

yoichio@chromium

Commenting for @chromium: http://bit.ly/2tSWsIH

Last update: 2021-2-26

Background and Motivation

The Fetch API provides an interface for fetching resources (including across the network). It will seem familiar to anyone who has used XMLHttpRequest, but the new API provides a more powerful and flexible feature set.

However current fetch doesn’t have a function whereby web authors can

Warm up the server. In other words, you could start the request once the user focuses a text input field, and get all of the headers out of the way, then wait until the user presses 'send' before sending the data they entered.
Gradually send data generated on the client, such as audio, video, or input data.

Proposal

I propose to introduce streaming body uploading to fetch, where you can use ReadableStream as a POST body.

Design overview

This paragraph describes related existing components and data flow in chromium to fetch and how I update them for streaming.

Initialize

When |window.fetch(.. {body:ReadableStream})| is called, Blink creates ReadableStreamBytesConsumer to read bytes from the stream and BytesLoader inheriting mojo::ChunkedDataPipeGetter to send the byte via mojo::DataPipe.

Then we bring PendingRemote<ChunkedDataPipeGetter> from renderer to network service.

Finally HTTPStreamParser has ChunkedDataPipeUploadDataStream, which has the DataPipe consumer from ReadbleStreamUpstreamLoader.

Pros

We can limit change.

Cons

We cannot reuse the FromDataElement infrastructure.
Little Inconsistency between network::ResourceRequestBody has a vector<DataElement> having ChunkedDataPipeGetter.

Uploading

When HTTPStreamParser::DoSendBody() is called, it has ChunkedDataPipeUploadDataStream read data from ReadableStream via mojo::DataPipe. HTTPStreamParser has a buffer to receive the data and if the buffer is written, HTTPStreamParser calls Socket::Write() to upload the data until reading all data from ReadableStream.

Uploading via ChunkedDataPipeGetter in network service is already implemented and not needed to be updated.

Component update detail

(update) third_party/blink/renderer/core/fetch/request.cc::ExtractBody() (0.5w)

Add |if V8ReadableStream(..)| branch to return BodyStreamBuffer having ReadableStream.

(update) blink::BodyStreamBuffer (1w)

Change DrainAsFormData() return null if |made_from_readable_stream_| is true; (Already done)
Add function DrainAsChunkedDataPipeGetter(), which initializes PendingRemote<ChunkedDataPipeGetter> and BytesUploader with it and ReadableBytesConsumer locking the ReadableStream, and return the PendingRemote<ChunkedDataPipeGetter>. The BytesUploader is retained by the BodyStreamBuffer.

(new) blink::BytesUploader (4w)

Has blink::BytesConsumer member.
Implements network::mojom::ChunkedDataPipeGetter reading BytesConsumer.

FetchManager::Loader::PerformHTTPFetch() (0.5w)

Update body constructing procedure like:

auto* form_data = fetch_request_data_->Buffer()->DrainAsFormData(exception_state);
if (formData) request.SetHttpBody(form_data);
else request.SetChunkedDPG(fetch_request_data_->Buffer()->DrainAdChunkedDPG());

blink::ResourceRequest (0.5w)

Add mojo::PendingRemote<mojom::ChunkedDataPipeGetter> member.

web_url_request_util.cc::GetRequestBodyForWebURLRequest() (0.5w)

Conversion from WebURLRequest to ResourceRequestBody including the ChunkedataPipeGetter.

WebURLRequest (0.5w)

Add mojo::PendingRemote<mojom::ChunkedDataPipeGetter> getter function.

(test) (4w)

DevTools
Send stream larger than kRequestBodyBufferSize (=16KB)
Redirect
Authentication
CORS preflight
no-cors requests
service worker integration
Prohibit HTTP but HTTPS
AllowH1ForStreamingUpload or not

Standard process

Streaming body upload is already standardized in whatwg/fetch.

However there are a couple of open issues to be closed to ship this feature.

#982: 421 and upload streams (Closed@Mar 8, 2021)
#1058: Allow streaming requests to follow 301/2 redirects if method is 'POST'
#966: Request body streams should use chunked encoding

Doing origin trial

#888: Define behavior in the presence of TLS Early Data
#538: Request body streams that cannot be retried
#267: Use a ReadableStream with byte source (formerly called ReadableByteStream) for .body

Testing at https://glitch.com/edit/#!/yoichio-sw?path=sw.js%3A1%3A0

Appendix

Design discussions

ReadableBytesConsumer

[yhirano] We don't have |consumer_| when |made_from_readable_stream_| is true.

[yoichio] We do that on this design. See the first bullet line.

[yhirano] Then we need to rewrite all the code touching |readable_stream_| because |readable_stream_| is locked when passed to ReadableStreamBytesConsumer (see the class comment).

I think it's better to create a ReadableStreamBytesConsumer when DrainAsChunkedDataPipeGetter is called.

[yoichio] I see. Should we have additional Member<ReadableStreamBytesConsumer> or can reuse |consumer_|?

[yhirano] You don't need to create a member. You don't have to use |consumer_| as well. You just need to create a ReadableStreamBytesConsumer and pass it to a (also newly created) BytesUploader.

[yoichio] We only have BodyStreamBuffer retain BytesUploader instance?

[yhirano] Yes.

[yoichio] Done. Also updated the images.

PendingRemote<ChunkedDataPipeGetter>

[yhirano] How do you call this function?

[yoichio] Call at FetchManager::Loader::PerformHTTPFetch() below.

[yhirano] Thanks. But PerformHttpFetch doesn't know whether the BytesConsumer is ReadableStreamBytesConsumer.

[yoichio] At request.cc::ExtractBody() first, we let BodyStreamBuffer know it is initialized with ReadableStreamBytesConsumer.

[yhirano] I think that's fragile. How about defining DrainAsChunkedDataPipeGetter in BytesConsumer?

[yoichio] Done.

Design #1(declined): Have blink::FormDataElement holding ChunkedDataPipeGetter

Add FomDataElement scoped_refptr<ChunkedDataPipeGetter> member and

new enum kTypeChunkedDataPipe.