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 11:51:40 +1100
Cc: "William Chan (陈智昌)" <willchan@chromium.org>, Daniel Sommermann <dcsommer@fb.com>, HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <B006CF03-5E18-4D9A-AB24-C0814EE8C46B@mnot.net>
To: Martin Thomson <martin.thomson@gmail.com>
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> 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

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