WebSocket Update
A few weeks back I published a post about the awesome new technology that is WebSockets and a great WebSocket wrapper called Socket.IO. The HTML5 WebSocket API provides socket connection support for faster messaging between client and server. Consider WebSocket an optimized AJAX solution. SocketIO provides both server and client side solutions to use WebSocket. WebSocket is a great match for Comet technologies (GChat, Facebook Chat, etc.). Unfortunately it looks as though WebSocket revolution will need to be put on hold.
Bug 616733 in Mozilla bug tracker details Mozilla's plans to disable WebSocket in Firefox 4, enabled only by updating a pref setting. A Geolocation-style Firefox prompt was proposed but did not gain support. The reason for disabling WebSocket is a Google report detailing security issues with the current WebSocket protocol. That report is available here. Apple was recently known to be considering disabling WebSocket in Safari as well.
While WebSocket being disabled is a blow, web security grows increasingly important. Hopefully a new WebSocket protocol draft is soon released so we can unleash the power of WebSocket!
Very interesting paper, I’m glad to see that the browsers hold themselves to higher standards than other platforms for the sake of security. I have generally been ambivalent about WebSockets though. Other than outperforming AJAX is there really much more it can do? When I work with the Flash platform to utilize a socket connection I’m usually doing so to pull some kind of byte information to convert into something else, such as streaming music that needs to be pulled apart and put back together ( e.g. stripped of its metadata and spliced together again). I understand that theoretically WebSockets could do this, but only from a client-side perspective.
Usually when I am using a socket to get information from a server it is a special type of server for a specific type of media (e.g. SHOUTcast for music or video, etc). The problem with WebSockets is that it wants me to go into the server side so that custom responses can be sent back to the client in order to validate security measures. This inherently limits WebSockets as it is much harder for out-of-the-box server software to be modified to send custom responses based on custom headers than it is to validate based on a site-root xml file, like Flash does. This is what I love about Flash’s protocol, I often find myself in a situation where I don’t have control of the server to the extent that I would like, but Flash offers a way around this problem, while sacrificing security only minimally or not at all.
There is also another simple consideration to be made that makes Flash easy to use. Flash doesn’t need to validate security in its development environment. As a developer when I’m testing Flash in Flash builder I can see a server’s output without having to do anything to the server. This is a tremendous advantage as it allows me to do a lot of preliminary research on a project without much effort (ie going into a server and modifying its responses to the client). This is starting to sound like an infomercial for Flash, but I don’t mean it to. I genuinely want JavaScript/HTML to be superior to Flash, but as a developer, even given the spec as it stands I can’t help but see that Flash offers features that make it much better. Any thoughts?
nathan sweet: What WebSockets can do is that a connection can be left open so that the server can let the client know when something is updated or ready as opposed to AJAX where the client has to poll the server all the time.
@Johan:I think you only read my first paragraph. I understand what a socket connection is. The reason I compared it to AJAX, is that it would be able to accomplish AJAX-like tasks at a much higher speed (pulling really simple data like latitude and longitude points for a Google Maps mash-up, calling for simple text information about a user, etc), but it wouldn’t be able to manipulate byte-data as effectively as other socket-connecting platforms, and I list my concerns in the subsequent paragraphs.
Well, if you use the Socket.IO library, it should fall back naturally to other means while the vendors sort out the problems with WebSocket right?
Yes, but as always, you want the most optimal solution. AJAX-longpolling isn’t optimal which is why WebSocket was created.
How suboptimal it is depends greatly on your application. Most web applications can do perfectly on long-polling + Keep-Alive, with only negligible differences with WebSocket (and also advantages over it, like proxy bypassing).
We’ve also put together some thoughts on the situ: http://blog.pusherapp.com/2010/12/9/it-s-not-websockets-it-s-your-broken-proxy
Maybe i’m too optimistic about websockets, but i think this security issue doesn’t influence any development of websocket applications. If you want to make a public websocket app, then please wait until a new – more secure – handshake mechanism is released(or keep your app within the intranet). This security issue seems to be a proxy problem rather than a websocket problem anyway. Until then, no worries for testing new ways of delivering content. Websockets can do much more than just webchat. I think they can completely replace page-requests within a site. I’m currently experimenting with this(https://github.com/phrearch/hwios/wiki/Hwm) on a realtime wiki based on the infinote protocol(jinfinote) and websockets to allow multi-user viewing/editing of pages. What i like about websockets compared to flash is that you can easily integrate websocket messaging with other javascript and the DOM offcourse.
I spent weeks writing HTML5 games and I’ve just read this :( Back to long polling for now!
If cross-browser-compatibility is an issue, then websockets are probably not interesting for most developers. However i’m convinced that’s just a matter of time before a new draft will be released(which only should take minable amount of work to adapt). In the meanwhile I don’t see a problem to just advise users to use browser x, that supports websockets .76. I wrote something about a websocket CMS(http://hwios.blogspot.com/2011/01/websocket-cms.html), replacing HTTP as transport. I think it’s more efficient to keep a persistant connection within one site.