- From: Michael Sweet <msweet@apple.com>
- Date: Sun, 10 Aug 2014 09:20:41 -0400
- To: Greg Wilkins <gregw@intalio.com>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>
I think we do still need a reminder reference in the HTTP/2 spec (3.4 still applies, send a RST_STREAM to close an idle stream), and that a server can send a GOAWAY frame after a period of inactivity on the whole connection. On Aug 7, 2014, at 2:01 AM, Greg Wilkins <gregw@intalio.com> wrote: > > I'm wondering if we need to say something about stream timeouts in the draft? > > With HTTP/1 most servers/clients/intermediaries will timeout connections if there is no IO activity for a period. Some will also apply a total timeout for a complete message to arrive. Section http://tools.ietf.org/html/rfc7230#section-3.4 describes how such timeouts are handled. > > With HTTP/2, the IO activity style timeout no longer applies, as there can be lots of IO activity on other streams while a particular stream is stalled forever. Total timeouts can still apply. > > So is section 3.4 sufficient to describe behaviour for h2? or should we also set some expectation as to the possible longevity (or otherwise) of inactive streams? > > Note that I can see at least one use-case for long held idle stream. Basically it is the long polling use-case of "protocol abuse". Frameworks will still long poll over http2 and would benefit from a bit more certainty over how long an idle stream can be expected to live. I can even imaging more creative protocol abuse where a long held stream is used to enable push promises to be sent, thus allowing arbitrary resources to be sent from server to client. > > > > -- > 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. _________________________________________________________ Michael Sweet, Senior Printing System Engineer, PWG Chair
Received on Sunday, 10 August 2014 13:21:14 UTC