Re: HTTP2 Stream timeouts?

[Michael Sweet <[e-mail]>]

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 <[e-mail]> 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 <[e-mail]> 
> 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