Firefox 4 ditched WebSockets for security reasons. Does anybody know the justification to add it back now? More specifically, do they fix the security issue of WebSocket, or do they just give up to the popular demand?
In the original protocol, it was possible to get two endpoints to transact over Websockets even if a middlebox between them didn't perfectly enforce the protocol. This is bad because it potentially confuses the middlebox about which parts of the stream are HTTP/1.1 requests or not, which can allow attackers to poison caches.
In the new protocol, Websockets traffic is (trivially) encoded so that it (a) can't accidentally be interpreted by either endpoint as something other than Websockets and (b) can't confuse middleboxes.
Basically, "new" Websockets has custom Websockets encryption that nothing other than Websockets will be speaking, so, if you're talking Websockets, it's because both endpoints consented to do so.
No, just the opposite - this change was necessary to get WebSockets to work with old, broken proxies. Previously those proxies might interpret part of the body of the WebSocket traffic as an HTTP header; now they will correctly just pass the traffic through.
That's good news, WebSockets is probably the second coolest thing to come out of the HTML5 movement, right after WebGL I think. Everything else is cool and all but those two are major changes.
I'm also happy and couldn't agree more, but I would make it more generic: Canvas/WebGL is the huge change. And I would add Local Storage as a distant third to WebSockets' strong second. The rest is fun but not game changing.
Yeah that's true, Canvas is a huge win also. I use both extensively for my current work project. The File Api is also pretty awesome, I'd tie it up to local storage. In the field (Medical imaging) I'm in, allowing users to load data from their computer with no round trip to the server is very important. It helps for security reasons.
It has unlimited storage if you use Chrome's Webstore. I suppose it will just take a while before the other browsers can figure out how to implement it the right way for more than 5 MB of storage.
There's a difference between cool and important. pushState isn't that cool as we can almost do the same thing without it (#!), but web sockets are a whole new concept. That said, for sites that don't constantly update, pushState will be more useful than web sockets.
In case you're wondering what "this API will be temporarily namespaced" means, see http://bugzil.la/659324. Before Firefox 6 is pushed to the release channel, the constructor will will be changed to "new MozWebSocket()". Once the JavaScript API is stabilized, it will be changed back to "new WebSocket()".
Anything that Comet or other long-polling techniques provide, really.
The advantages of WebSockets include constantly changing specifications which are neither backwards- nor forwards-compatible, a lack of proxy traversal, an arbitrary and unreasonable limitation on binary data transfer, and lack of unified browser and server support.
It's not that bad. Right now you basically have support for the -76 protocol in release channel Chrome and Firefox 4 or 5, it's nearly trivial to support all of those with a single server.
With Firefox 6.0, I had to spend some time to upgrade our little Python server, but now it happily serves both -76 and -07. It also looks like -07 is very close to being signed off on as the actual standard, so the compatibility problems are probably a thing of the past soon (-76 and -07 are actually completely trivial to discern from a server point of view).
I haven't tried with binary data, but it looks like it's explicitly supported with -07. Not sure about proxies, they aren't relevant to our work app.
For server side development, I've found that Jetty has a good websockets API. I had difficulty getting the server and browser to agree a few months ago when I tried it (common libs in python and C# were tested). Moving to Jetty got it working. I'm not sure how current it is though.
In practice, things like Base64 encoding are used. That's what we use in Ganeti Web Manager to host a noVNC (HTML5 VNC client) and have it talk WebSockets with the backend.
In theory, there's no good reason we can't have binary frames; I have internally filed it under the "Why can't we have nice things?" category.
WebSockets will generally provide latency improvements over long-polling as they won't have the overhead of creating and breaking down many HTTP connections (as to "push" using long-polling you need to return to the browser). XHR-multipart communication is better than long-polling, but only Firefox supports it.
I still don't understand "web" sockets. I mean, to get a web page, I already have a TCP connection. TCP connections are bidirectional. All we need is for the browser to write stuff to the socket and read stuff from it.
Yes, I understand that proxies may assume HTTP is request/response... but that's fine. My app breaks when you use that proxy. I can live with that.
The future-proof fix is to add some Cache-control header that says, "hey, this response is infinitely long! don't cache!".
