UserAgent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Firefox/45.0

Example URL:
https://gist.github.com/Matthias247/60f700a5faea1ccc1006

Steps to reproduce the problem:
1. Start a (HTTP2) server which streams data slowly to chrome, e.g. 1byte/s 
2. Make a Fetch API call to the to server and try to access the streamed body through the fetch body stream

What is the expected behavior?
The promise should resolve directly after the complete HTTP2 header block which marks the start of the response stream was received. I should directly be able to access the content of the stream as soon as a related DATA frame arrives. If I send single bytes from the server in 1 second intervals like shown in the linked server code then I should be able to use that data in the client without a big delay.

What went wrong?
The promise returned from fetch is not resolved until not at least a certain amount of bytes were received. That number seems to be 1024.
If at the beginning of the response stream a big data block (>= 1024 bytes) is returned at once then the promise will be resolved immediately.

Did this work before? N/A 

Chrome version: 49, Canary  Channel: n/a
OS Version: 6.1 (Windows 7, Windows Server 2008 R2)
Flash Version: 

I'm experimenting with using HTTP2 for streaming and synchronization purposes (similar to gRPC). The idea is that everytime I have a state update on the server I write that in a serialized form to the HTTP response stream and can pick it through processing the stream on the client. However this currently doesn't seem to work when when the object size is small, as I then would need lots of updates until the first one would be actually visible to the client.