I don't think performing a clean shutdown for misbehaving clients is that important, as they are misbehaving anyway. The only thing were it helps is for debuggi

I don't think performing a clean shutdown for misbehaving clients is that important, as they are misbehaving anyway. The only thing were it helps is for debugging the misbehaving application: The developer can see the error message and see something got wrong instead of only seeing a closed connection. In doubt closing the connection is probably always the simplest way to handle invalid situations, as libraries will always have to deal with that situation. Handling close/shutdown/goaway messages is much harder. I also don't consider frames which are received for already reset streams as a big issue. Just ignore them if they are for an unknown stream ID which is lower than the highest established one. However I agree there are a few rough edges in the HTTP/2 spec. The worst one for me are race conditions around SETTINGS negotiations. If one implementations wants to use a low window size or HPACK buffer size it must still cope with the fact that the remote might send more data before it knows about it - which it can only answer with a stream reset. This in turn might cause many clients to assume that the server is not working or shutting down and to create a new connection and try the same again. The only sensible way for SETTINGS in my opinion is to use the default settings or higher ones - which are unfortunatly so high that it makes HTTP/2 a poor fit for embedded or IoT applications, where it could otherwise shine due to the less demanding binary protocol. The other thing that I don't like too much are the headers in special header frames without flow control. Getting overall flow control correct (and avoiding that attackers can exploit this) is hard. And from a layering perspective it would have been much clearer if there would have been a lower layer which allows to create flow-controlled multiplexed byte streams and a higher layer which defines on how to transport headers and body data inside these streams. Now we have one big HTTP/2 layer which covers everything. But I guess that was done to get HPACK working. HPACK itself is IMHO ok.