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

Server Push used for long polling

From: Julian Reschke <julian.reschke@gmx.de>
Date: Mon, 12 Jan 2015 17:26:13 +0100
Message-ID: <54B3F5A5.3090101@gmx.de>
To: HTTP Working Group <ietf-http-wg@w3.org>
Patrick McManus wrote:
> On Tue, Jan 6, 2015 at 8:13 AM, Stefan Eissing <stefan.eissing@greenbytes.de
>> wrote:
>> 3. Clarification on server-initiated push?
>> In discussions with colleagues some had the notion that HTTP2 would allow
>> server initiated "requests". My reading of the draft is that this is not
>> really the case. Server pushes are only defined for streams opened by the
>> client.
>> - Is this the correct reading of the spec?
> That's right. The server can push 0..N transactions on any stream opened by
> the client.
>> - If yes, has HTTP2 any advise how to best do long polling or what is the
>> recommended alternative?
> client opens a stream indicating its interested in an event stream.. the
> server may/may not provide a response but it leaves that stream open for
> the duration of time it might push. When it pushes events (represented by a
> request/response pair) it associates the new even streams with the client
> stream. There can be N of these events in parallel, which makes it
> considerably nicer than long polling. Whenever the server decides it is
> done pushing things it can close the odd stream.. or the client can stream
> reset the odd stream if it decides its done first.

When I read this first my interpretation was that the client opens a new 
stream and just leaves it idle waiting for pushes.

However, Section 5.1.1 says:

"The first use of a new stream identifier implicitly closes all streams 
in the "idle" state that might have been initiated by that peer with a 
lower-valued stream identifier. For example, if a client sends a HEADERS 
frame on stream 7 without ever sending a frame on stream 5, then stream 
5 transitions to the "closed" state when the first frame for stream 7 is 
sent or received." -- 

So opening another stream for a new request would close that stream. And 
things would be even worse when multiple clients share the same 
connection when using the same intermediary.

Am I missing something here?

Best regards, Julian
Received on Monday, 12 January 2015 16:26:45 UTC

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