Re: Server Push used for long polling

On Thu, Jan 15, 2015 at 8:56 AM, Greg Wilkins <gregw@intalio.com> wrote:

>
> As I have noted in other threads, it is an epic fail of HTTP2 that we have
> to consider using fake HTTP requests for websocket semantics, as we were
> chartered to consider carrying websocket semantics.
>
> But other than spilt milk,  I think the paragraph highlighted by Julian
> does have ramifications for the priority mechanism usage proposed by
> Patrick, as he intends to create 5 streams with just a priority message.
> Note that there are also other usages proposed of stream creation with just
> a priority message (I can't recall what they are, but we did just recently
> add the ability to send priority first).
>
> Thus 5.1.1 says that a server should close those streams, as they are
> definitely idle as headers have not been received.    This will break
> Patricks priority mechanism (and please don't suggest that servers should
> remember the priority relationships of closed streams, as the CONTINUATION
> mechanism already makes closure like dealing with the return of the living
> dead, but servers have to be eventually forget streams.... please!!!).
>
>
> Other than that, I think that using PP for a long polling replacement is a
> lot of work for very little gain.    Long polling as written today will
> just work on HTTP2.   The only limitation that PP is removing the one RTT
> between subsequent messages as the server does not need to wait for a new
> long poll before sending the next message.  The cost of this is essentially
> a new protocol based on hacking fake HTTP messages that will need dedicated
> client support.    Wouldn't it have been far better/easier to just make
> HTTP2 capable of carrying websocket semantic rather than faking it?
>
Wouldn't you need an open (i.e. pre-opened) websocket stream to do this?
IMO, spontaneous server-push (i.e. without a client-initiated stream) is a
unique feature of PP, which is orthogonal to the problem of streaming data
from the server to client.

>
>
>
>
>
>
>
>
>
>
> On 12 January 2015 at 22:27, Martin Thomson <martin.thomson@gmail.com>
> wrote:
>
>> On 12 January 2015 at 09:03, Julian Reschke <julian.reschke@gmx.de>
>> wrote:
>> > 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.
>>
>>
>> Indeed, but we do have Prefer: wait=10000000000 if you want to include
>> such a signal.
>>
>>
>
>
> --
> Greg Wilkins <gregw@intalio.com>  @  Webtide - *an Intalio subsidiary*
> http://eclipse.org/jetty HTTP, SPDY, Websocket server and client that
> scales
> http://www.webtide.com  advice and support for jetty and cometd.
>