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.

Reply via email to