Re: Server Push used for long polling

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?










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.