[lazyloop]

HTTP/2 is a bad protocol, that much is clear by now. Luckily most of us won't have to deal with it, because it will be deployed merely as an optimization, with a new generation of reverse-proxy servers, like H2O. https://github.com/h2o/h2o

[andrewstuart2]

Care to at least explain why you think it's a bad protocol?

[lazyloop]

Poul-Henning Kamp (the author of Varnish) explained it best. http://queue.acm.org/detail.cfm?id=2716278

[jamescostian]

Do you have another explanation which hasn't been torn apart by Hacker News commentators already? As someone who would like to avoid going to the trouble to implement HTTP2, I'm not being sarcastic - I truly want to know why HTTP2 is so bad, and I want to read it from someone who backs up their words with cold-hard facts

[frankzinger]

Have a look at the W3 HTTP WG mailing list. PHK and others voiced all of their objections there in detail over a long period, and you can also read the rest of the WG's responses: https://www.w3.org/Search/Mail/Public/advanced_search?keywor... (all of PHK's posts to the list, in chronological order).

[lazyloop]

This for example happened in the HTTP working group earlier today, the whole thing was rushed and the known flaws just keep adding up. https://lists.w3.org/Archives/Public/ietf-http-wg/2015JanMar...

[asuffield]

I followed the thread a little further, and the response seemed reasonable: experiments were run on this idea, it didn't seem to help, and nobody (including phk) has offered any further evidence to the contrary since then.

I think you need to expand a little more on why you feel this is a "known flaw".

[bsdetector]

A 60 page document to explain how to compress text name/value pairs that are mostly unchanged between requests is "reasonable"?

A static compression table with proxy authentication fields in it, as if the network between your browser and LAN proxy is somehow the bottleneck, is reasonable?

This is a most over-engineered protocol, one where nobody knows how tables were constructed or from what data and nobody can quantify what the benefits its features will really be. For instance how much is saved by using a huffman encoding instead of a simple LZ encoding or simple store/recall or not compressing it? Nobody knows! Google did some magic research in private and decided on the most complicated compression method, so therefore HTTP/2 must use it.

This HTTP/2 process is insane.

[mark242]

"As someone who would like to avoid going to the trouble to implement HTTP2 (...)"

Good luck with that. Google has been incredibly adept at using the leverage of their search engine to make webmasters adhere to best practices. ("mobile friendly" e-mails lately, anyone?) Once HTTP/2 lands as a default in Chrome, Apache, Nginx, and Netty, of course they'll push HTTP/2-friendly sites higher in search results.

[stephenr]

I think you meant to say "Googles definition of best practices"

[DannyBee]

Except, as HN has mostly ripped him apart for, his argument is very weak at best.

He goes into zero detail, and where he does, it says things like "likely to increase CO2 consumption"?

Seriously?

[IvyMike]

HN discussion: https://news.ycombinator.com/item?id=8850059

[jimktrains2]

Because it doesn't solve any problems except page loading speed. There are other things that people care about and the added complexity of implementing Layer 4 in Layer 7 make it even more of a monstrosity.

I put this in another comment in the above:

* Better authentication

* More secure caching

* Improved ability to download large files

* Better methods to find alternate downloads locations

* Making each request contain less information about the sender

* Improved Metadata

I brain-dump a bit here: https://github.com/jimktrains/http_ng

[lazyloop]

How is it that sensible comments like this keep getting downvoted?

[jimktrains2]

I just wish people would actually discuss their opposition to any statement I made rather than just downvoting, but so it is.

[mattbessey]

Well he doesn't need to, by his own proclamation there's no arguing! /s

[megaman821]

It is not a bad protocol for what is in there, it is bad for what is not.

It seems like it was built for the big players to eek out 5% more performance. How about the average website? What is in there help standardize authentication? What is in there to help protect privacy?

In the end it looks more HTTP 1.2, with header compression being the only new feature. The rest of what makes up HTTP 2 is basically implementing a new transport layer protocol at the application level.

[MichaelGG]

On tests on a rather average SPA site I worked on, adding the letters "spdy" to the nginx config produced double-digit% performance benefits.

Keeping it backwards compatible with HTTP 1.1 as far as semantics means it will actually get real adoption, very easily, as you can seamlessly enable it via middleware without changing app code anywhere.

I don't know what you mean to "standardize auth", but seeing what a clusterfuck OAuth2 turned into, it'd probably guarantee HTTP2 wouldn't ship for a long time, then ship a mess.

To protect privacy, major browsers plan to only support HTTP2 over TLS. That should be a major incentive for more websites to force TLS. Pretty clever, sorta, even if we might have technical objections to requiring TLS for no "real" reason.

[megaman821]

Double-digit performance for a bunch a little files probably. It is less than 5% when compared against concatenated CSS and JavaScript, image sprites, and domain sharding. Its great that HTTP2 saves a build step but it is hardly going to make the web a lot faster.

[zackelan]

> help standardize authentication

> help protect privacy

I think this is sort of answered by the headline - "HTTP/2 is done".

If they had succumbed to the second-system effect and added every bell and whistle that every HTTP user would ever want, there would be an endless period of bikeshedding and it would be years before you could even call the spec "done".

They seem to have taken a more conservative approach - changing enough that HTTP 1.2 wasn't accurate, but also not going all-out and trying to define a post-Snowden quantum-computing-based KSTP (kitchen sink transport protocol).

[jimktrains2]

Or they could have solved actual problems people have like the lacking of privacy features and the problems with HTTP Authentication currently.

[velox_io]

I agree, and have no problem with a binary protocol (you always have to go down to the byte layer if you want performance networking or storage). But they could have made it much easier, just look at the spec on http://json.org (BSON isn't that bad either). I sometimes wonder if RFC's are designed to be human readable..

I think 5% is a very conservative figure. HTTP has massive overhead for lots of small file (look at the http joke), even with browser caching it still requires multiple round trips (empty TCP frames!) and compression has a negative impact on small files (overhead & bigger files)

The problem is, that to use this effectively (sending a page, plus any CHANGED assets down a single request). Requires quite a bit of work on not only the webserver, but also the application.

Another plus with reusing connections, is not having to re-authenticate every request.

[tptacek]

"Standardize authentication"?

[megaman821]

Well Basic Auth exists now, but it is unusable for most sites due to several well-documented shortcomings. Surely something could be done to improve upon it.

[tptacek]

The most important shortcoming of basic auth is the idea of building it into the protocol to begin with. Session authentication is superior to basic auth.

[Kalium]

Like kicking it up to the application layer?

[tveita]

You can add new authentication methods by defining the format of the authorization/authentication headers. OAuth 2 does it. The only thing you need is buy-in from application authors.

[megaman821]

This is mostly true but browsers treat Basic Auth special. To use Authorization Bearer headers you have to use JavaScript and perhaps localstorage. When using Basic Auth the browser caches your credentials and allows you to be authenticated without cookies and without JavaScript code. The only way you can use OAuth header authorization today is with JavaScript apps, Basic Auth works with normal server side apps.

[acdha]

> How about the average website?

It's actually much bigger for the average site which doesn't have Google's engineering team supporting hundreds of thousands of edge servers expensively pushed as close the client as possible and massive investment in front-end optimization. Think about how much complexity you can avoid taking on without needing to do things like sharding, spriting, JS bundling, etc.

[patrickmcmanus]

arbitrary levels of prioritized multiplexing within a functioning congestion control context is the killer feature of http/2.

header compression exists merely to enable that as an implementation detail.