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

[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.