Subject: Server Push used for long polling

From: Julian Reschke <[email-masked]>
Date: Mon, 12 Jan 2015 17:26:13 +0100

Patrick McManus wrote:
> On Tue, Jan 6, 2015 at 8:13 AM, Stefan Eissing <[email-masked]
>> 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

---

From: Julian Reschke <[email-masked]>
Date: Mon, 12 Jan 2015 18:03:27 +0100

> Am I missing something here?

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

---

From: Martin Thomson <[email-masked]>
Date: Mon, 12 Jan 2015 13:27:54 -0800

On 12 January 2015 at 09:03, Julian Reschke <[email-masked]> 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.

---

From: Greg Wilkins <[email-masked]>
Date: Thu, 15 Jan 2015 17:56:51 +0100

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 <[email-masked]>
wrote:

> wouldn't

-- 
Greg Wilkins <[email-masked]>  @  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.

---

From: Wenbo Zhu <[email-masked]>
Date: Thu, 15 Jan 2015 11:23:37 -0800

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

---

From: Greg Wilkins <[email-masked]>
Date: Thu, 15 Jan 2015 20:30:33 +0100

> from the server to client.

Wenbo,

I'm not saying that PP is not needed.   It looks well designed for purpose
and that is pushing associated resources to a HTTP request. PP is one of
the key features in HTTP2 that make it worthwhile deploying now despite all
it's warts.

What I don't think it is good for is replacing long polling as a way of
providing a server to client messaging transport.  That is what websockets
has been designed for and we should look to how websockets can be well
carried over HTTP2 rather than how we can trick HTTP Push into being a
messaging transport for non HTTP messages.

cheers

---

From: Wenbo Zhu <[email-masked]>
Date: Thu, 15 Jan 2015 11:42:45 -0800

On Thu, Jan 15, 2015 at 11:30 AM, Greg Wilkins <[email-masked]> wrote:

> providing a server to client messaging transport.
>
Agreed. Also note that long-polling is not necessarily the most efficient
way for providing server to client messaging, i.e. the RTT overhead is a
problem of long-polling, not HTTP/2.

> That is what websockets has been designed for and we should look to how
> websockets can be well carried over HTTP2 rather than how we can trick HTTP
> Push into being a messaging transport for non HTTP messages.
>
> cheers
>
>
>
> --

---

From: Mike Bishop <[email-masked]>
Date: Thu, 15 Jan 2015 19:52:42 +0000

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:[email-masked]]
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 <[email-masked]<mailto:[email-masked]>> 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 <[email-masked]<mailto:[email-masked]>> wrote:

--
Greg Wilkins <[email-masked]<mailto:[email-masked]>>  @  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.

---

From: Wenbo Zhu <[email-masked]>
Date: Thu, 15 Jan 2015 12:05:33 -0800

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 <[email-masked]>
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 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)
>
>
>
> *From:* Wenbo Zhu [mailto:[email-masked]]
> *Sent:* Thursday, January 15, 2015 11:24 AM
> *To:* Greg Wilkins
> *Cc:* HTTP Working Group
> *Subject:* Re: Server Push used for long polling
>
>
>
>
>
>
>
>   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?
>

---

From: Greg Wilkins <[email-masked]>
Date: Thu, 15 Jan 2015 21:55:03 +0100

> sending anything after the initial request)

This one is probably better likened to server-sent-events, which is
effectively just a HTTP response content type.

Websocket should be likened to a long-lived client initiated stream without
HTTP semantics that exchanges messages in both directions.

your other characterisations are spot on.

cheers

---

From: Mike Bishop <[email-masked]>
Date: Thu, 15 Jan 2015 22:06:37 +0000

You’re correct – that’s more equivalent.  But I’ve seen WebSockets used in the same way, even though it has broader capabilities.

From: Greg Wilkins [mailto:[email-masked]]
Sent: Thursday, January 15, 2015 12:55 PM
To: Mike Bishop
Cc: Wenbo Zhu; HTTP Working Group
Subject: Re: Server Push used for long polling

On 15 January 2015 at 20:52, Mike Bishop <[email-masked]<mailto:[email-masked]>> wrote:

•         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)

This one is probably better likened to server-sent-events, which is effectively just a HTTP response content type.

Websocket should be likened to a long-lived client initiated stream without HTTP semantics that exchanges messages in both directions.
your other characterisations are spot on.
cheers

---

From: Greg Wilkins <[email-masked]>
Date: Thu, 15 Jan 2015 23:22:53 +0100

On 15 January 2015 at 23:06, Mike Bishop <[email-masked]>
wrote:

> You’re correct – that’s more equivalent.  But I’ve seen WebSockets used in
> the same way, even though it has broader capabilities.

True,

The problem with server sent events is that there is no guarantee that an
intermediary will forward the content in chunks.   A caching proxy might
try to cache the entire response.

So websocket is preferable if it is able to connect.    Never really
understood why W3C went for two such similar mechanisms in HTML5 when
websockets can do the job of both.

cheers

---

From: Wenbo Zhu <[email-masked]>
Date: Fri, 16 Jan 2015 01:08:37 -0800

On Thu, Jan 15, 2015 at 2:22 PM, Greg Wilkins <[email-masked]> wrote:

>> You’re correct – that’s more equivalent.  But I’ve seen WebSockets used
>> in the same way, even though it has broader capabilities.
>
>
> True,
>
SSE also assumes long-polling, to avoid the buffering problem, IIRC.

> websockets can do the job of both.

We've created an informal survey doc (no nomenclature) on the gaps of HTTP
and WebSocket protocols ...
http://www.ietf.org/mail-archive/web/hybi/current/msg10580.html ...

Comments welcome.