1

I've been using websockets without an issue for months to communicate between Chrome and my localhost app. Suddenly, with the latest version of Chrome, data is not going through cleanly.

In the Chrome extension's javascript, the relevant part of the code is:

window.ws = new WebSocket("ws://localhost:13000/");

window.ws.onopen = function () {
    window.ws.send('GO');

In my C# app:

string msg = ASCIIEncoding.UTF8.GetString(buffer);
Debug.WriteLine(msg);

For months this worked fine and I would get "GO" back out day in, day out. Now what I'm getting on the receiving buffer is 4 bytes {114,247,7,0) which does not translate to "GO" in any encoding I can find. Anyone have any idea what could be happening? I'm bemused as I have not touched either end of code (chrome or listener).

Cheers!

PS: The full Chrome Version 19.0.1084.15 beta-m

Jimmy Sawczuk
  • 13,488
  • 7
  • 46
  • 60
Jamona Mican
  • 1,574
  • 1
  • 23
  • 54
  • To rule out this being a Chrome bug, you could try temporarily switching to Chrome's dev track (currently on v20.x) to see if the bug is still reproducible. – simonc Apr 13 '12 at 08:26

2 Answers2

2

Figured it out. Turns out Chrome has just enabled compression on websockets by default. I just needed to modify the websocket server on my end to refuse that extension and Chrome reverts to plain text.

Jamona Mican
  • 1,574
  • 1
  • 23
  • 54
0

Read some data regarding Masking. Browser may send messages with Masking enabled, and it will add extra 4 bytes into frame that will apply masking to your messages. Browsers may have it enabled or disabled, so on server side you should support both and use masking if frame contains masking enabled bit.

Check out how masking is applied based on RFC 6455

Community
  • 1
  • 1
moka
  • 22,846
  • 4
  • 51
  • 67
  • RFC6455 mandates that browsers always use masking (see section 5.1). Are you aware of browsers that don't mask their data? – simonc Apr 13 '12 at 09:41
  • Have no specific examples, but had working proxy that was processing messages and changing their framing. That was advanced (not public) proxy. As well beta or testing versions of browsers may have options to control masking. As well when you send from server, you might have enabled or disabled masking, and browsers still ok to work it out. If there is such option of enabling / disabling mask, I would recommend to bear in mind in implementation such possibility. – moka Apr 13 '12 at 09:45
  • 1
    The RFC also mandates that servers do not use masking although some servers ignore this and mask all their messages. [SO's](http://stackoverflow.com/questions/10061903/websocket-traffic-encoding-gzip/10063214#10063214) for example. Browsers aren't yet rigorous enough to reject this. – simonc Apr 13 '12 at 09:56
  • Thanks but it looks like it was Chrome recently introducing compression, as a default. I just had to change the websocket server to reject Chrome's compression through the extension negotiation mechanism. – Jamona Mican Apr 13 '12 at 12:49