fetch streaming upload

[yutakahirano]

Request for Mozilla Position on fetch streaming upload

• Specification Title: Fetch streaming upload
• Specification or proposal URL: https://fetch.spec.whatwg.org/
• Caniuse.com URL (optional): N/A
• Bugzilla URL (optional): N/A
• Mozillians who can provide input (optional): @annevk (whle he is leaving Mozilla), @ddragana

Other information

Discussions:

• Streaming upload whatwg/fetch#1438
• Request body streams should use chunked encoding whatwg/fetch#966
• Uploading a Request made from a ReadableStream body whatwg/fetch#425

TAG review:

• Fetch streaming upload w3ctag/design-reviews#754

Explainer:

• https://github.com/yutakahirano/fetch-with-streams/blob/master/streaming-upload.md

[yutakahirano]

We talked about the feature at TPAC 2019 and at that time Mozilla was interested in the feature. note

[nwtgck]

These may be Bugzilla URLs.

• 1387483 - [Meta-Bug] Support ReadableStream as Request.body in fetch API
• 1469359 - Support ReadableStream as Request.body in fetch API in necko

[bgrins]

I chatted with some folks about this. We're positive on the concept & use cases. There were two concerns raised which I wanted to share and give space for discussion if necessary:

1. Potential for observable ServiceWorker lifetime changes (as per @asutherland). We think browsers should not keep alive a ServiceWorker due to an ongoing stream and since the SW lifetime isn't specced there's a risk for interop bugs. @yutakahirano do you know if this is the case in the Chrome implementation?
2. There's likely some implementation complexity for Gecko (as per @mystor), which doesn't affect our position on the standard but I'll share it for context:

Because our existing code depends on all of the upload stream being available and rewindable, we actually aggressively convert the stream into a buffered one so we can replay it within the http channel

[yutakahirano]

Potential for observable ServiceWorker lifetime changes (as per @asutherland). We think browsers should not keep alive a ServiceWorker due to an ongoing stream and since the SW lifetime isn't specced there's a risk for interop bugs. @yutakahirano do you know if this is the case in the Chrome implementation?

When the script clones a Request and then kicks off the network fallback, we need to keep the service worker alive until we read the request body.

See 'Running clone() in the service worker does not prevent network fallback.' which uses "handleConeAndIgnore" for the test case.

[valenting]

Considering the last comment and the fact that we are actually going to implement this, I think we can close this issue as Positive ➕.

[martinthomson]

➕ it is. Thanks all. No dashboard entry for this one.