Slashdot Mirror
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.
Google has a big case of "Invented Here" syndrome.
If Google started something, you can count on them dropping it.
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.
If I have been able to see further than others, it is because I bought a pair of binoculars.
Don't give Lennart Poettering any more bad ideas. PLEASE !
"Transparent" is a shit show that trades on every stereotype going. A man in drag is NOT a transsexual.
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.
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.
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.
Serious? Seriousness is well above my pay grade.
What? POST is the non-idempotent one. See the table in http://tools.ietf.org/html/rfc..., section 8.1.3
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.
If I have been able to see further than others, it is because I bought a pair of binoculars.
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.
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. The doctor takes all the baby's stats, writes it on the birth certificate, drops the certificate into a pneumatic chute that whisks it away to safety (in the database) as the hospital and all its occupants are immediately vaporized by an explosion (if you're still using CGI, replace this with the entire sun going supernova. Add recreating the solar system to the beginning of the next request).
The GET creates a hospital, staffs it with receptionists, doctors, cloning technicians, and so on. A woman (the request) goes in, the receptionist routes her to the cloning ward where the woman hands over the birth certificate that had been mailed to her, the doctor looks over the certificate and checks to make sure she's really supposed to have it (or not, given the state of security these days) then pulls out a cloning tank and reconstitutes a baby that is identical in every way (ideally) to the original and hands it to the woman. As the woman leaves the hospital baby in tow, it explodes behind her, action movie style.
Or, y'know, you could just pass the new baby straight to a View and do all this with half the hospitals, doctors, receptionists and none of the cloning vats.
then I've got a 486 upgrade I'll donate for free.
Thanks! Once it can do the same task with half the number of requests, it'll work twice as well!
If I have been able to see further than others, it is because I bought a pair of binoculars.
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...
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.)
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
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.
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. The JS will need some way to tell the browser what to render and HTML is as good a way as any.
In addition to greatly increasing costs (there are no free wildcard certs, and encryption does increase CPU workload, which decreases scalability), it also increases the barrier for writing your own tools to interoperate with the web (HTTP servers, clients, proxies, aggregators, etc.) If you've ever looked at the SSL libraries out there, all but the OpenBSD-only LibreSSL are a complete clusterfuck. This is the GnuTLS API, for instance. I won't even get into the security ramifications like Heartbleed. Whereas HTTP/1.1 can be spoken to by a human being using a telnet terminal, and even Commodore 64's have been made to serve up web pages.
Sadly, modern developers have completely lost touch with the value of making things small and simple.
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.