Discussion within MPEG just reminded me of another thing we could use in XHR or Fetch: The ability to control HTTP/2 stream priorities <http://http2.github.io/http2-spec/#StreamPriority>.
For example, I might want to request the next 5 segments, but indicate that later segments are dependent <http://http2.github.io/http2-spec/#pri-depend> on earliest segments. This would let us fully use the available bandwidth without having later segments cannibalize bandwidth from earlier segments. HTTP/2 associates priority information with HEADERS <http://http2.github.io/http2-spec/#HEADERS> (but as a flag, not as a normal header), so maybe it would make sense to add this to Fetch's Headers <https://fetch.spec.whatwg.org/#headers-class>. I'm not sure if it makes sense to put it on Request <https://fetch.spec.whatwg.org/#request-class>, since it seems to only expose readonly attributes. On 02/20/2015 05:37 AM, Brendan Long wrote: > >> On Feb 20, 2015, at 11:53 AM, Kornel Lesiński <kor...@geekhood.net> wrote: >> >> For server push we already have Server-Sent Events: >> >> https://html.spec.whatwg.org/multipage/comms.html#server-sent-events >> <https://html.spec.whatwg.org/multipage/comms.html#server-sent-events> > Using an entirely different protocol to inform the JavaScript client of > events that the browser is already aware of seems like overkill. > > This also doesn’t solve the problem of canceling pushed streams. > >>> I’m not really concerned with how this is solved, but an example would be >>> to add to XMLHTTPRequest: >> XHR is dead. >> >> https://fetch.spec.whatwg.org/ > I’ll look into what would need to be added to this. Presumably we could just > add an onpush event to Request which is fired with an event containing a new > Request (containing info from the PUSH_PROMISE). > > It’s not clear to me how we would cancel a pushed stream, or retrieve > streaming body data without waiting for the request to completely finish.
