Re: Server push limited to cache priming?

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

Received on Thursday, 20 March 2014 01:08:05 UTC