Speed and Mobility: An Approach for HTTP 2.0 to Make Mobile Apps and the Web Faster
This week begins face to face meetings at the IETF on how to approach HTTP 2.0 and improve the Internet. How the industry moves forward together on the next version of HTTP – how every application and service on the Web communicates today – can have a positive impact on user experience, operational and environmental costs, and even the battery life of the devices you carry around.
As part of this discussion of HTTP 2.0, Microsoft will submit to the IETF a proposal for “HTTP Speed+Mobility.” The approach we propose focuses on Web performance improvements at the same time it takes into account the important needs of mobile devices and applications.
You can read more here about this proposal and an approach to HTTP 2.0 which considers network speed, cost, and device battery life, and works for everyone from sites owners, content providers, to consumers.
-- Rob Mauceri, Group Program Manager, Internet Explorer
Comments
Anonymous
March 25, 2012
Google SPDY technology is to be based and HTTP2.0 is true? Rumor has it. It security is OK? That side firmly talked, I want to thank you for working on development, implementation. I would like to ask well balanced.Anonymous
March 25, 2012
A copy of the proposal would be nice.Anonymous
March 25, 2012
This tells us almost nothing. A copy of the proposal please.Anonymous
March 25, 2012
why IE10 is so slow to issue? Microsoft is really too soft. You people are lazy or silly?Anonymous
March 25, 2012
Did any of you bother to follow the link? Idiots. Oh, and @Martin? The only "lazy or silly" person on this blog is the guy asking why IE10 hasn't shipped yet and offering no desire to help get it out the door. Maybe you want to whine about not having a flying car or jet backpack, too, while you're at it.Anonymous
March 25, 2012
That link provides no info other than a bunch of hand waving... It isn't even slideware yet. Just how are you proposing to save battery life? How are you hoping to merge web sockets with SPDY? And most importantly... When IE supports HTTP 2.0 will you ensure that it properly supports all headers?! We don't want another "vary" header that IE ignores or an HTTPS cache rule that erases downloads before the end user can open them... Or a save page functionality that requires a complete reload of the entire page. Make sure you are willing to commit fully to HTTP 2.0 bred ore you toot your horn!Anonymous
March 25, 2012
The eventual http 2.0 specification will likely have levels of compliance to scale with limited devices. IE and other browsers will have most of the standard eventually.Anonymous
March 26, 2012
The comment has been removedAnonymous
March 27, 2012
IE 10 does not support mathml (already included in HTML5) IE 10 does not support webgl And microsoft is proposinf a new specification ? Implement first what other browsers already support. Then, AFTER THIS, you can propose new specifications...Anonymous
March 27, 2012
The comment has been removedAnonymous
March 27, 2012
Wait what?! @Randall - just where is this proposal online? all we've seen is "talk" about what this "thing" would do - there has been ZERO cold hard facts or a specification for us to read. we're glad that Microsoft is interested in telling us about this before forcing an implementation on us - but the community will be much more willing to listen if you give us something to read... to let us decide if we should be happy about this new concept or be fearful that IE is just going to open up and monopolize more connections to the server than IE9 already does with its over zealous pre-loading and re-loading if the context changes instead of re-parsing the files it already downloaded (a serious WT*?! in the IE9 design). NickAnonymous
March 28, 2012
@Wait what -- I was only replying to the intro (the -00 version of the Internet-Draft), but -01 is up now. Haven't had time to read through. It has features I didn't expect, like default-on header compression. The 00 version seemed to hint Microsoft really wants to protect existing network infrastructure that tinkers with HTTP packets on the wire ("switches, routers, proxies, load balancers, security systems"). I was saying I think men-in-the-middle editing HTTP sessions without user/server consent is a bug, not a feature we want to carry forward, and I sketched out one way to encourage end-to-end integrity for next-gen HTTP connections short of a TLS wrapper. (And, revising what I laid out yesterday, a new schema and port for HTTP+integrity wouldn't make sense -- just use integrity checks to determine 1) whether it's safe to use new features that might not work with packet-rewriting hardware, and 2) whether to show the user a "checks passed" cue analogous to the SSL lock (a checkmark in the address bar, say).)Anonymous
March 29, 2012
muito bom