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