W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2014

Re: Server push limited to cache priming?

From: Mark Nottingham <mnot@mnot.net>
Date: Thu, 20 Mar 2014 12:27:42 +1100
Cc: Martin Thomson <martin.thomson@gmail.com>, "William Chan (陈智昌)" <willchan@chromium.org>, Daniel Sommermann <dcsommer@fb.com>, HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <9D46C078-63E9-4CE3-AA11-0F73048AF264@mnot.net>
To: Adrien de Croy <adrien@qbik.com>
... 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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:25 UTC