Interacting with HTTP/2 push

[jakearchibald]

HTTP/2 allows additional resources to be pushed with a response. This is something we may want to expose to SW.

This will probably need a new event, something like…

self.onpushresponse = function(event) {
  event.response;
  event.request;
};

This would be fired when the request portion is received and we're at the start of the body (same as when fetch resolves).

This allows the developer to add the request/response pair into a cache. It response should be abortable too, we should probably have .abort on response objects.

The network can also abort the request, i.e. if it matches something already in the HTTP cache. Because of this, we probably need a way for the SW to "claim" the pushed response. Maybe this is as simple as preventDefault.

(I don't think we need this for the first version of the spec, but we should ensure we don't do anything that gets in the way)

/cc @willchan

[annevk]

Why should we expose HTTP/2 semantics like this? Would this pairing not happen automatically at the network layer?

[jakearchibald]

If an HTTP/2 response comes with additional request/response pairings via push, it feels like the serviceworker should have some access to this so they can be placed in caches.

This isn't a v1 thing though.

[willchan]

I agree with the sentiment for simply keeping this in mind, but not explicitly working on this in v1.

I think we need use cases for this before designing too much for it. It's not obvious to me that it's clearly advantageous to allow network level pushes (via HTTP/2) to notify a ServiceWorker so it can populate an application cache, rather than sitting in the HTTP cache until claimed by the web layer (whether that be the document or the SW). But if someone has a good explanation for it, I'd be interested.

[annevk]

Closing this. Once there's a concrete plan we can open an issue. Now this issue just makes it less clear what is left to be done on the specification.

[rektide]

Not sure entirely what relation this has to push support in fetch but, but that issue is whatwg/fetch#51 . Also there's #796 which is a very specific use case of rejecting pushes.