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

Re: Server push limited to cache priming?

From: (wrong string) 陈智昌 <willchan@chromium.org>
Date: Wed, 19 Mar 2014 09:56:50 -0700
Message-ID: <CAA4WUYgbGa+QTmM9wcHxdaenz_v2bG6k8aHhiWrtdAX1fu14zw@mail.gmail.com>
To: Daniel Sommermann <dcsommer@fb.com>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
I think that's a good point. This is an unfortunate part of having perhaps
too (current?) browser-centric a view in some of our discussions.

And this might be a casualty of imprecise terminology. Notably, the
existing text is reasonable for PUSH_PROMISEs, where a push stream is tied
to an "associated" stream. But for server-initiated streams without an
associated stream (where you just initiate with a HEADERS frame), indeed
restricting to only cacheable responses seems unnecessarily restrictive.

Note that in a platform where you might have multiple applications using
the same HTTP/2 connection (e.g. a browser with multiple hosted web apps
multiplexing over the same connection), you need to identify the particular
application to deliver the server-initiated stream to. You can imagine a
URL registration model or something instead, but perhaps the easiest way to
do this for now is to use WebSockets-style message-based communication over
a single HTTP/2 bidirectional stream initiated by the client (so there's an
explicit binding between the client app and the stream).

On Wed, Mar 19, 2014 at 9:31 AM, Daniel Sommermann <dcsommer@fb.com> wrote:

> I've noticed that parts of the HTTP/2 spec seem to assume that priming the
> browser cache is the primary purpose of server push. However, it seems like
> server push could be used for other purposes, such as delivering async
> messages from the server to the client. I can imagine future application
> extensions that allow clients to register callbacks for when pushed
> resources arrive. This approach could be much more network-efficient than
> current long-polling techniques. Why does the language seem to assume that
> server push is only used for browser caching? E.g. "A server can only push
> responses that are cacheable". It seems unnecessarily restrictive.
Received on Wednesday, 19 March 2014 16:57:18 UTC

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