Re: Server Push used for long polling

You are correct. #3 involves some kind of faked requests on the server-side
(and I was on the Servlet discussion too), but not for HTTP/2.

And I was mixing #2 with #1 when talking about the RTT overhead. Thanks for
the clarification.

- Wenbo

On Thu, Jan 15, 2015 at 11:52 AM, Mike Bishop <Michael.Bishop@microsoft.com>
wrote:

>  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> 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.
>
>
>