Re: Server push limited to cache priming?

Speaking personally -- 

I'm going to continue to push back on non-caching uses of server push in HTTP/2; our charter explicitly tells us to be semantically backwards-compatible with HTTP/1, and that means no new semantics. The only way to fit server push into HTTP's existing semantics is to consider it a cache update.

In other words, if you overload server push to mean "async message" and use a new client API to get them, that's not a HTTP API. It'd also necessitate figuring out how to distinguish those updates from pushes that *are* intended for the cache.

OTOH it should be possible to layer async messaging over caching in a way that takes advantage of server push, somewhat like COMET does. I've started to sketch out one mechanism that would contribute to that here:
  http://tools.ietf.org/html/draft-nottingham-http-patch-status-00#appendix-A

Cheers,




On 20 Mar 2014, at 4:30 am, Martin Thomson <martin.thomson@gmail.com> wrote:

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

--
Mark Nottingham   http://www.mnot.net/

Received on Thursday, 20 March 2014 00:52:06 UTC