support for Firefox 6 native websocket #87

Closed
Hendler opened this Issue Aug 16, 2011 · 13 comments

Projects

None yet

4 participants

Hendler commented Aug 16, 2011

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.

Owner
gimite commented Aug 18, 2011

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.

Contributor
kanaka commented Aug 18, 2011

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.

Owner
gimite commented Aug 20, 2011

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.

Contributor
kanaka commented Aug 22, 2011

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.

Owner
gimite commented Aug 25, 2011

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
ghost commented Aug 28, 2011

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)

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

@ghost
ghost commented Aug 28, 2011

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).

Contributor
kanaka commented Aug 29, 2011

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
ghost commented Aug 29, 2011

ok, got it, thx.

Contributor
kanaka commented Aug 29, 2011

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).

Owner
gimite commented Dec 17, 2011

Done.

@gimite gimite closed this Dec 17, 2011
Hendler commented Jan 8, 2012

thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment