You can think differently, of course, but after looking at this (https://news.ycombinator.com/item?id=8824789) I reconsidered my previously positive view on it.
(Also, I'd love a cookie)
Snark aside, it's a standardized way of allowing different architectural patterns that can benefit use cases we haven't even seen yet. Yes, those architecture patterns currently benefit large corporations, but they're not being implemented at the expense of anything else. HTTP is a remarkably complete and flexible protocol.
What other benefits were you expecting to see that aren't already part of HTTP/1.1?
* no more easy debugging on the wire
* another TCP like implementation inside the HTTP protocol
* tons of binary data rather than text
* a whole slew of features that we don't really need but that please some corporate sponsor because their feature made it in
* continuing, damaging and absurd lack of DNS and IPv6 considerations
* most notably the omission of any discussion of endpoint resolution
And as I said in another thread: yes. Calling it HTTP/1.2 would actually have made me a little happier. This isn't the next new, big thing. This is a minor improvement, if not a minor regression.
Also WTF does HTTP have to do with DNS, DNSSEC, and IPv6? Talk about layering violations...
Also, I think a total wire-protocol change warrants a major version number increase, not that it matters at all.
And honestly, IPv6 is probably the biggest "big corporate" feature out there. Any big company providing access to more than 16 million devices (and yes, they do exist) has a very urgent need since the 10.0.0.0/8 network only contains ~16 million addresses.
At the end of the day, it's only a standard. As proven by SPDY, "big corporations" like Google are going to implement whatever the heck they want to, then ask for it to be included in the standard. I'm all for a system that makes it easier for companies to get their technologies standardized as part of an open standard - they're spending the investment dollars, but we all benefit from the capability.
Header compression, server push and proper multiplexing (which avoids all the problems with pipelining) are all features most applications will benefit from.