Using nghttp2 to work around Nginx HTTP/2 bugs | Hacker News Reader

Using nghttp2 to work around Nginx HTTP/2 bugs

blog.crashed.org

74 pointsokket26 comments

> Specifically, the "stable" version of nginx can't do HTTP/2 POST on any current browser without nginx dropping and resetting the connection.

I hit this bug a while back. StackOverflow responders said I was crazy. I went to trac.nginx.org and while preparing a bug report, I saw that it had already been reported just a day prior. Felt good knowing I was not crazy, and there was a bug in nginx.

Do you have this SO post?

I second this. A quick Google search didn't reveal the SO post, so now I'm more curious.

Specifically, the "stable" version of nginx

Is there any reason not to use mainline? This is what nginx recommend, it's not a -dev at all. I haven't been bitten yet anyway.

http://nginx.org/en/linux_packages.html

Exactly, nginx stable is more like a LTS branch. See https://www.nginx.com/blog/nginx-1-6-1-7-released/ which also mentions "Note that stable does not mean more reliable or more bug-free. In fact, the mainline is generally regarded as more reliable because we port all bug fixes to it, and not just critical fixes as for the stable branch. [..] We recommend that in general you deploy the NGINX mainline branch at all times."

I've read that Cloudflare open sourced their nginx http/2+spdy implementation for nginx https://blog.cloudflare.com/open-sourcing-our-nginx-http-2-s... I would rather give Cloudflare's modified nginx a shot than not using nginx at all. https://github.com/cloudflare/sslconfig/pull/36

For those of you that absolutely need strong HTTP/2 support, I highly recommend checking out H2O[0]. It has much less features than NGINX, but is very lightweight and has good performance with low resource footprint.

[0]: https://h2o.examp1e.net/

I was looking at that. It doesn't seem to have WSGI support for Python apps, though.

.. or just good old Apache.

mod_http2 is still considered experimental, and the source of 2 of the 3 vulnerabilities announced for 2.4 this year.

https://caddyserver.com/ ! With Let's Encrypt built-in.

interesting project. Never heard of it before.

nghttpx could be used to support server push (see https://nghttp2.org/documentation/nghttpx.1.html#server-push), which nginx does not currently support (see https://stackoverflow.com/questions/33537199/does-the-nginx-...) — neat!

Wait, so the advice to fix my end-all-be-all HTTP proxy application is to run another proxy in front of it?

Why not just turn off http2 support in config until stable has good support?

Exactly what I was wondeirng. Can one really speak of a need for HTTP2 rather than a yearning desire, at most?

Yes, anybody who runs a large site and gets far better performance out of it for the majority by now of clients who support it.

I'm replying to your post, specifically, but the other comments seem to be making the same point: HTTP2 confers a performance advantage.

So I repeat my question: is this speed advantage stricto-sensu necessary? Why can't one "just" spin up a few more EC2 instances until this is fixed?

Is there a case in which HTTP2 is necessary, and HTTP1 just won't cut it? I think that's the sense of the original question, and I think it's a valid question when talking about hacking one's way around bugs that are going to get fixed anyway.

I'm open to being wrong about this, but I'm surprised at the resistance to this question.

The perf advantage is in user loading times. HTTP1 won't cut it, and no amount of hardware on the server will, either.

Just adding "SPDY" to nginx on some customer sites was enough to reduce load times by double digit %. (10-30 IIRC)

I think SPDY might be a workaround for a bit; it's still supported this year right?

>I think SPDY might be a workaround for a bit; it's still supported this year right?

No, Nginx dropped it (they only offer HTTP2 since 1.9.5) and Chrome dropped it from the client too this year IIRC.

HTTP/2 is ~10% https://w3techs.com/technologies/details/ce-http2/all/all

HTTP/2 is growing faster than IPv6 https://w3techs.com/technologies/comparison/ce-http2,ce-ipv6

I'm not really sure that kind of comparison makes much sense.

HTTP is a layer 7 protocol, IPv6 is layer 3. Rolling out a layer 3 change is an entirely different thing and requires not just the two parties using it to be adapted, but everything and everyone in between. That plus a general lack of a positive business case for v6 has meant tremendously slow adoption.

HTTP/2 support on the other hand has been quickly added to major browsers and with a number of big players like Google and social media providers supporting it those numbers would rise much more quickly. Cloudflare and similar providers would skew those metrics too since they can accept the connection over HTTP/2 from your client but still talk 1.X to the backends.

I saw a nice performance boost on my webapp and it was basically "free".

There are quite a few studies that show that revenue drops proportional with performance, i. e. if people have to wait 4seconds instead of two, you're leaving half your revenue on the table.

As others have mentioned, there are real performance gains to be won on both client and server, but does that make it a necessity? No.

Perhaps the more compelling reason you're looking for is that HTTP2 significantly affects best programming practice.

Well-established patterns of HTTP become antipatterns under HTTP2, e.g. image sprites, concatenating files, domain sharding. Most of those originated as messy hacks to get around limitations of HTTP and introduced unwanted complexity into both development and deployment of web services. Thanks to HTTP2, they are no longer needed and in fact can actually reduce performance now that the standard handles the simple case effectively.

Upgrading therefore makes for cleaner architecture as well as the obvious perf boost. The longer you hold off, the longer you have to hold off making those updates and pushing them into production. (And again, it's of course not a necessity in the same sense a security or compliance update would be. But it's another very good reason imo.)

While these patterns are not needed anymore, most of them are not antipatterns in http/2 reducing requests still helps you by getting rid of http headers. Most of the time it is not harmful, it just does not give you the performance plus it gave you in http 1.

Reply on news.ycombinator.com