We should investigate and consider implementing Request.body and Response.body attributes as streams. Proposal is here: https://github.com/yutakahirano/fetch-with-streams Blink intends to ship an implementation: https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/35_QSL1ABTY

Tracking under 'platform-rel-Facebook'. This issue is blocking Facebook from rolling out service worker to users and providing more feedback on Firefox's implementation.

I've been told once facebook rolls this out Chrome will receive a considerable startup perf boost relative to firefox if we don't support this. We should see if we need this to be competitive.

adding dev-doc-needed, just in case we need to update docs as a result.

(In reply to Bas Schouten (:bas.schouten) from comment #2) > I've been told once facebook rolls this out Chrome will receive a > considerable startup perf boost relative to firefox if we don't support > this. We should see if we need this to be competitive. Adding :overholt for his direction...

Thanks for bringing this up, Bas. We're aware of some of the work Facebook has been doing here and have requested some more information (they have already been great about sharing their results). If that comes back showing that this is super super important, we'll see if we can shuffle this bug's priority. Barring that, this is still on our "next most important thing" list.

I'm implementing this feature in bug 1128959.

The important thing is the design of this api. It might permits not only to use a byte reader but also a way for transforming a stream in another stream. For example you receive a particular text stream and it convert it another stream after a manupulation. In addition it is necessary to create a custom reader/writer also in javascript not only in native code. I could create a algorithm generating a stream(for example a sound,...). This api in future might replace a lot of not mature api for reading/writing video/audio streams.