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

[Ilya Grigorik]

On Tue, Feb 24, 2015 at 9:32 AM, Brendan Long  wrote:

> HTTP/2 associates priority information with HEADERS
>  (but as a flag, not as a
> normal header), so maybe it would make sense to add this to Fetch's
> Headers . I'm not sure if
> it makes sense to put it on Request
> , since it seems to only
> expose readonly attributes.
>

HTTP/2 allows reprioritization via PRIORITY frame [1], so this is something
we should account for in the API. E.g. application starts fetching an image
(high priority fetch) but the user advances to the next image in the
gallery, at which point the applications want to reprioritize the initial
fetch such that it still completes and gets cached, but doesn't compete
with new+other fetches that are of higher priority.

[1] http://http2.github.io/http2-spec/#PRIORITY

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

[Anne van Kesteren]

On Tue, Feb 24, 2015 at 6:32 PM, Brendan Long  wrote:
> The ability to control HTTP/2 stream priorities

The tentative plan is to expose these on a promise subclass fetch()
will return at some point in the future, once we figure out what the
API should look like. (That's also where we plan to put fetch
termination and perhaps some per-fetch messaging scheme to keep in
touch with the service worker.)


-- 
https://annevankesteren.nl/

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

[Brendan Long]

Discussion within MPEG just reminded me of another thing we could use in
XHR or Fetch: The ability to control HTTP/2 stream priorities
.

For example, I might want to request the next 5 segments, but indicate
that later segments are dependent
 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
 (but as a flag, not as a
normal header), so maybe it would make sense to add this to Fetch's
Headers . I'm not sure if
it makes sense to put it on Request
, 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  wrote:
>>
>> For server push we already have 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.

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

[Domenic Denicola]

From: whatwg [mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of Brendan Long

> 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.

Working on that:

- http://streams.spec.whatwg.org/
- https://github.com/yutakahirano/fetch-with-streams/

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

[Brendan Long]

> On Feb 20, 2015, at 11:53 AM, Kornel Lesiński  wrote:
> 
> For server push we already have 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.

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

[Kornel Lesiński]

> On 20 Feb 2015, at 10:48, Brendan Long  wrote:
> 
> The obvious question to ask is “why not just poll the server”? The answer its 
> that live streaming latency depends (among other things) on how quickly you 
> poll. Unless you can perfectly predict when the server will have an update 
> available, you need to either poll slightly late (introducing latency) or 
> poll significantly more often than the server creates updates. Using server 
> push is equivalent to to polling infinitely fast, while simultaneously 
> reducing load on the server by making fewer requests (win/win).

For server push we already have Server-Sent Events:

https://html.spec.whatwg.org/multipage/comms.html#server-sent-events

> 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/

-- 
regards, Kornel

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

[Brendan Long]

Hi,

I’m wondering if there is any work in progress to define an API for JavaScript 
clients to detect that an HTTP/2 server has pushed content, and to control the 
“half closed” vs “closed” state of HTTP/2 streams (to control whether or not a 
server can push content).

Use Case

The use-case I have in mind is MPEG DASH or HLS live streaming:

A server updates the manifest (MPD or m3u8) and pushes it. The client browser 
will cache it, but JavaScript applications don’t know that it exists. For newly 
generated segments, we need the MPD to use them anyway, but for adaptive 
streaming we need to know when the request started and when it finished so we 
can estimate bandwidth. If a server is pushing MPD updates, we want a way to 
tell it to stop (RST_STREAM on a pushed stream to end the transfer, or 
RST_STREAM on the original client request to prevent future pushes for that 
request).

The obvious question to ask is “why not just poll the server”? The answer its 
that live streaming latency depends (among other things) on how quickly you 
poll. Unless you can perfectly predict when the server will have an update 
available, you need to either poll slightly late (introducing latency) or poll 
significantly more often than the server creates updates. Using server push is 
equivalent to to polling infinitely fast, while simultaneously reducing load on 
the server by making fewer requests (win/win).

I imagine that this would be useful for JavaScript implementations of HTTP/2 
REST API’s, especially API’s using something like ATOM or RSS. Firefox has an 
API for addons to detect pushed streams, so presumably they think there is some 
use for this (but they didn’t propose this as a public API, so maybe not?).

Solution

I’m not really concerned with how this is solved, but an example would be to 
add to XMLHTTPRequest:

interface XMLHttpRequestEventTarget : EventTarget {
  // event handlers
  attribute EventHandler onloadstart;
  attribute EventHandler onprogress;
  attribute EventHandler onabort;
  attribute EventHandler onerror;
  attribute EventHandler onload;
  attribute EventHandler ontimeout;
  attribute EventHandler onloadend;
  attribute EventHandler onpush;
};

enum XMLHttpRequestLeaveRequestOpenType {
  “true”,
  “false”,
  “no-preference"
};

interface XMLHttpRequest : XMLHttpRequestEventTarget {
  // most of this interface left out for readability

  void open(ByteString method, USVString url, boolean async, optional 
USVString? username = null, optional USVString? password = null, optional 
XMLHttpRequestLeaveRequestOpenType leaveRequestOpen = “no-preference");

  void abort(); // can already be used to fully close client request stream
};

interface XMLHttpPushResponse {
  // event handlers
  attribute EventHandler onprogress;
  attribute EventHandler onabort;
  attribute EventHandler onerror;
  attribute EventHandler onload;
  attribute EventHandler ontimeout;
  attribute EventHandler onloadend;

  void abort();

  // response
  readonly attribute USVString responseURL;
  readonly attribute unsigned short status;
  readonly attribute ByteString statusText;
  ByteString? getResponseHeader(ByteString name);
  ByteString getAllResponseHeaders();
  void overrideMimeType(DOMString mime);
   attribute XMLHttpRequestResponseType responseType;
  readonly attribute any response;
  readonly attribute USVString responseText;
  [Exposed=Window] readonly attribute Document? responseXML;
}

interface XMLHttpRequestPushEvent : Event {
  attribute XMLHttpPushResponse response;
};

And then we’d need some text to say:

If leaveRequestOpen is “true” and the request was made over HTTP/2, the user 
agent should not fully close the request stream until XMLHttpRequest is garbage 
collected or abort() is called on it. If it is “false”, the user agent must 
immediately close the HTTP/2 stream after receiving a complete response.

If a user agent receives a PUSH_PROMISE on the HTTP/2 stream for an 
XMLHttpRequest, it must create an XMLHttpPushResponse, attach it to a 
XMLHttpRequestPushEvent, and fire it for XMLHttpRequestEventTarget.onpush.

XMLHttpPushResponse's attributes and methods all have identical semantics to 
the versions on XMLHttpRequest.

Thoughts?

Brendan Long