Intent to Implement: fetch() upload streaming

306 views
Skip to first unread message

Yoichi Osato

unread,
Nov 7, 2019, 8:57:47 PM11/7/19
to blink-dev

[blink-dev] Intent to Implement: fetch() upload streaming

(Sorry I resend this due to mis-formatting)

Contact emails

yoi...@chromium.org, yhi...@chromium.org


Design doc/Spec

Spec: https://fetch.spec.whatwg.org/#concept-body-stream

Design doc: https://docs.google.com/document/d/1MOdGlq4N9Dd533g3KjxTRRzOVLDd56D2ozpRe-MvyyM/edit?usp=sharing 

TAG review: https://github.com/w3ctag/design-reviews/issues/434

WHATWG discussion: https://github.com/whatwg/fetch/pull/425 


Summary

Fetch provides a generic definition of Request and Response objects (and other things involved with network requests). 

This is a feature which lets web developers make a fetch with a ReadableStream body.


Motivation

You will be able to upload streaming data - possibly generated by devices, media, and so on.

Some web clients want to talk to a streaming end-point directly without any intermediary translation. 

Traditionally, uploading streaming data was implemented on WebSocket but it has made client/server code messy. Fetch upload streaming makes that simpler.


Non-goal

Due to Chromium network stack implementation complexity, supporting bi-directional streaming (i.e., sending request body while receiving response body) is out of scope. Chromium starts reading response after sending all the request body, and we don't intend to change that.. 

 

Risks

Interoperability and Compatibility

Edge: no signal

Firefox: public support (see the TPAC discussion)

Safari: public support (see the TPAC discussion)

Web / Framework developers: some opinions can be seen at https://github.com/whatwg/fetch/pull/425 and https://groups.google.com/a/chromium.org/forum/#!topic/blink-network-dev/bsVgOxNCzFc.

 

Some servers may not be able to handle chunked uploads. To protect the legacy servers, the fetch spec states UA doesn’t allow no-cors requests to have a streaming body, and UA forces CORS preflight for any cross-origin request with a streaming body. [1]

[1] (https://fetch.spec.whatwg.org/#dom-request)


Ergonomics

The API is built around ReadableStream, which means that its core I/O principles would be familiar to the developers who had already used Streams via Fetch and other APIs.


Activation

This facility was not previously available in the web platform, so creating a high-fidelity polyfill is not possible. Developers will need to have two code paths until all browsers support it.


Debuggability

Having DevTools show something simply 'request body is ReadableStream' in Request Payload section and afterwards extending that to something more meaningful.


Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes.


Link to entry on the feature dashboard

https://www.chromestatus.com/feature/5274139738767360 


Requesting approval to ship?

No.

Yoav Weiss

unread,
Nov 8, 2019, 7:01:35 AM11/8/19
to Yoichi Osato, blink-dev
On Thu, Nov 7, 2019 at 5:57 PM Yoichi Osato <yoi...@chromium.org> wrote:

[blink-dev] Intent to Implement: fetch() upload streaming

(Sorry I resend this due to mis-formatting)

Contact emails

yoi...@chromium.org, yhi...@chromium.org


Design doc/Spec

Spec: https://fetch.spec.whatwg.org/#concept-body-stream

Design doc: https://docs.google.com/document/d/1MOdGlq4N9Dd533g3KjxTRRzOVLDd56D2ozpRe-MvyyM/edit?usp=sharing 


Can you please make this document public?
An explainer would make this easier to review by outlining what the proposed change is, and what use cases it helps to solve
 

Summary

Fetch provides a generic definition of Request and Response objects (and other things involved with network requests). 

This is a feature which lets web developers make a fetch with a ReadableStream body.


Motivation

You will be able to upload streaming data - possibly generated by devices, media, and so on.

Some web clients want to talk to a streaming end-point directly without any intermediary translation. 

Traditionally, uploading streaming data was implemented on WebSocket but it has made client/server code messy. Fetch upload streaming makes that simpler.


Non-goal

Due to Chromium network stack implementation complexity, supporting bi-directional streaming (i.e., sending request body while receiving response body) is out of scope. Chromium starts reading response after sending all the request body, and we don't intend to change that.. 

 

Risks

Interoperability and Compatibility

Edge: no signal

Firefox: public support (see the TPAC discussion)

Safari: public support (see the TPAC discussion)


For Mozilla, I believe that counts as "positive signals", but not "public support".

Web / Framework developers: some opinions can be seen at https://github.com/whatwg/fetch/pull/425 and https://groups.google.com/a/chromium.org/forum/#!topic/blink-network-dev/bsVgOxNCzFc.

 

Some servers may not be able to handle chunked uploads. To protect the legacy servers, the fetch spec states UA doesn’t allow no-cors requests to have a streaming body, and UA forces CORS preflight for any cross-origin request with a streaming body. [1]

[1] (https://fetch.spec.whatwg.org/#dom-request)


Ergonomics

The API is built around ReadableStream, which means that its core I/O principles would be familiar to the developers who had already used Streams via Fetch and other APIs.


Activation

This facility was not previously available in the web platform, so creating a high-fidelity polyfill is not possible. Developers will need to have two code paths until all browsers support it.


Debuggability

Having DevTools show something simply 'request body is ReadableStream' in Request Payload section and afterwards extending that to something more meaningful.


Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes.


Link to entry on the feature dashboard

https://www.chromestatus.com/feature/5274139738767360 


Requesting approval to ship?

No.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CA%2BnOeyg8fn8Mt1Cz3%3DXuJoiOTE9Gi8Rb8YtvbLctZ%3DWkbAOqGw%40mail.gmail.com.

Yoichi Osato

unread,
Nov 10, 2019, 9:59:10 PM11/10/19
to Yoav Weiss, blink-dev
O.K. Now it is public.

> An explainer would make this easier to review by outlining what the proposed change is, and what use cases it helps to solve

Firefox: public support (see the TPAC discussion)

 
> For Mozilla, I believe that counts as "positive signals", but not "public support".

I see, but the feature dushboard has only "Shipped", "In development", "Public support", "Mixed public signals", "No public signals", "Public skepticism" and "Opposed" items.
 "Mixed public signals" suits the opinion? 



2019年11月8日(金) 21:01 Yoav Weiss <yo...@yoav.ws>:

EricLaw-MSFT

unread,
Nov 11, 2019, 4:30:06 PM11/11/19
to blink-dev
Edge can be switched to Public Support. We are excited to see this feature, and there are a number of teams at Microsoft interested in taking advantage of it. 

As noted in the past, we have framework teams (SignalR) that are also interested in bidirectional streaming, but the ability to use two parallel unidirectional requests is considered a meaningful stepping stone. 

thanks,

-Eric Lawrence
Edge Networking

Yoichi Osato

unread,
Nov 11, 2019, 9:06:22 PM11/11/19
to EricLaw-MSFT, blink-dev
>  Edge can be switched to Public Support. We are excited to see this feature, and there are a number of teams at Microsoft interested in taking advantage of it. 

Thanks for stating that! The feature dashboard has been updated.

> As noted in the past, we have framework teams (SignalR) that are also interested in bidirectional streaming, but the ability to use two parallel unidirectional requests is considered a meaningful stepping stone. 

Yes, I heard some users wanted bidirectional streaming on request. We will revisit the feature later on.

2019年11月12日(火) 6:30 'EricLaw-MSFT' via blink-dev <blin...@chromium.org>:
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/24523982-bfaf-4fd6-9b96-3b8d0c1109f4%40chromium.org.
Reply all
Reply to author
Forward
0 new messages