Re: Server push limited to cache priming?

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