Re: Server push limited to cache priming?

On 19 March 2014 09:56, William Chan (陈智昌) <willchan@chromium.org> wrote:
> This is an unfortunate part of having perhaps too (current?) browser-centric
> a view in some of our discussions.

I don't think that it's that at all.  I know that browsers and browser
use cases dominate the discussion often, but I believe that this
decision was made for another reason.

The reason, as I understand it, relates to the ability of a client to
act upon a response when it is received.  If you push a response that
is not expected and it's not cacheable, then - absent some sort of
eventing API - it has to be discarded.  This is more a symptom of
wanting to minimize the delta for using applications, and a concern
that we don't completely understand all the implications of a choice
to allow non-cacheable responses.  Once we have eventing APIs, then
perhaps we can lift the restriction, but it's harder to remove
functionality if we made a mistake.

Received on Wednesday, 19 March 2014 17:31:18 UTC