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!

KorHosik
  • 1,225
  • 4
  • 14
  • 24
  • 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. – pimvdb Sep 09 '11 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. – KorHosik Sep 09 '11 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). – pimvdb Sep 09 '11 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! – KorHosik Sep 09 '11 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: http://stackoverflow.com/questions/7040078/not-sure-how-to-frame-data-in-websockets-draft-08/7045885#7045885. – pimvdb Sep 09 '11 at 15:51

1 Answers1

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

Community
  • 1
  • 1
kanaka
  • 70,845
  • 23
  • 144
  • 140
  • 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 ^^' – KorHosik Sep 09 '11 at 18:57
  • You might want to take a look at [Socket.IO](http://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). – kanaka Sep 09 '11 at 19:41
  • @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 ;-) ). – kanaka Sep 09 '11 at 19:43
  • Socket.IO seems to be very interesting, I will see that. Thanks! =) – KorHosik Sep 09 '11 at 20:07