HTTP2 Stream timeouts?

[Greg Wilkins]

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.

[Martin Thomson]

Post by Greg Wilkins
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.

No way anyone would do that...

https://tools.ietf.org/html/draft-thomson-webpush-http2-00

[Greg Wilkins]

Post by Martin Thomson
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

[Michael Sweet]

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.

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