×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

S+M Vs. SPDY: Microsoft and Google Battle Over HTTP 2.0

Soulskill posted about 2 years ago | from the two-will-enter-one-will-maybe-eventually-leave dept.

The Internet 180

MrSeb writes "HTTP, the protocol that underpins almost every inch of the world wide web, is about to make the jump from version 1.1 to 2.0 after some 13 years of stagnation. For a long time it looked like Google's experimental SPDY protocol would be the only viable option for the Internet Engineering Task Force to ratify as HTTP 2.0, but now out of left field comes a competing proposal from Microsoft. Lumbered with the truly awful name of HTTP Speed+Mobility, or HTTP S+M for short, Microsoft's vision of HTTP 2.0 is mostly very similar to SPDY, but with additional features that cater toward apps and mobile devices. 'The HTTP Speed+Mobility proposal starts from both the Google SPDY protocol and the work the industry has done around WebSockets,' says Jean Paoli from the Microsoft Interoperability team. Basically, the S+M proposal looks like it's less brute-force than SPDY: Where server push, encryption, and compression are all built into SPDY, Microsoft, citing low-powered devices and metered connections, wants them to be optional extensions. Judging by the speed at which the internet (and the internet of things) is developing, I think MS's extensible, flexible solution has its merits."

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

180 comments

Oh god... (5, Funny)

