Google Chrome Will Adopt HTTP/2 In the Coming Weeks, Drop SPDY Support

An anonymous reader writes: Google today announced it will add HTTP/2, the second major version of Hypertext Transfer Protocol (HTTP), to Google Chrome. The company plans to gradually roll out support to the latest version of its browser, Chrome 40, "in the upcoming weeks." At the same time, Google says it will remove support for SPDY in early 2016. SPDY, which is not an acronym but just a short version for the word "speedy," is a protocol developed primarily at Google to improve browsing by forcing SSL encryption for all sites and speeding up page loads. Chrome will also lose support for the TLS extension NPN in favor of ALPN.

Comments

Google's biggest problem is IH

[Anonymous Coward]

Google has a big case of "Invented Here" syndrome.
If Google started something, you can count on them dropping it.

Re:Google's biggest problem is IH

[AmiMoJo]

They are only dropping it because HTTP/2 is largely based on SPDY but with some improvements. SPDY was always a research project designed to produce something better than HTTP/1.1, and it has. Job done, the replacement is here and an official standard, so why maintain the old SPDY code?

More over, Google seems to be aggressively removing old stuff from Chrome to keep it from bloating too much. Netscape plugins have already gone. Blink dropped all the compatibility stuff in Webkit for old systems and browsers. My bet is that Flash will be removed in a year or two as well.

Re:1/2 requests,2x throughput, stop POST-Redirect-

[Chalnoth]

It's pretty easy to get around this issue with JavaScript, e.g. by using Angular. I think this is less a problem with the HTTP protocol and more a problem with website design.

Re:Might as well redesign HTML as well

[Anonymous Coward]

HTML is horribly trivial to do via a database and templating.

If it wasn't for how broken JS was in what it could - and can still - do, JS would be almost 100% used to make websites instead of actually manually writing crappy markup.
HTML should have died years ago. Just like any XML storage system. It is a god-awful eyesore.
Templating is a far saner method of creating websites. (which is why it has become a major standardized feature in HTML5)
JS-generated is even better in that regard. (unless you are a library-using moron. Nice overhead you have there.)
Binary, maybe a step too far, but storage-wise and CPU-wise, it would be immensely more efficient.
But it is a bit too late now when a good portion of people have reasonably fast connections. It still doesn't mean that it isn't a good thing to pursue. Under 2 billion people even HAVE access. Extremely-low bandwidth is a Good Thing. (even more so for SERVERs)
There has been many attempts of making a compressed, compact or binary version of HTML (I even made a crappy attempt I should upload some day), but none caught on for obvious reasons: it is extremely niche.

JS itself needs to be split up.
DOM-related JS should be one major chunk of it for one, which only needs the ability to create, delete, order and anything-else node related.
This would instantly cut out 100% of abusive JS if you blocked other stuff, but still allow for interactive websites, EXACTLY WHAT WAS WANTED.
The whole data verification thing is one of the most abused things in JS because so many crappy developers never checked their data server-side, leading to the billions of hacks that have happened over the years.
But security has dropped in to a not-even-tertiary consideration when it comes to webdev these days. Shame since at the beginning of HTML5s development, security was a primary facet of it, rewriting practically every spec with security in mind.
The biggest section that needs tidying up STILL is resource requesting. Biggest, most insecure area in webdev there is. It is a pure disaster.
Iframes are about the only thing that has gotten any of that HTML5 goodness, but nothing else has been even touched besides the 3 different offline application specs.

Of course, I am going to get some semantics nerd come in and cry about how you should separate your stuff.
Or worse, some XHTML fanboy. Literally the worst thing to happen in Webdev. Thank FUCK XHTML2 died.

Re:Might as well redesign HTML as well

[JWSmythe]

Well, it could be. That's not necessarily a good idea.

I did work under someone once who thought the future of web hosting would be to store all data in compressed blobs in databases. He had read somewhere that databases were faster than filesystems, and some other nonsense that made it sound like a good idea. Luckily, he never tried to implement it.

Re:1/2 requests,2x throughput, stop POST-Redirect-

[Qzukk]

I think this is less a problem with the HTTP protocol

Using onload="history.pushState(null, null, '/user/31813812');" certainly works, but now pushing the "back" button is the landmine instead of pushing refresh (not to mention users that turn off javascript). Being able to use javascript to pretend you're doing what the HTTP procotol should have done does not make it not a problem with the protocol.

That said, the HTTP/1.1 protocol itself is fine. A user agent ought handle a 201 Created response exactly like this as a side effect (OK, so the response body is technically not a listing of places you can get the created object from, but it's supposed to be displayed to the user either way), but there are zero browsers implementing the Location part of it. Adding a response code explicitly for the purpose of "here is a response to display to the user right now, if the user wants to reload it, request this URL instead" would hopefully get browser developers to say "oh, I see why we're doing this" and do it. Doubly so when they're writing a new implementation for a new protocol. At this point, I'd argue that the best thing to do would be to add something like "311 Content With Future Redirect" so that browsers that don't implement it continue with 3xx POST-Redirect-GET semantics (losing nothing) and browsers that do understand it will work.