Hacker News Reader

Comment by aarkX | Hacker News Reader

I just tried HTTP/2 on nginx 1.10.0 and got constant "client sent stream with data before settings were acknowledged while processing HTTP/2 connection" errors from many different client addresses. This was on a standard website with regular browser traffic.

View on HN

This is because nginx has some interesting assumptions about the HTTP/2 preamble works. See this mailing list thread[0] for discussion about it. See also the nginx bug[1].

The TL;DR is that nginx wants to do some weird stuff with flow control to avoid the need to do internal buffering. nginx is definitely outside the RFC here: what the client is doing is entirely acceptable.

[0]: https://lists.w3.org/Archives/Public/ietf-http-wg/2016AprJun... [1]: https://trac.nginx.org/nginx/ticket/959

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.

Reply on news.ycombinator.com