Chrome 46 - Problems with `Sec-WebSocket-Extensions`

I don't think this is the same as #166 and so I've raised a separate issue. These issues may be in the same ballpark though.

I've had problems getting rc9 to work with Chrome 46. It appears to be related to Chrome sending permessage-deflate; client_max_window_bits as a Sec-WebSocket-Extensions header. WebSocket-Sharp responds with the extension header permessage-deflate; client_no_context_takeover; server_no_context_takeover which is all too much for Chrome; it curls up and dies with WebSocket connection to 'wss://mylocation:13000/something' failed: Invalid frame header

IE by contrast doesn't send any Sec-WebSocket-Extensions headers and so, crucially, doesn't hit this code path:

https://github.com/sta/websocket-sharp/blob/master/websocket-sharp/WebSocket.cs#L673

Basically processSecWebSocketExtensionsHeader doesn't get invoked for IE.

The immediate workaround appears to be ensuring that IgnoreExtensions is set to true so processSecWebSocketExtensionsHeader is never called.

I'd be interested if anyone has any insights as to why this might be problematic.

Interestingly it looks like initial frames come through correctly and subsequent ones fail. I enclose screenshots from my Chrome devtools to illustrate:

Start in websocket-sharp/WebSocket.cs at the referenced lines around 673 and processSecWebSocketExtensionsHeader around 1100. Reproduce the Chrome 46 handshake and compare it with the IgnoreExtensions workaround and IE behavior. Done means identifying why the negotiated extension leads to later invalid frame headers and addressing the failing path without relying on the workaround.