Fetch streaming upload

[yutakahirano]

Wotcher TAG!

I'm requesting a TAG review of fetch streaming upload.

[One paragraph summary of idea, ideally copy-pasted from Explainer introduction]

• Explainer¹ (minimally containing user needs and example code): https://github.com/yutakahirano/fetch-with-streams/blob/master/streaming-upload.md
• Specification URL: https://fetch.spec.whatwg.org/
• Tests: /wpt/fetch, /wpt/service-workers
• User research: None
• Security and Privacy self-review²: https://github.com/yutakahirano/fetch-with-streams/blob/master/streaming-upload-security-privacy-questionnaire.md
• GitHub repo (if you prefer feedback filed there): https://github.com/whatwg/fetch
• Primary contacts (and their relationship to the specification):
  • [Yutaka Hirano] ([@yutakahirano]), [Google]
• Organization(s)/project(s) driving the specification: [Chromium]
• Key pieces of existing multi-stakeholder review or discussion of this specification:
• External status/issue trackers for this specification (publicly visible, e.g. Chrome Status): https://chromestatus.com/feature/5274139738767360

Further details:

• [x] I have reviewed the TAG's Web Platform Design Principles
• Relevant time constraints or deadlines: [2022-07-19]
• The group where the work on this specification is currently being done:
• The group where standardization of this work is intended to be done (if current group is a community group or other incubation venue):
• Major unresolved issues with or opposition to this specification:
• This work is being funded by:

You should also know that...

[please tell us anything you think is relevant to this review]

We'd prefer the TAG provide feedback as (please delete all but the desired option):

🐛 open issues in our GitHub repo for each point of feedback

☂️ open a single issue in our GitHub repo for the entire review

💬 leave review feedback as a comment in this issue and @-notify [github usernames]

---

CAREFULLY READ AND DELETE CONTENT BELOW THIS LINE BEFORE SUBMITTING

Please preview the issue and check that the links work before submitting.

In particular, if anything links to a URL which requires authentication (e.g. Google document), please make sure anyone with the link can access the document. We would prefer fully public documents though, since we work in the open.

¹ We require an explainer to give the relevant context for the spec review, even if the spec has some background information. For background, see our explanation of how to write a good explainer. We recommend the explainer to be in Markdown.

² A Security and Privacy questionnaire helps us understand potential security and privacy issues and mitigations for your design, and can save us asking redundant questions. See https://www.w3.org/TR/security-privacy-questionnaire/.

[torgo]

Ho @yutakahirano - can you please update your explainer with a bit more detail? Please have a look at the explainer explainer for some detail on this. A good explainer should start with user needs - rather than developer needs. There's a purpose to this - to make sure the technologies we are adding to the web are build to meet user needs or solve user-facing problems. Thanks!

[yutakahirano]

@torgo This allows web developers a way to upload unbounded streams. On the other hand, web developers can work around the current limitation, via multiple fetch requests or other APIs/protocols. There are other problems for such mitigations (more network resources, more latencies, extra developement cost for another protocol, etc.) but these are problems for developers, not for end-users. Hence it is difficult to state clear user benefits, although I believe the new feature ends up benefitting end-users in the end, via more efficiency and less developement cost.

[torgo]

Hi @yutakahirano that's great - can you please articulate that user benefit at the beginning of the explainer. Something like "More efficiency and lower development cost for streams means better, more performant, more reliable web applications when those web applications make use of streams."

[yutakahirano]

Thanks, I updated the explainer.

[maxpassion]

Hi @yutakahirano, we had a discussion in our TAG meeting today. In the explainer, you mentioned that the current version support only "half-duplex" and the future version may support "full-duplex", is there any mechanism that deals with the compatibility of different versions?

[yutakahirano]

Sorry for the delay!

Currently "half" is the only valid value, "full" is just mentioned in a note. Hence currently new Request('/', {duplex: 'full'}) throws an exception (if the browser supports streaming upload). When full-duplex streaming upload is specified and a browser starts supporting it, the browser will accept new Request('/', {duplex: 'full'}).

[torgo]

Hi @yutakahirano thanks for the updates. We'd like to see more detail on the user need and expected use cases for this. For example "Currently when users need to do xxx the situation is yyy. This creates problems because zzz. This technology solves these problems by qqq." This should be at the top of the document explaining what the new technology proposal is. We're also reviewing the API and we appreciate your feedback regarding the modes. Also thank you for going through the security & privacy questionnaire and providing answers. Can you bring this document into the same repo as the explainer please (rather than a google doc)?

[yutakahirano]

Done: https://github.com/yutakahirano/fetch-with-streams/blob/master/streaming-upload-security-privacy-questionnaire.md

[yutakahirano]

cc: @jakearchibald

[torgo]

Hi @yutakahirano thanks for the updated questionnaire responses.. I think we're still looking for some more info in the explainer relating to use cases and user need (from the end-user PoV)?

[yutakahirano]

"Currently when users need to do xxx the situation is yyy. This creates problems because zzz. This technology solves these problems by qqq."

I think they are already explained in the doc.

The end-user benefit is described as:

These performance shortcomings and cost of additional logic will impact end-users. In other words, this feature will help end-users enjoy web applications with better performance, more reliability and less cost.

Sample use-cases are listed as:

• Web developers can upload unbounded data to the server.
• Web developers can implement streaming processing easily.

The kwown workarounds and their shortcomings are described at the Without the feature paragraph.

I like the current structure because xxx, yyy and zzz are long. If we had them in a single paragraph, it'd be very hard to understand the paragraph.

[torgo]

@yutakahirano Ok we're happy to close this on that basis. For reference: I think you do need to spend more time thinking about how to explain this feature and its benefits - especially when it gets documented in places like MDN where developers are not going to have the same context in their heads so may need a little more explanatory text. That's part of the point of asking for explainers, by the way.