I got a copy of Paul-Henning Kamp's critique "HTTP/2.0 - The IETF is Phoning It In" off the ACM website before the link went dead. Here's a bit of what he said about it:<p>"Some will expect a major update to the world’s most popular protocol to be a technical masterpiece and textbook example for future students of protocol design. Some will expect that a protocol designed during the Snowden revelations will improve their privacy. Others will more cynically suspect the opposite. There may be a general assumption of "faster." Many will probably also assume it is "greener." And some of us are jaded enough to see the "2.0" and mutter "Uh-oh, Second Systems Syndrome."<p>The cheat sheet answers are: no, no, probably not, maybe, no and yes.<p>If that sounds underwhelming, it’s because it is.<p>HTTP/2.0 is not a technical masterpiece. It has layering violations, inconsistencies, needless complexity, bad compromises, misses a lot of ripe opportunities, etc. I would flunk students in my (hypothetical) protocol design class if they submitted it. HTTP/2.0 also does not improve your privacy. Wrapping HTTP/2.0 in SSL/TLS may or may not improve your privacy, as would wrapping HTTP/1.1 or any other protocol in SSL/TLS. But HTTP/2.0 itself does nothing to improve your privacy. This is almost triply ironic, because the major drags on HTTP are the cookies, which are such a major privacy problem, that the EU has legislated a notice requirement for them. HTTP/2.0 could have done away with cookies, replacing them instead with a client controlled session identifier. That would put users squarely in charge of when they want to be tracked and when they don't want to—a major improvement in privacy. It would also save bandwidth and packets. But the proposed protocol does not do this.<p>[He goes on to tear a strip off the IETF and the politics behind HTTP/2.0 ...]
Looking forward to when HAProxy support for HTTP/2 lands since they refused to implement SPDY support.<p>Here's a list of common servers support for SPDY/HTTP2: <a href="https://istlsfastyet.com/#server-performance" rel="nofollow">https://istlsfastyet.com/#server-performance</a>
HTTP/2 might have version 2 syndrome.<p>Another better way would have been keep SPDY, as there is usefulness there, separate and then on HTTP/2, to incrementally get there, and use an iteration of something like AS2/EDIINT (<a href="https://tools.ietf.org/html/rfc4130" rel="nofollow">https://tools.ietf.org/html/rfc4130</a>) which does encryption, compression and digital signatures on top of existing HTTP (HTTPS is usable as current but not required as it uses best compression/encryption currently available that the server supports). This standard still adheres to everything HTTP and hypertext transfer based and does not become a binary file format but relies on baked in MIME.<p>An iteration of that would have been better for interoperability, secure and fast. I have implemented it directly previously from RFC for an EDI product and it is used for sending all financial EDI/documents for all of the largest companies in the world Wal-mart, Target, DoD as well as most small and medium businesses with inventory. There are even existing interoperability testing centers setup for testing out and certifying products that do this so that the standard works for all vendors and customers. An iteration of this would have fit in as easily and been more flexible on the secure, compression and encryption side, and all over HTTP if you want as it encrypts the body.
Are there any good reverse proxies out there that support HTTP/2? Right now I'm using varnish, but I'd love to switch over to something supporting this.
Can someone explain to me the actual upside of header compression? I work on a fairly major educational site and calculating now our request + response headers comes out to 1,399 bytes. Gzipping them they come out to 1,421 bytes. A small net increase.<p>Am I missing something? Do some people have so many cookies that this makes a difference or something?
Unfortunately right now apache doesn't support HTTP/2 at all. There was a mod_spdy, but it's pretty much dead. Apache took it over from google some time ago, but since then nothing happened.
Does anyone know if Cloudflare has plans to implement HTTP/2? RIght now they support SPDY.<p>I found the answer from their blog:<p>"Part of the service CloudFlare provides is being on top of the latest advances in Internet and web technologies. We've stayed on top of SPDY and will continue to roll out updates as the protocol evolves (and we'll support HTTP/2 just as soon as it is practical)."
What happens if someone built a service based on it? Should they never trust browsers keeping alive even the shitty (in comparison to free and standardised HTTP/2) features? What's great about the web is that now 20 year old services still are working in the latest runtimes (browsers).
Does somebody has good nginx configurations for HTTP/2? Good that browser go this directions but at the moment I have no clue on how to implement HTTP/2 (is there a SPDY fallback?) on my nginx server :(
HTTP/2 is an ugly mess of taking something simple and making it more complex for minimal benefit. It could have been so much better than a binary mess.<p>As engineers, the ones that take simple concepts and add complexity, those are not engineers, those are meddlers.<p>It could be as long lived as XHTML.<p>I was hoping for more SCTP rather than a bunch of cludge on top of what is a pretty beautiful protocol in HTTP 1.1. Protocol designers of the past seemed to have a better long view mixed with simplicity focused on interoperability that you like to see from engineers.
Google just loves exerting their power. It will take more than Chrome devs declaring it a done deal to make this happen. The browser is only half the issue. Web servers must get on board for this to matter. Obviously Safari, FireFox and IE have some say in this too.
I'm not ever supporting HTTP/2. For something "monumental" enough to be called the whole second revision of HTTP, what have we really gained? A Google-backed "server push" mechanism and some minor efficiency additions? Add to that the fact that SPDY was pushed through as HTTP/2 because nothing else was ready.<p>Please.<p>Downvoters: although I don't usually do this, I'd ask you to enter into a discussion with me instead of just hitting the down arrow. Do you honestly think my discussion is worth being silenced?