6 ms·
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
by lazyloop 12y ago
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 https://github.com/h2o/h2o
- andrewstuart2 12y agoCare to at least explain why you think it's a bad protocol?
- mattbessey 12y agoWell he doesn't need to, by his own proclamation there's no arguing! /s
- lazyloop 12y agoPoul-Henning Kamp (the author of Varnish) explained it best. http://queue.acm.org/detail.cfm?id=2716278 http://queue.acm.org/detail.cfm?id=2716278
- IvyMike 12y agoHN discussion: https://news.ycombinator.com/item?id=8850059 https://news.ycombinator.com/item?id=8850059
- DannyBee 12y agoExcept, 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?
- jamescostian 12y agoDo 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
- lazyloop 12y agoThis 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/0475.html https://lists.w3.org/Archives/Public/ietf-http-wg/2015JanMar...
- asuffield 12y agoI 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 12y agoA 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.
- frankzinger 12y ago> 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! It's not all about compression ratios. From the HPACK spec (https://http2.github.io/http2-spec/compression.html#rfc.section.1 https://http2.github.io/http2-spec/compression.html#rfc.sect...): 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.
- megaman821 12y agoIt 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.
- tptacek 12y ago"Standardize authentication"?
- megaman821 12y agoWell 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.
- Kalium 12y agoLike kicking it up to the application layer?
- tveita 12y agoYou 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 12y agoThis 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.
- jimktrains2 12y agoBecause 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 https://github.com/jimktrains/http_ng
- lazyloop 12y agoHow is it that sensible comments like this keep getting downvoted?
- jimktrains2 12y agoI just wish people would actually discuss their opposition to any statement I made rather than just downvoting, but so it is.