The header part of a frame....again

I'm connecting to a simple server from firefox 40.0a2 and send something.

At first I was using an old version of websocket-sharp.dll binary
(it was bundled w/ the WebSockets.unitypackage here http://forum.unity3d.com/threads/unity5-beta-webgl-unity-websockets-plug-in.277567/ )

Then I had to see that sometimes some bytes in the payload are zeroed.

It seems deterministic, the same file always gets corrupted the same way.

So I thought maybe it works on master, cloned into it, compiled, ran my server, connected from js, sent something and bang - WebSocketException ( "The header part of a frame cannot be read from the data source."); was thrown.

After some fiddling I found out that removing the server_no_context_takeover and client_no_context_takeover extensions fixes this problem for me. (They were not sent with the old binary)

When I use master w/o patching out this extensions the ReadBytesAsync-callback in the WebSocketFrame.cs receives an byte[0], checks header.Length and fails.

After patching out those context_takeovers (whatever they're supposed to do) in my clone from master I can receive data again, but the data is corrupted in the same way as in the old version, so now I'm back to investigating why this is happening to me (maybe my code in the browser already f**ed up before websocket-sharp received the bytes, maybe it's another issue w/ websocket-sharp, maybe mozilla .... hope I'll find out soon)

UPDATE: I managed to capture the bytes from the browser to my server via RawCap, wireshark reads the .pcap, already does the unmasking, after deflating the bytes with 5 lines of C# I see the \0 bytes there too - so this is probably not a problem w/ the library, it happens before that

UPDATE 2: I tried the same thing with chrome, there I get the "The header part of the frame" exception always. it doesnt matter if I compile websocket-sharp with or without the _no_context_takeovers

UPDATE 3: it seems to be firefox..: it works if i set network.websocket.extensions.permessage-deflate to false in the about:config

if I set it to true things get really strange...
here is what i send and what comes out at the other end:

test                    \0\0\0\0
tes test                \0\0\0 \0\0\0\0
te tes test             te \0\0\0 \0\0\0t
tte tes test            tte \0\0\0 \0\0\0t
this is another test!   this is another \0\0\0\0!
t te tes test           t te tes test
tes tes te              \0\0\0 \0\0\0 \0\0
testyucrap              \0\0\0\0yucrap

UPDATE 4: about the null-bytes, it really seems like this is a firefox-problem, i filed a bug over there...: https://bugzilla.mozilla.org/show_bug.cgi?id=1176176

UPDATE 5: chome seems to do the same thing as firefox

UPDATE 6: I just found issue #120, setting IgnoreExtensions now fixes the null-bytes without me having to change the browser default settings, chrome still tails with the header part...

Start with WebSocketFrame.cs and the ReadBytesAsync callback, then review issue #120 and the permessage-deflate handling. Reproduce the behavior with Firefox and Chrome using the extension settings described in the report. Done means establishing whether websocket-sharp mishandles negotiated context takeover or documenting that the corruption originates in the browsers.