- From: Greg Wilkins <gregw@intalio.com>
- Date: Mon, 11 Aug 2014 10:07:07 +1000
- To: Martin Thomson <martin.thomson@gmail.com>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>
Received on Monday, 11 August 2014 00:07:35 UTC
On 8 August 2014 03:28, Martin Thomson <martin.thomson@gmail.com> wrote: > > No way anyone would do that... > > https://tools.ietf.org/html/draft-thomson-webpush-http2-00 How creative :) So I thought about this a bit more and I don't think such schemes are as vulnerable to unknown timeouts as HTTP/1 long polling. The problem with long held HTTP/1 long polls is that sometimes when intermediaries timeout a connection they just go dark - never send a FIN or RST and the client ends waiting forever for a response that will never come. With a long h2 stream, it can't silently go away (unless the whole connection does), so I'm now thinking that we don't really need to clarify this significantly. If the client receives a 4xx response or a reset stream, it will know the long held stream is over and initiate a new one if it wishes to remain connected to the push channel. cheers -- Greg Wilkins <gregw@intalio.com> http://eclipse.org/jetty HTTP, SPDY, Websocket server and client that scales http://www.webtide.com advice and support for jetty and cometd.
Received on Monday, 11 August 2014 00:07:35 UTC