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
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
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).
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".
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.
> 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!
SPDY [SPDY] initially addressed this redundancy by
compressing header fields using the DEFLATE [DEFLATE]
format, which proved very effective at efficiently
representing the redundant header fields. However, that
approach exposed a security risk as demonstrated by
the CRIME attack(see [CRIME]).
This specification defines HPACK, a new compressor for
header fields which eliminates redundant header fields,
limits vulnerability to known security attacks, and which
has a bounded memory requirement for use in constrained
environments. Potential security concerns for HPACK are
described in Section 7.
The Huffman code is optional and the spec says not to use it on sensitive fields (no mention of what those are). You can use a separate LZ on each header field, compressing really long headers and not having information leak between headers and the bodies. You think they tested that? Or did the people who didn't know about CRIME in the first place just react? Where are the numbers that show a static huffman code that was created from some unknown dataset at one point in time and can't be extended because there's only a single "compress or huffman" bit in the protocol is needed? Like I said, insane.
"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.
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
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.
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.
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.
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).
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.
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.
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.
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.
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.
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.
