7

I'm currently working with WebSockets and a PHP server: it works very well with Google Chrome and Opera, but not with Firefox 6.

I think it's due to the protocol version this last uses: I see somewhere that it uses the seventh version, whereas it's an older one for Google Chrome and Opera.

So, I modified my server code in order to manage this new version: by hashing the secure-key with 258EAFA5-E914-47DA-95CA-C5AB0DC85B11 and other stuffs, Firefox succeeds to connect. But if another client wants to connect (even another Firefox), the first one with Firefox deconnects itself.

I saw that buffer received by socket_recv() is either empty or hashed...

So I decided to skip the idea of managing the protocol used by Firefox 6 (there are no documentation on Internet... !): I think it could be easier to specify the protocol to use directly in JavaScript.

On this page they say that we can write this:

var mySocket = new WebSocket("http://www.example.com/socketserver", "my-custom-protocol");

But what should we write instead of "my-custom-protocol" in order to use the protocol managed by Google Chrome and Opera?

Thanks in advance!

Improve this question
5
  • There is the hybi-00 version which is also called hixie-76 and includes the two binary keys. There is also the new hybi-07 which uses that secure key you posted. You'd have to generate a correct handshake depending on which version the handshake request is. Since both versions use different header names for the keys, that should be possible. Commented Sep 9, 2011 at 14:47
  • Thanks for your answer! So I've tried this one: var mySocket = new WebSocket("http://www.example.com/socketserver", "hybi-00"); but the header sending by Firefox is still the same... The only difference is now there is Sec-WebSocket-Protocol: hybi-00 in the header, but it still uses the seventh version. Commented Sep 9, 2011 at 15:10
  • I think I've not been fully clear. Each browser sends either version, and you can't control that. On the server, however, you can check what version has been sent, and respond appropriately (i.e. correct handshake response). Commented Sep 9, 2011 at 15:39
  • Oh, I see. So what is the purpose of the second parameter of WebSocket constructor if it changes nothing on the server-side? To come back to my problem, I think that the handshake is correct because Firefox is connected. It's only the messages it receives that have a strange behavior... Never mind, I'll see that later, thank you again! Commented Sep 9, 2011 at 15:49
  • I honestly think you can ignore that custom protocol argument. For messages, there is indeed a huge change as to how these are sent with hybi-07. You cannot parse them the same way as hybi-00. It does support binary messaging that way though. I once answered another question about this, perhaps it helps: stackoverflow.com/questions/7040078/…. Commented Sep 9, 2011 at 15:51

1 Answer 1

Reset to default
11

The protocol option to the WebSocket constructor is really a "sub-protocol" (it is often called by that name) and it is an application level sub-protocol. It does not have any effect on the actual WebSocket protocol version. Browsers basically support a single version of the WebSocket protocol itself. Most servers support several versions of the protocol.

Firefox 6.0 introduced support for the new HyBi series of protocols (HyBi-00 is really just a copy of the Hixie-76 protocol). The HyBi versions introduce a new framing format for data and are not just a change to the handshake. Chrome 14 also uses the new HyBi protocol series.

Here is the most recent version of the WebSockets protocol: https://datatracker.ietf.org/doc/html/draft-ietf-hybi-thewebsocketprotocol-14 although firefox 6.0 is actually this one https://datatracker.ietf.org/doc/html/draft-ietf-hybi-thewebsocketprotocol-07 but there aren't really that many real changes (mostly textual changes to the spec itself).

Are you certain that firefox is connecting successfully (i.e. do you actually get an onopen event in the browser)?

Improve this answer
Sign up to request clarification or add additional context in comments.

4 Comments

Thanls for these clarifications! I've indeed received an onopen event, that's why I suppose that the problem comes from the way messages are sent (and pimvdb has confirmed that ^^). I've downloaded and tested with Google Chrome 14 and the same problem occured... Manage WebSockets seems to be so difficult for now, I think I will use Node.js or something else ^^'
You might want to take a look at Socket.IO which is a WebSocket layer that runs on Node.js and handles session management (and also has a fallback to long-poll if WebSockets is not supported by the browser).
@KorHosik, also if you think this answered your question sufficiently, don't forget to choose an answer for those that follow after (and for reputation of course ;-) ).
Socket.IO seems to be very interesting, I will see that. Thanks! =)

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.