Connection fatal HTTP/2 stream errors

We are currently working on improving Jetty's handing of stream errors and
I'm wondering what other server implementations are doing about stream
errors.

The issue is that there are many errors that can be detected during hpack
decoding, or soon after that could be handled with a RST_STREAM.  However
because of either the difficult and/or expense of needing to continue with
decoding the headers (to keep the hpack table state correct), we are
currently leaning towards treating all stream errors as fatal to the
connection.

Such errors that I have identified include are:

   - headers too large
   - upper case in header name
   - non US-ASCII character in header name or value
   - unknown scheme
   - non token bad method (spaces etc)
   - badly formatted authority and/or bad port number
   - bad path (eg non hex % encoded or bad character encoded)
   - bad status

Note that some of these checks could be done after hpack decoding, however
if we are storing fields in the Hpack table, we try to store the decoded
version of them rather than just the string.

We are looking setting an error state and continuing decoding, but in the
case of too large that is a bit counter productive.  So currently we are
thinking that any of these kinds of errors are going to result in a GO_AWAY
message as it is just too difficult to handle such errors deep inside hpack
decoding and continue.

But the down side of this is that you can easily send poison pills that
will kill a connection, which is pain if you are aggregating
connections.

Anyway, just wondering what other server implementations are trying to do.
If others are going to make efforts to keep connections open and just
ignore the bad streams, then I guess we will follow peer pressure and do
the same.

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.