> 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.
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."
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.
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.
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.
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.
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.
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.