3 ms·

the worst thing of the spec is that it writes stuff like: An endpoint might choose to close a connection without sending a GOAWAY for misbehaving peers. B

by merb 10y ago

the worst thing of the spec is that it writes stuff like: An endpoint might choose to close a connection without sending a GOAWAY for misbehaving peers. But it does not define how a misbehaving peer could look a like. Or WINDOW_UPDATE or RST_STREAM frames can be received in this state for a short period after a DATA or HEADERS Actually it's really really hard to get such a time right. Since it's extremly depending on the client. Also the http/2 state machine is extremly complex vs. the statefulness of a http/1 client (no state machine at all). Also the spec gives a lot of weight to the server/client where they can treat some errors either as a stream only error or as a full error (i.e. goaway, reconnect/disconnect). Not sure if it is good at all. Push Promises are probably not even useful to the most servers/users. And also have a flaky specification. It's okai to send them between data frames, but it makes no sense to do it. WebSockets don't work over http/2 and even with a extension they would disconnect every 31-bit/2 streams (or less). I think that http/2 is a good thing, but at the moment I would rather count on http/2.1 that will get everything correct and made stuff significantly easier. P.S.: Hpack is probably the easiest to implement/get right

Matthias247 10y ago
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.

by merb 10y ago

Matthias247 10y ago

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.