Re: Server push limited to cache priming?

On 03/19/2014 09:59 AM, Martin Thomson wrote:
> Did you have
> something else in mind that requires an uncacheable response?

Not in particular, but the language of the spec assumes that the purpose 
of server push is cache priming. Before I run out and implement a 
notification channel or other non-caching features on top of server 
push, it would be good to know that this is not an "unexpected" or 
"unsupported" use-case.

On 03/19/2014 09:56 AM, William Chan (陈智昌) wrote:
> 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).

I'm imagining a scheme something like this:

-> GET /subscribe?chan=my_chan (stream=1)

<- PUSH_PROMISE (assoc-stream=1, promised-stream=2)
<- HEADERS and DATA (stream=2)

<- PUSH_PROMISE (assoc-stream=1, promised-stream=4)
<- HEADERS and DATA (stream=4)

...etc

On the same connection, the client could be subscribed to the same 
channel multiple times, which is probably just a client bug and would 
lead to duplicate notifications. I don't see how this is fatal however. 
The server or intermediary doesn't have to do any extra bookkeeping (I 
think you were getting at this approach with your last point). It would 
just forward based on the associated stream. You are right that we don't 
really need both a PUSH_PROMISE and HEADERS in this case. In some ways 
SPDY's push mechanism is more appropriate for this use case than HTTP/2.

On 03/19/2014 10:30 AM, Martin Thomson wrote:
> Once we have eventing APIs, then perhaps we can lift the restriction, 
> but it's harder to remove functionality if we made a mistake. 
Understandable. I guess I'd like to get us thinking about those eventing 
APIs sooner than later to make sure the caching restrictions don't bite 
future implementations. If there are opportunities to safely broaden the 
language of the spec to acknowledge other uses for server push, I think 
we should make those changes.