Back in 2009, Google began an industry discussion about a prospective upgrade to HTTP protocol - the application that enables the Web over the Internet. The concept is called SPDY, and to date, conventional wisdom held that while some are skeptical of Google's motives, as a concept, SPDY was running unopposed.

Maybe not any more. This week, Microsoft is embarking on a curious strategy that sounds a lot like its old "embrace + extend" approach to world domination. Advancing just the introductory paragraphs of an IETF technical proposal that has yet to be released, Microsoft is calling for the next version of HTTP to include multiplexing for multiple components (like SPDY) and full-time encryption of the session layer (like SPDY, but without relying solely on SSL or TLS). The "extend" part comes by way of an allusion to WebSocket (which has recently been considered a part of HTML5) - a provision for full-duplex communications critical to the next generation of Web apps.

Does the Web Need "S+M?"

The introductory paragraphs include the following: "HTTP at its core is a simple request-response protocol. The [IETF Network] working group has clearly stated that it is a goal to preserve the semantics of HTTP. Thus, we believe that the request-response nature of the HTTP protocol must be preserved. The core HTTP 2.0 protocol should focus on optimizing these HTTP semantics, while improving the transport via a new session layer. Additional capabilities that introduce new communication models like unrequested responses must be treated as an extension to the core protocol, and explored separately from the core protocol."

Employing both multiplexing and encryption on the session layer would, nearly all reasonable Internet engineers agree, dramatically improve the integrity of Web interactions and radically reduce traffic generated by pages that pull their content from multiple sources (which pretty much encompasses the majority of pages). There isn't much to dispute about Google's SPDY proposal, except perhaps the use of SSL (depicted in the Google diagram at right) for the encryption - in the wake of vast improvements on the part of TLS.

So if WebSocket is something the Web browser community has been working to implement anyway, what exactly is Microsoft's motive for attaching WebSocket (or at least, a reference to WebSocket, depicted below) to its counter-proposal for HTTP 2.0 to the Internet Engineering Task Force? Normally a look at the technical breakdown of the draft would yield clues. But as of now, that section of the public part of Microsoft's draft remains blank.


"The HTTP Speed+Mobility proposal starts from both the Google SPDY protocol (a separate submission to the IETF for this discussion) and the work the industry has done around WebSockets," states Jean Paoli, Microsoft's much respected interoperability manager, in a blog post earlier this week. "SPDY has done a great job raising awareness of Web performance and taking a 'clean slate' approach to improving HTTP to make the Web faster. The main departures from SPDY are to address the needs of mobile devices and applications."

That's the "Mobility" part of Microsoft's version of HTTP 2.0, and it's the part that gives the proposal the unfortunate abbreviation "HTTP S+M." ReadWriteWeb has contacted Microsoft with questions about its intent for the Mobility part, and was told a final response may be forthcoming.

This Page Intentionally Left Blank

Other parts of the public portion of Microsoft's draft proposal read like an argument than a specification. For example: "There is no 'one size fits all' deployment of HTTP. For example, at times it may not be optimal to use compression in certain environments. For constrained sensors from the 'Internet of things' scenario, CPU resources may be at a premium. Having a high performance but flexible HTTP 2.0 solution will enable interoperability for a wider variety of scenarios. There also may be aspects of security that are not appropriate for all implementations. Encryption must be optional to allow HTTP 2.0 to meet certain scenarios and regulations."

One of the long-time problems with Web session encryption is that it tends to be used only in important transactions. Thus the very fact that a session is encrypted generally tells you it should be. Encrypting everything would make it impossible for a sniffer to judge, just from the nature of the stream, what traffic is likely to contain important data.

Here, Microsoft appears to suggest that such a feature may optionally be turned off, perhaps to reduce power and time consumption on smaller devices, and perhaps to enable more "Internet of Things" scenarios. But some would argue that HTTP is an inappropriate protocol for inter-device communication anyway - that an IoT would not necessarily be a Web-of-Things.

Then there is the issue of client/server style communication. As you might imagine, one of the companies making inroads with WebSocket (singular or plural, depending upon whom you ask) is Microsoft itself. But by bringing up a W3C application-layer protocol - one which is likely to be fully adopted anyway - in the context of an IETF transport layer technology, is Microsoft's goal really to expedite this discussion or to slow it down... like it did once before?

HTTP 1.0's deficiencies and omissions are legendary, and its usefulness in the modern realm of Web applications has come only with substantive effort. The need to replace HTTP 1.0 was recognized by cooperating members of the IETF from the time the Web began.

But the first, best chance at upgrading HTTP with an object-oriented protocol geared toward apps came and went in 1999. HTTP-NG, as it was called at the time, ceased to be discussed not long after some of its creators were hired into Microsoft Research. A technology that would have enabled Web applications a full decade-and-a-half before the form factors for such apps were even fleshed out, stalled for lack of momentum - all in the interest of "open discussion." There's a danger here that Microsoft's move could cause the latest incarnation of HTTP 2.0 to suffer the same fate.



Stock image by Shutterstock