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

[epyT-R]

Yeah, I understand that. It's just unfortunate. I'd like to see more standards enforce proper crypto.

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:Might as well redesign HTML as well

[BarbaraHudson]

Don't give Lennart Poettering any more bad ideas. PLEASE !

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-

[Sowelu]

What? POST is the non-idempotent one. See the table in http://tools.ietf.org/html/rfc..., section 8.1.3

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.

Luke!

[Etherwalk]

Color me paranoid but this sounds like Google is going out of there weigh too weeken encryption in transport. For "national security" in homeland, amirite? God save the homeland!

I feel a great disturbance in the internet, as if millions of spellcheckers cried out in terror and were suddenly silenced.

Re:Backdoor collusion

[swillden]

Color me paranoid but this sounds like Google is going out of there weigh too weeken encryption in transport. For "national security" in homeland, amirite? God save the homeland!

Huh?

Google has pushed continually to increase the usage and the security of transport encryption. Google's SPDY, the basis for HTTP/2, was designed without any unencrypted mode; it's all TLS all the time. The IETF insisted on making unencrypted transport optional in HTTP/2, but you can be sure that Google won't take that option. Google's next-next generation replacement for HTTP, called QUIC, is a more radical redesign build on UDP rather than TCP, and also has no unencrypted mode. Encryption is baked so deeply into QUIC that it basically can't be removed. Google has also been instrumental in pushing the industry off of various weak versions of SSL/TLS, most recently leading the charge in removing SSL3 support. It was Google's researchers that brought Heartbleed, BEAST, CRIME and POODLE to light. Google Chrome was the first widely-used browser to implement certificate pinning, which was instrumental in the quick discovery of the DigiNotar CA compromise. Google engineers are working to develop a more final solution to the CA trust problem with the Certificate Transparency project. I could go on and on with all the great encryption-related work Google is doing (including my own small contributions to strong crypto on Android).

I think there's an extremely compelling argument to be made that Google is doing and has done more for internet transport encryption security than any other entity for quite some time.

(Disclaimer: I'm a Google security engineer, not a Google spokesperson. The above is not an official statement but only my -- very strongly held -- personal opinion.)