support for Firefox 6 native websocket

[Hendler]

Sorry - I haven't verified the issue yet - but the source does not appear to have MozWebSocket

https://github.com/search?type=Code&language=JavaScript&q=MozWebSocket+web-socket-js&repo=&langOverride=&x=23&y=21&start_value=1

Hacker News - http://news.ycombinator.com/item?id=2891489

"Mozilla is supporting a new version of websockets (https://bugzilla.mozilla.org/show_bug.cgi?id=640003) that as of a week ago did not work with a lot of popular libraries yet (socket.io). Its awesome to see better security features in place and I hope that library distributors are fast to follow up with changes in their library."

"For what it’s worth, you have to update your client code to instantiate a MozWebSocket and update your server to support the latest protocol. I know, because I’ve done this today :) We’re using the em-websocket gem though which has been updated recently so it really wasn’t that difficult."

Sorry, I haven't tested if this is a valid issue.

[gimite]

Thanks for the information.

First, you can still use MozWebSocket without modifying web-socket-js, simply by using MozWebSocket instead of WebSocket.

Second, I don't have clear idea how to handle MozWebSocket in web-socket-js. Maybe we should just WebSocket = MozWebSocket when available? Does anyone know why it's MozWebSocket, not WebSocket? Is it just because WebSocket is not official standard yet?

If we decide to do that, it should be after we switch the default to hybi-10 protocol. Because Firefox 6/7 speaks hybi-07 and hybi-10 protocol.

One small concern is that Firefox 6 is the only browser which speaks hybi-07 protocol. So some developers may prefer Flash implementation to MozWebSocket, to avoid implementing support for hybi-07 in server side just for Firefox 6.

[kanaka]

I tried to convince the Mozilla guys that at this point (since Chrome 14 doesn't prefix it) that the prefixing didn't serve much purpose but I wasn't successful in arguing the point. So Mozilla will probably use the Moz prefix for the next couple of browser versions.

The most correct behavior for web-socket-js would be to not define anything if MozWebSocket is defined and the Javascript application should detect whether MozWebSocket is defined. Then again, I'm not sure that is the most useful to users of web-socket-js so maybe we should work around Mozilla's prefixing by detecting MozWebSocket and redefining it as WebSocket

That does bring up an interesting new thought however. One new uses of web-socket-js in the coming months might be to allow web app developers to continue to use the older version of the protocol when the browser only supports the new protocol (and their server only supports the old protocol). This would allow the developers to continue to use websockets on all browsers even though their server may not support the new version of the protocol. So we might want to consider distributing the older version until all servers have support for the new protocol. Maybe even with a different namespace such as HixieWebSocket. Just a thought.

[gimite]

One new uses of web-socket-js in the coming months might be to allow web app developers to continue to use the older version of the protocol when the browser only supports the new protocol (and their server only supports the old protocol).

This can be done by recently added flag WEB_SOCKET_FORCE_FLASH.

[kanaka]

gimite, true. But what I meant is that even after we make the new protocol the default, we may want to maintain a branch of the old version (and mention this in the README) for a while so that web app developers can continue to use the old protocol until they are able to update their server implementations to versions that support the new protocol. I.e. web-socket-js could be the shim that allows backwards compatibility for a while to smooth the upgrade process.

I already have noVNC/websockify updated to support the new protocol so it won't affect me personally that much. Just a thought.

[gimite]

Yeah I'm planning to leave the old branch as is so that people really need it can use it, but I'll not actively maintain/support it. People should switch to new version :)

[ghost]

I think a single library should support all socket version. For example new or old version of a spec: I write a .js app that is used by 1MM people. Some use different version of browsers. Some users could fail over to flashsocket, and some could not if I pick a swf.

Proposed solution: I could in .js detect the version of browser they have and then pass in 'flags' into the swf to tell it which implementation to use. When I write an js. webapp, it gets used by users on the www. Some have old browser. Some have new. (This is not an issue in .as, only in .js)

[TooTallNate]

@puppetMaster, maybe you're looking for something like socket.io, which uses this flash websocket library underneath the hood...

[ghost]

Thx TooTalNate. I was talking client side.

(Server side, I found socketio to be a buggy, my project: http://search.npmjs.org/#/gamina uses websocket server, where I try for .js websocket native ... and fail manually to pure .as using gimite).

[kanaka]

It's not an issue of client-side version. Javascript can't detect what version of the protocol the server supports (you'll just get back an error when you try to connect). The version of web-socket-js that is served to the client should match a protocol version that the server supports so that the client and server can talk to each other. Allowing the Javascript to pick the version doesn't address the problem. The web application developer should switch the version of web-socket-js that is used when the server protocol version switches (the web application developer may or may not have control of which version the web socket server supports but he does have control of which web-socket-js object he serves).

On the other hand, having the ability to force web-socket-js to be used instead of the browser's native websocket support is useful for the case where the server and and native client support different web socket protocols. The native version supported by the browser can be inferred to some degree either by some object detection or at worst by browser version knowledge. If the Javascript app detects that the browser's native support doesn't match a version that the server supports then the app can force the web-socket-js to be used (which like I said, the version of web-socket-js sent by the server should be kept in sync with the protocol version the server uses).

[ghost]

ok, got it, thx.

[kanaka]

I corrected a typo in my previous statement. I should have said "but he DOES have control of which web-socket-js object he servers).

[gimite]

Done.

[Hendler]

thanks!