Re: Server push limited to cache priming?

... and I *think* that's where we're at with the current text. I just don't want to go explicitly documenting things that we're not designing / building into the protocol.


On 20 Mar 2014, at 12:07 pm, Adrien de Croy <adrien@qbik.com> wrote:

> 
> I don't think backward compatibilty means nothing new can be allowed.  It just means everything old must still be supported.  If a pathway doesn't support all new features (e.g. a 1.1 gateway in the chain), then that is a different issue, and some new features may not be available in that deployment case, but shouldn't be prohibited in the spec.
> 
> Cheers
> 
> Adrien
> 
> ------ Original Message ------
> From: "Mark Nottingham" <mnot@mnot.net>
> To: "Martin Thomson" <martin.thomson@gmail.com>
> Cc: "William Chan (陈智昌)" <willchan@chromium.org>; "Daniel Sommermann" <dcsommer@fb.com>; "HTTP Working Group" <ietf-http-wg@w3.org>
> Sent: 20/03/2014 1:51:40 p.m.
> Subject: 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/
>> 
>> 
>> 
>> 
> 

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

Received on Thursday, 20 March 2014 01:28:10 UTC