Follow Slashdot stories on Twitter

 



Forgot your password?
typodupeerror
×
The Internet Google Microsoft Technology

S+M Vs. SPDY: Microsoft and Google Battle Over HTTP 2.0 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."
This discussion has been archived. No new comments can be posted.

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

Comments Filter:
  • by merc ( 115854 ) <slashdot@upt.org> on Thursday March 29, 2012 @03:58AM (#39506153) Homepage

    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.

  • by Sneeka2 ( 782894 ) on Thursday March 29, 2012 @04:43AM (#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.

  • by Richard_at_work ( 517087 ) on Thursday March 29, 2012 @05:06AM (#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:No (Score:5, Informative)

    by styrotech ( 136124 ) on Thursday March 29, 2012 @05:06AM (#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.

  • by greyc ( 709363 ) on Thursday March 29, 2012 @07:06AM (#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.

  • by the_B0fh ( 208483 ) on Thursday March 29, 2012 @07:14AM (#39507219) Homepage

    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?

We are each entitled to our own opinion, but no one is entitled to his own facts. -- Patrick Moynihan

Working...