There are no current plans for streaming requests or responses. We are limited by what XMLHttpRequest supports.

There is a draft specification for streams in the Fetch API, with a native implementation shipping in Chrome already.

Please reopen, there are two was you can get a stream from XMLHttpRequest.

xhrRequest
.
responseType
 =
 "ms-stream"
;

// or

xhrRequest
.
responseType
 =
 "moz-chunked-arraybuffer"
;

If this would be implemented then i would rather want to use the polyfill then firefox or edge partially supported fetch api
This is crucial for my application where i need to handle large file with lower memory.
And with web-stream-polyfill this would be a breeze

Sure, let's revisit this. But I make no promises about actually implementing this in github/fetch.

It sounds like we can get native streaming from Chrome 43+, and streaming via XHR in IE and Firefox. How about Safari? is anything available there?

Like i said to jonnyreeves/chunked-request

Played a bit myself with streams and monkey patching xhr:
This is how i would do it for firefox: https://jsfiddle.net/98L105v3/2/

I created it yesterday, maybe it would be of any interest?

Borrow some info from jonnyreeves/chunked-request#16

• Chrome: use native reader from fetch
• FF: set responseType to moz-chunked-arraybuffer, get ArrayBuffer(s) from xhr.response progress event(s), accumulate if needed, resolve reader.read Promise
• IE10+: set responseType to ms-stream, call readAsArrayBuffer on xhr.response to get an eventemitter, get ArrayBuffer(s) from eventemitter progress event(s), accumulate if needed, resolve reader.read Promise
• IE9: set responseType to text, slice xhr.responseText on progress event(s) to get chunk(s), convert to ArrayBuffer(s) using text-encoding-utf-8, accumulate if needed, resolve reader.read Promise
• Safari: until it supports fetch, basically do the same thing as for IE9, except use native Uint8Array when converting to ArrayBuffer like this.

They also utility a partial request method (making multiple range request) Perhaps this would be a solution or just make it overkill

if this gets implemented the we can't use this code any longer

  if
 (
self
.
fetch
)
 {

    return

  }

Cuz with streams i think the polyfill would actually be better then the partial fetch api FF & Edge supports

Oh, and by the way.
If someone would do new Responsen(blob, {}).body.getReader() then there is some code you can take out of my Screw-FileReader lib about the part where I make a blob to a ReadableStream ??

Even if XMLHttpRequest can't really do streams, I think it would be great to have https://github.com/domenic/streams-demo working on old browsers, with only one chunk, and by adding a res.body.getReader()

@jimmywarting I'm not sure if this is still a concern, but the workaround method for a bad FileReader might also work to allow this polyfill to override a native implementation so you can keep your preferred streaming when browsers only offer partial support.

this project probably deserves to be looked at too

still no stream support?

Still no streaming support, and I think that it's safe to decide at this point that this polyfill will never have streaming support.

This polyfill has been feature-complete for a while (i.e. has all the features implemented that cover most common usages of fetch ) and will likely get no new large features. Furthermore, this polyfill isn't even used in any of today's modern browsers, since Chrome, Firefox, Safari, and Edge all have shipped with a native implementation of window.fetch for a long while now.

If your app really needs streaming, feature-detect it and use native browser capabilities. When streaming capabilities are not present (e.g. when this polyfill is being used in old browsers), your app should gracefully fall back to regular request/response reading.