Re: Server Push used for long polling

On 2015-01-12 17:26, Julian Reschke wrote:
> 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

So it was explained to me off-list that opening the stream implies 
sending a message, after which the stream is not idle anymore.

It still has a hacky feeling to me; for instance, an intermediary 
wouldn't be able to distinguish this case from a request that actually 
takes very long to execute.

Best regards, Julian

Received on Monday, 12 January 2015 17:03:57 UTC