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?
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.
In case you're wondering what <i>"this API will be temporarily namespaced"</i> means, see <a href="http://bugzil.la/659324" rel="nofollow">http://bugzil.la/659324</a>. 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()".
Rwaldron has some good coverage of this over at <a href="http://weblog.bocoup.com/javascript-firefox-aurora-6-and-eventsource-api" rel="nofollow">http://weblog.bocoup.com/javascript-firefox-aurora-6-and-eve...</a><p>Funny, I just posted this link to Rwaldron's coverage right before you posted to the link he is responding to.
IE does not inherently support WebSockets, so apps with worker threads will block. You can support WebSockets in IE clients using this hack:<p><a href="http://bit.ly/irM6XV" rel="nofollow">http://bit.ly/irM6XV</a>
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.<p>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.<p>The future-proof fix is to add some Cache-control header that says, "hey, this response is infinitely long! don't cache!".