You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
HTTP/2 has support for the server pushing content to the client before the client requests it. This is specified as the server sending a PUSH_PROMISE to the client with (at least) the method and url to the resource. The server can then start sending the response to the client before the client has requested it.
The spec does not specify how long the server should wait until it starts sending the response, so it can send it right away or it can choose to wait for a little while. If, while waiting, the server receives a RST_STREAM message from the client on the (stream of the) resource, then the server should interpret that as the client having rejected the content. This can be done for example if the client already has the content in it's cache, and therefore doesn't need it.
It would be useful if this could be handled by the ServiceWorker, since the ServiceWorker has a cache. The ServiceWorker could have a pushPromise event with the url as part of the event object, and a reject method that sends the RST_STREAM to the server. This could then be used to check if the url is in the ServiceWorkers cache, for example:
this.oninstalled=function(){caches.set('myCache',newCache());}this.addEventListener('pushPromise',function(event){//if the request url is in the cache,//then we don't need the server to send it to us,//so we reject itcaches.match('myCache',event.request.url).then(event.reject);});
The text was updated successfully, but these errors were encountered:
I think we want a more generic API and not require service workers to be able to deal with H2 push. whatwg/fetch#51 has some discussion and ideas, but not much progress yet.
HTTP/2 has support for the server pushing content to the client before the client requests it. This is specified as the server sending a PUSH_PROMISE to the client with (at least) the
method
andurl
to the resource. The server can then start sending the response to the client before the client has requested it.The spec does not specify how long the server should wait until it starts sending the response, so it can send it right away or it can choose to wait for a little while. If, while waiting, the server receives a RST_STREAM message from the client on the (stream of the) resource, then the server should interpret that as the client having rejected the content. This can be done for example if the client already has the content in it's cache, and therefore doesn't need it.
It would be useful if this could be handled by the ServiceWorker, since the ServiceWorker has a cache. The ServiceWorker could have a
pushPromise
event with the url as part of the event object, and areject
method that sends theRST_STREAM
to the server. This could then be used to check if the url is in the ServiceWorkers cache, for example:The text was updated successfully, but these errors were encountered: