RE: Server Push used for long polling

Wenbo, I don’t really understand the distinction you’re making with the term “spontaneous.”  At least as defined in HTTP/2, PUSH_PROMISE can only be sent on a client-initiated stream:
Pushed responses are always associated with an explicit request from the client. The PUSH_PROMISE<http://http2.github.io/http2-spec/#PUSH_PROMISE> frames sent by the server are sent on that explicit request's stream. The PUSH_PROMISE<http://http2.github.io/http2-spec/#PUSH_PROMISE> frame also includes a promised stream identifier, chosen from the stream identifiers available to the server (see Section 5.1.1<http://http2.github.io/http2-spec/#StreamIdentifiers>).

There is no mechanism defined (and there shouldn’t be, IMHO) for a server to arbitrarily throw information at a client without the client having signaled interest in something.  Once that interest is signaled, of course, there are several ways to implement it:

·         A long-lived request which will complete when the server has info of that type (i.e. long-poll)

·         A long-lived response in which the server occasionally emits interesting new information (equivalent to WebSockets, if the client isn’t sending anything after the initial request)

·         A long-lived response which tells the client incrementally what new resources are worth fetching (with the interesting resource potentially pushed alongside to reduce latency)

Regardless, the term “spontaneous” server push suggests something which doesn’t exist in HTTP/2.

From: Wenbo Zhu [mailto:wenboz@google.com]
Sent: Thursday, January 15, 2015 11:24 AM
To: Greg Wilkins
Cc: HTTP Working Group
Subject: Re: Server Push used for long polling



On Thu, Jan 15, 2015 at 8:56 AM, Greg Wilkins <gregw@intalio.com<mailto: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<mailto:martin.thomson@gmail.com>> wrote:
On 12 January 2015 at 09:03, Julian Reschke <julian.reschke@gmx.de<mailto: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<mailto: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.