W3C home > Mailing lists > Public > whatwg@whatwg.org > February 2015

Re: [whatwg] HTTP/2 push detection and control in JavaScript

From: Brendan Long <self@brendanlong.com>
Date: Tue, 24 Feb 2015 11:32:51 -0600
Message-ID: <54ECB5C3.6010703@brendanlong.com>
To: whatwg@lists.whatwg.org
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 <kornel@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.
Received on Tuesday, 24 February 2015 17:33:21 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 17:00:27 UTC