- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Mon, 12 Jan 2015 17:26:13 +0100
- 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." -- <http://greenbytes.de/tech/webdav/draft-ietf-httpbis-http2-16.html#rfc.section.5.1.1.p.4> 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