WebSockets Hits a Snag: The Perils of Rapid Change

When I sat down to write this post, the main subject was going to be some of the Really Cool Stuff that can be done with the WebSocket API, a nifty W3c specification-in-training for bi-directional communications between Web apps and servers. The API is simple and relatively clean, had been getting strong support in the latest crop of browsers, and it something that will really enhance the Web applications of the future. With WebSockets, you can build nifty client-server communications (think AJAX on steroids), client-to-client apps (e.g. chat) and broadcast features. Once you take a look at what it can do, you’re going to want to play with WebSockets. And this is a cornerstone of the new foundation of HTML5.

Unfortunately, the rapid progress towards getting WebSockets into the market has hit a road bump.

A recent security study detailed a major problem with the UPGRADE-based  semantics used to piggyback the WebSockets communication over the existing HTTP channel. The problem isn’t in the mechanism itself; rather, it has do with any transparent proxies that may be sitting between the web server and the client. Many of the existing proxies out in the wild don’t understand UPGRADE and therefore accidentally cache the WebSocket communications as if they where regular HTTP. This leaves a door open for attackers to poison the cache in such proxies. This could lead to some real bad mojo, since the proxy is by nature hard to detect and track and with the possibility of injecting harmful code into a vast numbers of victim browsers.

The paper has outlined a potential solution, based on a different and more widely used method of connection upgrade in HTTP. Given the speed that things are moving in the HTML5 world, I would expect that things will be back on track in a few months. But there is some fallout from this decision.

Mozilla and Opera have pulled WebSockets support for now, and Chrome will too if an exploit appears in the wild. I bet there a similar contingency being planned at Apple for Safari. So we’re going to have to wait a little longer before WebSockets is ready for prime time.

Don’t Forget: HTML5 Ain’t Baked Yet

We are living interesting times. My last post detailed some issues with the evolving Web SQL Database API. Or rather, the then-evolving API; the standard ran into some issues last year and by the end of November, worked on it was halted. The Indexed Database API is likely to be the successor, but there aren’t any implementations for production browsers just yet.

The fact is that the HTML5 complex is still evolving rapidly and shifting on a almost daily basis and along multiple dimensions. This is both great news and a source of headaches for Web developers. We’re seeing an explosion of exciting standards-oriented specs and protocols that are pushing the capabilities of the Web forward faster than ever before. At the same time, the sands are shifting under our feet and core technologies are popping up (and sometimes sinking) at a rate that’s hard to absorb.

P.S: If You Want WebSockets NOW

If you’d like to play with WebSockets in a forward-compatible (and backward-compatible) way, you might want to take a look at Socket.IO.  This library works with node.js and supports fallbacks using other technology in case WebSockets doesn’t work with your browser of choice. It’s a great way to get the benefits without have to worry about the specifics of which method is used to enable the behavior.