Google Chrome Will Adopt HTTP/2 In the Coming Weeks, Drop SPDY Support 88
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.
Re: (Score:2)
I guess you don't know that "Plain Text" is just a subset of binary - one that happens to have a generic class of applications that know how to interpret it (Text editors).
Which is why FTP clients have a "Text" and "Binary" transfer method, sorry this brain fart dates back to the 70s if not further. Data is either analog or digital, digital data is either text or binary implying you can meaningfully edit it in a text editor. The results are not always sane as a Word/OpenOffice file is "binary", an XML file is "text" but that's the de facto jargon in computers.
Re: (Score:2, Informative)
In this case, "text" is short for "automatic conversion to/from ascii with CRLF line endings". That is, the sending side will convert from the local format to ascii with CRLF, and the receiving side will convert from ascii with CRLF to the local format.
The local format may be ascii with LF, or even EBCDIC.
Re: (Score:2)
Re: (Score:2, Interesting)
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
Re: (Score:3)
I think you need to think it through again. First you begrudge the few extra bytes for the markup (images and such are the bulk of http traffic, not the markup) but then you deride client side sanity checking which can save multiple transactions? Yeah, the server side should check sanity for security and the client should do it for speed and efficiency (and reducing wasted server load). Eliminate the client side sanity checking and you'll get no checking at all most of the time.
HTML is here and it works. Th
Re:Might as well redesign HTML as well (Score:4, Interesting)
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:Might as well redesign HTML as well (Score:5, Funny)
Re: (Score:2)
Why not just distribute native binaries from an ftp site and be done with it? Then we don't need the browser, slow interpreted languages like php and javascript, and 40-100MB of ram just to display a page of text and some gfx. The binary connects to your database over TCP.
Re: (Score:2)
Re: (Score:2)
perhaps a binary data format, representing data in a database. This should be the next step.
And then we replace Javascript with Swift.
I'm hoping you forgot the /s
Re: (Score:2)
Google's biggest problem is IH (Score:4, Interesting)
Google has a big case of "Invented Here" syndrome.
If Google started something, you can count on them dropping it.
Re: (Score:1)
HTTPv2 = spdy
Re: (Score:2)
Not really, it has a number of modifications, including dropping mandatory encryption.
Re: (Score:3)
I don't see that as an improvement.
Re: (Score:2)
It is if you have constraints on server resources. Encryption costs CPU time, and it requires even more if you use forward security as people tend to since the Snowden revelations. If you're serving lots of public assets (think 4chan image CDN), requiring encryption would greatly increase the CPU resources you need.
Re:Google's biggest problem is IH (Score:4, Insightful)
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 (Score:2)
But who's prepared to pay more (even just in terms of ad impressions) just so they can see their cat pictures? No-one's arguing that security isn't essential for your bank or whatever, but all this "free" shit actually costs money to deliver, and encryption would make it cost more.
Re: (Score:3)
At the same time, it makes no sense to hire armed guards to watch over a stack of flyers meant to be free to the public.
Re: (Score:2)
Re: (Score:2)
I agree. Currently Chrome, IE and Firefox only support http/2 over TLS.
Just because the standard doesn't enforce encryption, doesn't mean that servers and clients can't mandate encryption.
http://en.wikipedia.org/wiki/H... [wikipedia.org]
Re:Google's biggest problem is IH (Score:4, Interesting)
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.
1/2 requests,2x throughput, stop POST-Redirect-GET (Score:3, Insightful)
Will HTTP/2 have a response code that will cause the browser to display the page that is returned from the server AND change the "current url" (for bookmarking, refreshing etc) to an alternate Location? POST to /createnewuser, display the response immediately with the URL of /user/3813812. Refreshing loads /user/3813812, not re-POSTing to /createnewuser.
Right now, the current paradigm of having to either redirect every single POST request to a new URL or risking users too stupid to know that they really need to not press reload on the page after saving something is a drain on server resources one way and support resources the other.
Re:1/2 requests,2x throughput, stop POST-Redirect- (Score:5, Interesting)
Re:1/2 requests,2x throughput, stop POST-Redirect- (Score:5, Interesting)
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.
Re: (Score:2)
You could just only return the data required from the POST request and use client side code to render it, instead of reloading the entire page. Saving bandwidth, server-side processing and rendering time.
Re: (Score:2)
Nothing is ever so simple. There are situations where you *want* POST to reprocess and refresh, such as when presenting statistics for a server. As a result the prototocol doesn't restrict you to one POST per page, and leaves it up to the server programmer to implement request id's to prevent duplicate execution when it needs to be prevented, rather than limiting the protocol to only allowing that behaviour.
Re:1/2 requests,2x throughput, stop POST-Redirect- (Score:4, Informative)
What? POST is the non-idempotent one. See the table in http://tools.ietf.org/html/rfc... [ietf.org], section 8.1.3
Re: (Score:3)
Post is the only non-indempotent of the major http verbs. Its one of the core difference between Post and Put and why when you create a new resource without a natural id, you use post, not put...
Re: (Score:3)
Post is the only non-indempotent of the major http verbs. Its one of the core difference between Post and Put and why when you create a new resource without a natural id, you use post, not put...
What happens if you POST to a server and the response is lost? How does client know it was processed or not? The answer is you always need some kind of id/token/big word because non-idempotwhatever is not actually possible.
The only thing POST is... is worthless... defective by design without specific and unnecessary application logic to deal with consequences of HTTP's total lack of a commitment procedure.
Re: (Score:2)
Erm, but in that instance POSTing then doing a GET makes sense.
The POST creates the new user.
The GET retrieves the information for user 3813812.
How are those two things the same? That is exactly how it is supposed to be done.
If your server can't handle that 'additonal' load very well, then I've got a 486 upgrade I'll donate for free.
Re: (Score:3)
With modern frameworks and Java level classiness (here, have a mappingfactory class that instantiates the mapping class that maps the data from the form into the object returned from the factory class that produced the object being created) what happens is more like
The POST creates a hospital, staffs it with receptionists, doctors, nurses, and so on. A pregnant woman (the request) goes in, the receptionist routes her to the OB ward where nurses help her into the stirrups and the doctor catches the baby. T
Re: (Score:1)
Yep that sounds correct. That is the entire point of GET and POST being different.
GET retrieves data, never alters it. POST alters data, never retrieves it.
This is kinda HTTP 101. You might disagree, but then you'd be doing it wrong.
You are using a perfectly good axe as a door stop then whining that your teaspoon isn't cutting down trees properly.
Re: (Score:2)
POST alters data, never retrieves it.
Except for all of the cases where POST returns data, sure. There is absolutely no reason to destroy the result of creating a resource instead of returning the newly created resource with a flag "don't do that again".
You are using a perfectly good axe as a door stop then whining that your teaspoon isn't cutting down trees properly.
Meanwhile you're dulling the perfectly good axe to be sure that nobody cuts down your sacred tree.
Re: (Score:2)
If the 'axe' is perfectly good, then why are you requesting fundamental changes to HTTP web apps and every web browser just to save your 8080 web server one additional hit?
Re: (Score:2)
Yep that sounds correct. That is the entire point of GET and POST being different.
GET retrieves data, never alters it. POST alters data, never retrieves it.
Both assertions are false.
This is kinda HTTP 101. You might disagree, but then you'd be doing it wrong.
LOL if you disagree with me your doing it wrong. No arguing that.
You are using a perfectly good axe as a door stop then whining that your teaspoon isn't cutting down trees properly.
HTTP is a dull rusty blade attached to a termite infested rotted, split, splintered handle yet it is the only axe left in the world and the only way to cut down trees.
It is unwise to attempt to use it properly as "intended" you will just break it and or injure yourself.
Instructions included with moldy packaging the axe originally came in is only a useful as a reminder of old times before our Alien overlords swooped do
Re: (Score:2)
I think you're confusing the protocol verbs with a heap of javabollocks on the back end.
In most systems GET occurs much more often than POST, and if you're returning to a system after logging off, you'll be doing a lot of GETs just to restore your environment (or page view).
I think a POST+GET optimisation would be nice, but it would be an optimisation, a little like how some DBs have a 'insert, or update if already exists' statement. But you can already return data from a POST, it does break the concept but
Re: (Score:2)
Erm, but in that instance POSTing then doing a GET makes sense.
The POST creates the new user.
The GET retrieves the information for user 3813812.
Too many people seem to think it's cool to add round trips for some incoherent appeal to logical consistency.
How are those two things the same? That is exactly how it is supposed to be done.
Who cares? HTTP verbs are insufficient to express jack or jill and HTTP completely lacks any useful transaction semantics. REST in the abstract is a great idea... only problem is HTTP is shit and when you don't treat shit like shit you end up with shit. HTTP is simply the wrong layer to be toying with any kind of abstraction if you care about useful results.
If your server can't handle that 'additonal' load very well, then I've got a 486 upgrade I'll donate for free.
The actual problem is users suffering t
Re: (Score:2)
The paradigm and semantic is perfectly clean/correct. The roundtrip is just an implementation detail.
The protocol could simply return the result of the post with a redirect, as well as the result of the get, in 1 response. Then under the hood even though you do a GET, the get "chunk" of the post result would get rendered. No additional roundtrip.
This is already used in some context. Imagine I want to show you a server rendered image based on some query string generated in javascript or something (ie: nothin
Re: (Score:2)
The paradigm and semantic is perfectly clean/correct. The roundtrip is just an implementation detail.
Like the rest of HTTP it is perfectly useless. No coherency nor atomicity nor any way to implement verbs beyond trivial "CRUD".
The protocol could simply return the result of the post with a redirect, as well as the result of the get, in 1 response.
Why is returning a pointer to data allowed while returning actual data itself not? This just sounds like bullshit.
Then under the hood even though you do a GET, the get "chunk" of the post result would get rendered. No additional roundtrip.
Or you can just return data and stop being silly.
(yeah, I could request the image and then set the data to the img tag. This was just a roundabout example).
It always is... I'll leave failure to communicate a coherent use case to speak for itself.
That technique works today, and for some edge cases, it is actually being used in the real world. Making a post -> redirect -> Get without roundtrip wouldn't be very different from existing paradigms.
But what is the point?
Re: (Score:2)
Clearly we're not making posts to an HTTP-based discussion board because when we submit a POST request we get response data back that is then displayed on screen. Violating such fundamental principles of HTTP surely disqualifies it from being considered as such.
Re:That will cause the browser (Score:2)
First, browser developers are in charge of browser behavior, not a protocol. RFC may say "should", or "must", but browser implementers don't have to do that.
There is a need for this, but your question is whether the standard requests, or requires, the feature. Your other, unasked question, is whether any development team has committed to respect the "required" or "must" statement from the RFC.
Luke! (Score:5, Funny)
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: (Score:2)
Re: (Score:2)
Color me paranoid but this sounds like Google is going out of there weigh too weeken encryption in transport.
Color me hopeful, but this looks like you went out of your way to misspell four words in a row.
Re:Backdoor collusion (Score:5, Informative)
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 [certificat...arency.org]. 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.)
Re: (Score:2)
Mostly pointless though, full encryption for data comms is often worthless - who cares about encrypted comms if all you're doing is looking at pictures of cats. When you're posting subversion messages criticising your local dictator, you need something better than plain old encryption anyway.
Now working with certificate authorities to manage revoked certificates is a good thing, but many of the problems with CAs are a more human problem - until we get to a point where encryption is seen as different to auth
Re: (Score:2)
The point I'm trying to make is that encryption isn't the problem that need to be solved, it all the infrastructure around it that does. Mandatory encryption isn't any solution to anything useful.
Encryption is almost never the solution. As Schneier said "If you think cryptography is the solution to your problem, you don't understand cryptography, and you don't understand your problem." This is because cryptography merely moves problems. In the case of encryption it turns large secrets in to small ones. That actually is very useful, because the small secrets have different properties which in many case make them easier to manage.
With respect to network communications, I agree that encryption doesn'
Re: (Score:2)
Re: (Score:2)
Dude, my employer is mentioned on my /. profile; I've never made any attempt to hide it. And it really has nothing to do with being annoyed by your crapflooding. EVERYONE is annoyed by your crapflooding.
It's fine that you like using a hosts file to block ads. Really. And it's even fine posting about it a time or two on relevant slashdot threads. If you kept it to a reasonable volume you'd probably even get modded up. But the crapflooding is obnoxious.
Finally, my comment about an APK-block extension was
It looks like a good idea. (Score:2)
Apparently this was already being done in a non-standard compliant manner but supported by all the browsers. The non-standard version, created and promo
Re: (Score:2)
No plans (Score:1)
I have no plans to adopt HTTP/2. The mandatory fauxcryption (as implemented in the browsers) is a dealbreaker. Certificates are nothing but a scam and they certainly aren't trustworthy since the CAs are subject to the whims of cybercriminals and governments. All this does is increase the barrier to entry for having your own webpage.
Re: (Score:3)
IE will kill it (Score:2)
Since IE 11 is end of life and so is the 2nd most popular browser IE 8 it will prevent adoption.
The saga of short sighted ceos not wanting to loose customers who run old operating systems kills innovation again as win 7 will continue to exist for a long time and with it IE 11 and 8 for corps with old apps
Re: (Score:2)
doesn't matter.
as long as android and ios support it, the sites will implement it. it's not like it needs that much effort to anyways.