I just read the mailing list post that was referenced in the article (http://mailman.nginx.org/pipermail/nginx-devel/2016-May/0082...) and found nginx flow control handling also quite peculiar there. Setting the initial flow control window to 0 and then increasing it based on content-length will increase the latency a lot and opens the window for lots of interoperability bugs. E.g. because the client already starts a stream and sends data (based on the default flow control window), which then gets rejected and which might not be retried (depending on the client libraries implementation).
Would be interesting to know what nginx does when it receives no content-length header, which is also valid.
From reading and implementing the HTTP/2 spec the setttings negotiation is the biggest weak spot in opinion, because it represents a big race condition where the expectations of client and servers probably won't match. I would have preferred it if they would either have put in a mandatory wait for SETTINGS ACK until streams can be acknowledged or if the default settings (window size, HPACK table size) would be very low and could only be increased during negotation. With the given HTTP/2 spec I would most likely try to be conservative as a library or application author and just announce/use the default settings or bigger ones in order to avoid compatibility problems. For most server this should be possible. However for constrained devices lower default settings would have been preferrable.
Yeah, I agree that for constrained devices this is somewhat problematic, though I'd say the only big concern there is header table size. Even that can be coped with, worst-case by just enforcing the lower-limit from the get-go and GOAWAYing if the client violates it.
But yes, nginx's HTTP/2 implementation is really quite strange to me.
Would be interesting to know what nginx does when it receives no content-length header, which is also valid.
From reading and implementing the HTTP/2 spec the setttings negotiation is the biggest weak spot in opinion, because it represents a big race condition where the expectations of client and servers probably won't match. I would have preferred it if they would either have put in a mandatory wait for SETTINGS ACK until streams can be acknowledged or if the default settings (window size, HPACK table size) would be very low and could only be increased during negotation. With the given HTTP/2 spec I would most likely try to be conservative as a library or application author and just announce/use the default settings or bigger ones in order to avoid compatibility problems. For most server this should be possible. However for constrained devices lower default settings would have been preferrable.