Theophany (2519296) | about 2 years ago | (#39506117)

S&M - really??

Re:Oh god... (0)

Anonymous Coward | about 2 years ago | (#39506133)

Hahahahaha Brilliant! I never even thought of that!

Re:Oh god... (5, Funny)

Kangburra (911213) | about 2 years ago | (#39506139)

Going to make for some great domain names! :)

Re:Oh god... (4, Funny)

Chrisq (894406) | about 2 years ago | (#39506759)

Going to make for some great domain names! :)

And some interesting work time search results. Imagine:

S+M maximum speed
S+M large payload
S+M security accessories

Re:Oh god... (5, Funny)

justforgetme (1814588) | about 2 years ago | (#39507145)

Not to forget the job market:

"Wanted senior S&M specialist with python experience and high availability background"

Re:Oh god... (5, Funny)

andrew3 (2250992) | about 2 years ago | (#39506169)

If they used HTTP mobility+speed it would be HTTP MS. But I suppose S&M makes things a whole lot more exciting. Dirty bastards. ;)

Microsoft ? Proprietary IP ? (-1, Flamebait)

Taco Cowboy (5327) | about 2 years ago | (#39506181)

Once bitten, twice shy

Does the M$ package comes with proprietary IP?

Re:Microsoft ? Proprietary IP ? (2)

thegarbz (1787294) | about 2 years ago | (#39506517)

Well that's kind of the point isn't it? In S&M someone always is the biter and the other one is the bitten.

It'll won't be Microsoft wearing the ballgag.

Re:Microsoft ? Proprietary IP ? (0)

gtirloni (1531285) | about 2 years ago | (#39506861)

Please cite Internet standards that were based fully on a Microsoft proposal and had IP problems.

Re:Microsoft ? Proprietary IP ? (4, Informative)

the_B0fh (208483) | about 2 years ago | (#39507219)

Did you forget Active Directory and Kerberos where Microsoft refused to say WTF they did in the extension field until the Kerberos working group threatened to redefine that field away and turn Microsoft's implementation incompatible?

Use strict (2)

aronzak (1203098) | about 2 years ago | (#39506211)

The Microsoft S&M (TM) standard will mandate the declaration 'use strict' on all pages.

Oh, and I don't think Microsoft can embrace, extend, extinguish this one even if they tried, because everyone knows that IIS is a piece of shit. Apache still has 55%, but nginx is the fastest growing web server; I don't think standards can disrupt what's already a healthy ecosystem.

Re:Use strict (0)

jrumney (197329) | about 2 years ago | (#39506485)

everyone knows that IIS is a piece of shit

Not being familiar with the scene from my mother's basement, is scat considered S+M too, or is it a distinct speciality?

Re:Use strict (0, Troll)

SteveWP (1845840) | about 2 years ago | (#39506587)

everyone knows that IIS is a piece of shit

Not being familiar with the scene from my mother's basement, is scat considered S+M too, or is it a distinct speciality?

Scat is a distinct Micro$haft specialty.

Re:Use strict (0, Troll)

Anonymous Coward | about 2 years ago | (#39506629)

You changed "Microsoft" into "Micro$haft".

Awww how cute - baby's first funny.

Re:Oh god... (3, Funny)

homsar (2461440) | about 2 years ago | (#39506303)

Microsoft can really be blind about how their product names can be interpreted. This is, after all, the company who brought us Wince (well, WinCE)...

Re:Oh god... (1)

Joce640k (829181) | about 2 years ago | (#39506475)

Also "Windows OneCare" (read it in an Inspector Clouseau voice...)

Not to mention Steve Ballmer talking about 'squirting' and those awful Seinfeld ads.

Re:Oh god... (0)

Anonymous Coward | about 2 years ago | (#39506311)

S&M - really??

But don't worry at least it "looks like it's less brute-force than SPDY"

Re:Oh god... (0)

Anonymous Coward | about 2 years ago | (#39506371)

Expect the next version (HTTP 3.0) HTTP S,M&G xD

Re:Oh god... (-1)

Anonymous Coward | about 2 years ago | (#39506541)

Did they not learn from the story of the failure of "GIMP" ??

Re:Oh god... (0)

Anonymous Coward | about 2 years ago | (#39507069)

This isn't too suprising from the company that had a business server abbreviated BPOS.

Re:Oh god... (0)

Anonymous Coward | about 2 years ago | (#39507189)

Is it coming with a blob and optional required buggy MS only compatible extensions? Google's proposal is not around adv buzz like Ms :

Ms offers :

backwards compatibility
makes your computer faster
feeds your family
have better saxxx

you just have to press this tiny ok button in the licence screen that sells you to devil without SSL.

Optional extensions? (1)

lgftsa (617184) | about 2 years ago | (#39506125)

I wonder if all the options of all the extensions will be part of the spec, or is this another embrace, extend, extinguish?

Re:Optional extensions? (5, Insightful)

Sneeka2 (782894) | about 2 years ago | (#39506207)

I really like that SPDY insists on SSL secured connections. This is what we should be moving towards and having it forced upon us in the next HTTP revision is a great step. But of course Microsoft tries to be backwards compatible, as they always are.

I say SPDY for modern devices, HTTP 1.1 for the foreseeable future for low powered devices. It still works fine, you know? And by the time HTTP 1.1 is retired, there will be no more devices so underpowered they can't establish a SPDY connection. For the love of god, drop legacy when you get the chance!

Re:Optional extensions? (5, Interesting)

fsterman (519061) | about 2 years ago | (#39506353)

Correct me if I am wrong, but encryption prevents caching. That is why Facebook and Google used to encrypt only user/password authentication. Forcing every connection to have encryption would prevent all caching as well...

No (0)

Anonymous Coward | about 2 years ago | (#39506419)

Encryption doesn't prevent caching (except maybe by the proxies), but I guess browsers do it that way .. the browsers won't cache as a precaution -- it can be overridden.

Re:No (1)

Sneeka2 (782894) | about 2 years ago | (#39506453)

the browsers won't cache as a precaution -- it can be overridden.

Say what now? Precaution against what?
And browsers cache assets transferred over HTTPS just fine.

Re:No (4, Informative)

styrotech (136124) | about 2 years ago | (#39506555)

Say what now? Precaution against what?
And browsers cache assets transferred over HTTPS just fine.

I think our anonymous friend is a little out of date, but was kinda right in the past for at least some browsers.

Firefox was one of the last browsers to not cache HTTPS resources even if the headers said to. I think this changed with Firefox 3 (?). The reasoning was that anything transferred over HTTPS was assumed to be private, and shouldn't be saved to disk. And yes this included images and stylesheets etc.

They did come to their senses thankfully.

Re:Optional extensions? (4, Informative)

Sneeka2 (782894) | about 2 years ago | (#39506429)

Correct me if I am wrong, but encryption prevents caching.

Well, you are wrong. At least as a general statement. :)

It prevents caching by proxies, but it works fine with regular client/server HTTP caching.

Re:Optional extensions? (4, Interesting)

arth1 (260657) | about 2 years ago | (#39507103)

It prevents caching by proxies, but it works fine with regular client/server HTTP caching.

The first is a huge problem. Having a transparent caching proxy easily saves a medium sized company 20-40% bandwidth and increases the perceived speed for users.
Enforced SSL also decreases speed because of a need to encrypt on one end and decrypt on the other. Slow devices pay the heaviest penalty.

My first test of SPDY showed that it slowed down page load by a factor of 2, and consumed a heck of a lot more resources too. Yes, this was on a slow machine. But guess what? Slower machines haven't been banned from accessing the web, and I don't think they should be.

I am not against SSL, but against the use of it for the sake of using it. It's the lazy way out.

No, please let me have HTTP/1.0 and 1.1, also without SSL. Because sometimes the solution creates as many problems as it solves.

Hopefully Microsoft's suggestion is a bit more sensible. But I doubt it. They want controlled slow obsoletion, so customers can be forced to buy new versions of Windows Server, Office and what have you.

Re:Optional extensions? (2)

chrylis (262281) | about 2 years ago | (#39506435)

Firefox, Chrome, Opera, and IE will all cache HTTPS content if permitted by Cache-Control headers. Of course, HTTPS, does prevent transparent proxy caches.

Re:Optional extensions? (2)

evilviper (135110) | about 2 years ago | (#39506457)

Correct me if I am wrong, but encryption prevents caching.

You're wrong. It prevents downstream proxies from caching, but Google is perfectly capable of putting the SSL layer in-front of Varnish/Squid, and caching rather than always hit the backend.

It hardly matters, these days. So much of the web is dynamically generated that caching hasn't been very useful in a long time, for anything but images.

Google and Microsoft are both EVIL (1)

Anonymous Coward | about 2 years ago | (#39506561)

But images are largely the reason for caching, that is the point.

Microsoft, bleating and extensible in the same sentence reeks of trying to get a foot in the door, don't let them

Google, insisting on SSL where only they can cache their content with effective man in the middle certificates. Making them the only company that can deliver content with any performance. Why wouldn't they want that? Additionally anyone wanting to access your particular Google searches such as by unfavorable governments such as the Americans or the British would then have exactly what they need, a single point to look at and a guarantee where the traffic came from. sheer genius.

Google is EVIL
Microsoft is EVIL
Government control is EVIL

So between them they break the beautiful anonymity and freedom of the web.

tinhats?

Re:Optional extensions? (2)

Johann Lau (1040920) | about 2 years ago | (#39506973)

You're wrong. It prevents downstream proxies from caching, but Google is perfectly capable of putting the SSL layer in-front of Varnish/Squid, and caching rather than always hit the backend.

Uhm, just because it's also caching doesn't mean it's the caching that is discussed, so wtf are you even talking about..

So much of the web is dynamically generated that caching hasn't been very useful in a long time

What? Just because something is dynamically generated doesn't mean it magically changes each time it's requested, or that it can't use last-modified or etag headers and implement "304 not modified", or be explicit about what is to be cached for how long, and under which circumstances. Again, what are you even talking about. Seems like you're just stringing words together.

Re:Optional extensions? (5, Insightful)

arth1 (260657) | about 2 years ago | (#39507243)

It hardly matters, these days. So much of the web is dynamically generated that caching hasn't been very useful in a long time, for anything but images.

Wrong. A lot of downloads are http. Do you really want all your users to download the same 80 MB updates or 2 GB iso files as separate copies through a shared internet connection, or get them from the cache after the first download?

And while a lot of content is dynamically generated, the javascript and css files generally aren't. The earlier they can be loaded in a client, the snappier the experience for the user.

Once you subtract downloads, streaming http video and audio, static pages, javascript, css and images, you'll find that what's left is a small part of the overall bandwidth.

What hurts with web 2.0 and abloodyjax is the ridiculous number of connections you establish and break down. Latency kills you. Re-using connections and keeping them more persistent helps, at the cost of maintaining unused connections at both ends. And caching what is cacheable (instead of the web devs taking the lazy cop-out of marking everything as dynamic) helps a lot.

SPDY is like the stores handing out a huge shopping cart to everyone whether they need it or not, to solve the problem of certain buyers pushing a train of two or more carts. It'll piss of those who just want a bottle of milk. It's a solution looking for a problem.

Re:Optional extensions? (0)

Anonymous Coward | about 2 years ago | (#39506355)

I really like that SPDY insists on SSL secured connections. This is what we should be moving towards and having it forced upon us in the next HTTP revision is a great step. But of course Microsoft tries to be backwards compatible, as they always are.

I think Microsoft is more concerned about doing business in places where encryption is illegal or heavily regulated (a list of countries which seems to be dangerously close to expanding into the West). Basically, MS doesn't want to have a standard which forces SSL so it's a business decision rather than a technical one, that's just a smoke screen.

[Any mobile device that can decode video or audio is going to have a DSP which should be perfectly capable of AES in low power, AES might end up being the only supported encryption algorithm but that isn't a real problem]

The interesting question is whether, if they don't get their way, MS will pull their usual bait-and-switch where they just implement SPDY but in a not-quite-standard quirky way and include support for operating without SSL anyway which they then try to force on everyone via bundling with IIS and IE and their various other web connected products.

Re:Optional extensions? (1)

loufoque (1400831) | about 2 years ago | (#39506501)

It could be argued that encryption should be done at the IP level, not HTTP level, and therefore having mandatory HTTPS is redundant

Re:Optional extensions? (2)

nomaddamon (1783058) | about 2 years ago | (#39506591)

Drop legacy and force extensions? Sounds like M$/Apple (but in this case it's the opposite) this will lead to "Oh, I'm sorry your App X can't connect to the Internet anymore, you know it's already 3.5 years old? Time to buy a newer version!"

But seriously, in the foreseeable future (lets say 10 years) we wont get to a state where mobile devices can be allays on-line, listening for server pushes and not drain the battery in 4 hours.

"You forgot google.com open in your mobile browser? It servers you right that your battery lasted 2 hours... and here is the bill for the 500mb bandwidth it consumed while at it"

Re:Optional extensions? (1)

icebraining (1313345) | about 2 years ago | (#39506751)

Nothing forces an application to be continuously on-line to support server push.

Server Push is to enable servers to push content to the client that it didn't specifically ask for; for example, /. could push the logo image right after getting a request for the HTML part, so that the client doesn't have to parse the HTML, find the image tag and then do a new request to ask for it.

Supporting server push actually reduces battery and traffic, since you don't need to send requests or keep the connection open for so long.

If a client doesn't want a particular resource being pushed, it can just issue a CANCEL error, which forces the server to stop pushing it.

Re:Optional extensions? (2)

codepunk (167897) | about 2 years ago | (#39506609)

SSL connections are a great thing however with that comes a great deal of cost and overhead for the server operator.

Re:Optional extensions? (2)

madsen (17668) | about 2 years ago | (#39506663)

There is ofcourse the problem that using SSL makes it much harder for us to inspect the traffic for malware, bots, and whatnot.

Re:Optional extensions? (4, Informative)

greyc (709363) | about 2 years ago | (#39507171)

[...] SPDY insists on SSL secured connections.

Citation Needed.

Certainly the common server-side implementations right now like [wikipedia.org] to use it with encryption, but I can find no mention of that being mandatory in the SPDY IETF draft [ietf.org].

In particular, section 2.1 has all of the following to say about upper-level protocols:

2.1. Session (Connections)
      The SPDY framing layer (or "session") runs atop a reliable transport
      layer such as TCP [RFC0793]. The client is the TCP connection
      initiator. SPDY connections are persistent connections.

SPDY has protocol elements that are only useful when it's wrapped by TLS/SSL, but then you aren't forced to use those on a given connection, either.

Really? (2)

bazmail (764941) | about 2 years ago | (#39506147)

S&M? lol what is it with microsoft and their naming schemes. Turtle phone anyone?

Re:Really? (2)

Sneeka2 (782894) | about 2 years ago | (#39506231)

Well, they could have gone with "Hypertext Transfer Protocol 2.0 Speed and Mobility Express Professional Server 2013 Edition for Workgroups" instead, or httpsmepew:// for short. I think "S&M" is already a pretty good try for them.

Re:Really? (0)

Anonymous Coward | about 2 years ago | (#39506543)

Well, they could have gone with "Hypertext Transfer Protocol 2.0 Speed and Mobility Express Professional Server 2013 Edition for Workgroups Service Pack 3" instead, or httpsmepew:// for short. I think "S&M" is already a pretty good try for them.

FTFY

I'm weary of any standard coming out of Redmond (5, Informative)

merc (115854) | about 2 years ago | (#39506153)

Lets take a little look at the history of Microsoft and clearly understand what we're getting into before we blindly adapt one of their standards.

Re:I'm weary of any standard coming out of Redmond (3, Insightful)

bemymonkey (1244086) | about 2 years ago | (#39506225)

Wary.

But yes, it's always a good idea to take a closer look... although tbh, the same thing applies for Google's alternative ;)

Re:I'm weary of any standard coming out of Redmond (1)

Anonymous Coward | about 2 years ago | (#39506535)

Wary.

But yes, it's always a good idea to take a closer look... although tbh, the same thing applies for Google's alternative ;)

I disagree. Based on history and the status quo. MS is based on technical monopoly. That means closed formats and standards. Like Office format. And in MS networkt, only MS-softaware is compatible. And that's how MS want's it to continue. Remeber the ODF/OOXML process?

Google has no such a history. Google has based on open standards and code. No one is forced to use Googles services. That's why I use them.

Re:I'm weary of any standard coming out of Redmond (1)

Johann Lau (1040920) | about 2 years ago | (#39506995)

While "wary" is likely the originally intended meaning, "weary" also parses fine ^^

Re:I'm weary of any standard coming out of Redmond (2)

MadKeithV (102058) | about 2 years ago | (#39506233)

Lets take a little look at the history of Microsoft and clearly understand what we're getting into before we blindly adapt one of their standards.

They even called it HTTP Sadism & Masochism, it's not like we aren't warned.

Re:I'm weary of any standard coming out of Redmond (1, Funny)

dido (9125) | about 2 years ago | (#39506267)

As if the name of the proposed standard wasn't already a dead giveaway. It's obviously another ploy for them to place the world back under their bondage and domination. I think some marketing drone at Microsoft hadn't thought the name through, or perhaps they are here trying to display a frank and contemptuous display of their true motives in introducing such a protocol. I hear a song by Rihanna playing in the background....

Re:I'm weary of any standard coming out of Redmond (1)

Thing 1 (178996) | about 2 years ago | (#39507201)

Microsoft has a history of marketing intelligence. They released the first version of Windows Update as the Critical Update Notification Tool (make the acronym...). They also had a campaign in System Center with the tagline "You're in control!" Spoken, it sounds like "hitting the bowl" (i.e., the same way that "gun control is hitting what you're aiming at", the joke just in case being "you're in" --> "urine").

Re:I'm weary of any standard coming out of Redmond (0)

Anonymous Coward | about 2 years ago | (#39506611)

Why? Just because Microsoft corrupts organisations like the ISO to literally buy their own standards? That was just an innocent mishap!

Sigh. Microsoft copies Google yet again. (0)

Anonymous Coward | about 2 years ago | (#39506219)

They stopped innovating years ago - copying Google [blogspot.co.uk] is about the only thing they can do these days. And what's with the word "mobile" in this me too effort - it's not like they've ever had any relevance there [wired.com], or ever will [thenextweb.com].

Re:Sigh. Microsoft copies Google yet again. (3, Funny)

DrXym (126579) | about 2 years ago | (#39506319)

People discount Microsoft because they fail to realise that Microsoft is relentless. It's like waves of zombies. You might fight off the first wave and become a bit arrogant but before you know they're back and attacking in large numbers. Before you know it your defences are overrun, your bullets have been spent and they're eating your brains.

Re:Sigh. Microsoft copies Google yet again. (1)

Johann Lau (1040920) | about 2 years ago | (#39507013)

Then they stumble around blindly and starve, because they ate/transformed all humans. Then they eat each other. Then the sun rises and life forms anew on the planet.

it's Internet, not internet! (0)

Anonymous Coward | about 2 years ago | (#39506285)

spell it right please

I don't understand ... (0)

Anonymous Coward | about 2 years ago | (#39506323)

... why they don't go whole hog, and call it "HTTP BSDM".

I'm sure they could come up with a good backronym.

SSL needs to be mandatory (1)

backslashdot (95548) | about 2 years ago | (#39506387)

SSL needs to be mandatory .. there is way too much threat from various governments and even non governmental bodies that want to see what people are doing on the web.

If wish somebody would ship an SSL-only browser.

Re:SSL needs to be mandatory (2)

shutdown -p now (807394) | about 2 years ago | (#39506415)

SSL needs to be mandatory .. there is way too much threat from various governments and even non governmental bodies that want to see what people are doing on the web.

Given the centralized nature of SSL certificates, it's downright trivial for a sufficiently interested government to execute a MITM attack on you. All they need to do is force the certificate authority to issue a copy to them.

Re:SSL needs to be mandatory (4, Informative)

Richard_at_work (517087) | about 2 years ago | (#39506553)

They don't even need a copy, or interaction with the same CA - any cert issued for the same domain by any CA will do just fine, which is why the creation of a CA in China recently was a hot topic, as it allows global MITM attacks by Chinas government.

Re:SSL needs to be mandatory (1)

ewanm89 (1052822) | about 2 years ago | (#39506569)

Most governments worldwide have their own certificate authority with root certificates in browsers. So they don't need to put pressure on an 3rd party to do it.

Re:SSL needs to be mandatory (1)

modmans2ndcoming (929661) | about 2 years ago | (#39506607)

That is an issue with the CA system, not SSL.

Re:SSL needs to be mandatory (1)

Meneth (872868) | about 2 years ago | (#39506727)

SSL relies on the CA system to function effectively, which means that without a reliable CA system, SSL is also unreliable.

Re:SSL needs to be mandatory (1)

modmans2ndcoming (929661) | about 2 years ago | (#39506879)

apparently you don't understand the difference between a technological and non-technological problem.

They can replace the CA system with something that functions more reliably and SSL would not need to change.

Re:SSL needs to be mandatory (0)

Anonymous Coward | about 2 years ago | (#39507099)

While you are technically correct your points are similar to issues with nuclear power.

Its great , except for that waste issue; TODAY ... you can not have one without the other, same with SSL & CAs; TODAY ... you can not have one without the other.

Not a fan of optional (2)

MtHuurne (602934) | about 2 years ago | (#39506417)

For every optional feature, the server will need code to deal with clients that do support it and clients that don't. It's more code to write and more potential for bugs. Of course this doesn't mean that every feature should be mandatory, but compression and encryption are already supported by pretty much every browser and server push would be a significant improvement over polling.

On metered connections, compression and server push would be improvements and encryption wouldn't make a difference. For power consumption, server push would be an improvement (polling means sending over a wireless link regularly), compression would probably not make much of a difference (assuming we're talking about gzip here) and encryption might tax the battery a bit more. However, if this is an issue, the common encryption algorithms could be hardware accelerated.

Re:Not a fan of optional (1)

loufoque (1400831) | about 2 years ago | (#39506519)

You do realize some devices just don't have those hardware accelerators you're speaking of?

Re:Not a fan of optional (1)

MtHuurne (602934) | about 2 years ago | (#39506575)

Today some don't have it, but this is a design for a future standard. Smartphones already have MPEG4 acceleration and I think hardware AES would take less transistors than MPEG4. Also, a software fallback for encryption is possible, so even if it would take a bit more power you'd still be able to use it. And when transistors continue to shrink computation will become cheaper over time, while the amount of power spent on the display and the radio will probably not decrease a lot.

I also realize that not all devices are smartphones, but the embedded market uses SoC designs and adding an encryption module to such a system would not cause a significant increase in footprint.

Re:Not a fan of optional (1)

ewanm89 (1052822) | about 2 years ago | (#39506613)

AES was designed to be hardware accelerated in the NIST standardization process, it's one of the reasons Rijndael won to become AES.

Re:Not a fan of optional (1)

loufoque (1400831) | about 2 years ago | (#39506961)

So all older devices would become incapable of connecting to modern websites, even with software upgrades?

Re:Not a fan of optional (1)

MtHuurne (602934) | about 2 years ago | (#39507019)

No, they would spend a bit more power by doing decryption in software instead of hardware.

Re:Not a fan of optional (4, Insightful)

Serious Callers Only (1022605) | about 2 years ago | (#39506671)

Those devices can stay on http 1.1 which will be supported for the foreseeable future. That's a much better way to manage backwards compatibility than trying to make certain features optional.

Re:Not a fan of optional (1)

ewanm89 (1052822) | about 2 years ago | (#39506579)

Encryption takes more time and data for the handshake and integrity checks and compression will make a huge difference on hypertext and other text only data.

Re:Not a fan of optional (1)

modmans2ndcoming (929661) | about 2 years ago | (#39506625)

Related assets being pushed with out request will be a huge deal too...I call up the webpage, I want the webpage, so you might as well give me everything without waiting for me to ask for the next image/javascript block...etc.

Re:Not a fan of optional (1)

JasterBobaMereel (1102861) | about 2 years ago | (#39507283)

Microsoft the market leader in Mobile phone OS's is obviously the right way to go rather than the minority player Google ... oh sorry got that the wrong way round ...

Microsoft and the mobility fiasco (1)

jcdr (178250) | about 2 years ago | (#39506465)

Microsoft, with the ridicule market share of Windows Phone, you are probably not in the position to tell to Google how to do this kind of technology.

Re:Microsoft and the mobility fiasco (0)

Anonymous Coward | about 2 years ago | (#39507441)

I'm sure you made the same argument then... that the ODF team were in no position to tell Microsoft what to do with open document formats, what with the 9x% market share held by Office. Oh, you didn't? Then stop making it here. I saw some other clown make the same argument on the SIM format per Apple. "Huh, Apple sells more smartphones than Nokia so Nokia needs to shut up". It's a terrible precedent to set and will burn you in the ass.

Summary oversimplifies the proposal (5, Funny)

93 Escort Wagon (326346) | about 2 years ago | (#39506483)

Microsoft proposes HTTP 2.0 come in the following varieties:

HTTP Speed+Mobility Starter Edition
HTTP Speed+Mobility Professional
HTTP Speed+Mobility Enterprise
HTTP Speed+Mobility Ultimate

Re:Summary oversimplifies the proposal (2)

should_be_linear (779431) | about 2 years ago | (#39506679)

Also, their own HTTP Speed+Mobility implementation is completely different from one they proposed for standardization.

Re:Summary oversimplifies the proposal (2)

will_die (586523) | about 2 years ago | (#39506855)

Micro soft is getting away from that terminalogy and simplifing, they are going with:

HTTP S & M Leather Edition
HTTP S & M Chain Edition
and for the Asian market HTTP S & M Tentacle Edition

disagree... (0)

Anonymous Coward | about 2 years ago | (#39506549)

I disagree that the MS approach to making it extensible is valid... sure that makes sense in today's world, but by the time the standard is widely accepted, internet speeds in most developed nations will far out perform the need for it to be plug-able to accommodate for bandwidth issues. It yet again goes to show that MS has a hard time looking into the future in comparison to Google

HTTP Pipelining (1)

Anonymous Coward | about 2 years ago | (#39506769)

Speedup from HTTP pipelining: +40%

There's a reason why they didn't test against pipelining, because there's no need for a new protocol at all. The reason why they want to push SPDY so much is they want a direct 1-to-1 connection between your browser and the Google -- no caching, no proxy, no more documents. If you want to use the internet you'll need to be signed in to Google like DRM. And a persistent connection that's open for a long time means it's the same user -- better to sell you ads and track you.

HTTP 2.0 should be HTTP, a hyper text transfer protocol.

Personally both sound good (0)

Anonymous Coward | about 2 years ago | (#39507519)

And they really should work together to combine both ideas.

Microsoft actually want to contribute on a level playing field now.
So they should be given a chance at least.

They have contributed some very useful things to the web right now that we take for granted on quite a few sites, this in particular.
And before people say "oh but it is slow", I'd like to see your native versions of the same thing. Hint: there are none.
But really, the very few programs where there are thousands upon thousands of active elements all with pretty detailed information on them, styling information, that can all equally affect each other directly through resizing, being plucked out the source, and so on, that are all on a UI are typically pretty damn slow, unless it is done through the video canvas. (that includes the native version of Google Wave that was done)
The video canvases on web browsers are getting so much quicker with each iteration that they will pretty quickly catch up to native speeds. And that isn't even counting WebGL.

Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...