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

Re: Server push limited to cache priming?

From: Adrien de Croy <adrien@qbik.com>
Date: Thu, 20 Mar 2014 01:07:36 +0000
To: "Mark Nottingham" <mnot@mnot.net>, "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>
Message-Id: <ema2347e4b-26ea-40f0-b08c-6bcee7024f85@bodybag>

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.



------ 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:
>On 20 Mar 2014, at 4:30 am, Martin Thomson <martin.thomson@gmail.com> 
>>  On 19 March 2014 09:56, William Chan (陈智昌) <willchan@chromium.org> 
>>>  This is an unfortunate part of having perhaps too (current?) 
>>>  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

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