Add/modify API to send and receive raw frames

[kapilreddy]

API change discussion for implementing Websocket extension permessage-deflate

I am implementing websocket extension permessage-deflate. (Refer: https://tools.ietf.org/html/draft-ietf-hybi-permessage-compression-21)

There are two problems with http-kit async handler API

• WSHandler will always assume that TextFrame has text data. This is correct for normal Websockets behavior but in case of permessage deflate extension the TextFrame contains compressed data.
• send function in AsyncChannel class dispatches on type of data. It will create a Websocket frame depending on type of data passed. But for permessage-deflate the compressed data is not a string but it needs to be part of a frame.

So problem is primarily divided into two parts sending and receiving. In both cases it is caused by the assumption that a TextFrame will always contain UTF-8 string data.

While API change for sending raw frame is non-breaking change. The API change for receiving data is breaking change.

[brunchboy]

I wonder if the lack of this is what is preventing http-kit from successfully responding to WebSocket requests from my browsers? I get [Error] WebSocket connection to 'ws://localhost:16000/ws' failed: Compressed bit must be 0 if no negotiated deflate-frame extension (1, line 0) from Safari, and WebSocket connection to 'ws://localhost:16000/ws' failed: Invalid frame header from Chrome. For now I am having to give up on the idea of using WebSockets.

[kapilreddy]

@brunchboy Can you check what response headers is server returning in the browser ? I think server/proxy might be responding with some WebSockets deflate-frame extension specific headers.

[brunchboy]

Whoops, I thought I had tagged that state of the project in Git, but I was missing a few files, so it took me a little work to get back to where I could reproduce it. As I thought I recalled, I do not see any deflate-related response headers. It seems to me (from what little I understand of the protocol) like the server is staying in a plain text mode, while the browser is expecting it to have switched to a binary format. Here is a Wireshark capture of the failed socket open attempt, for what it is worth. I am proceeding fine without web sockets, just polling for UI changes every 50 milliseconds. (This is fine because it is a local web server for lighting control software.)

GET /ws HTTP/1.1
Upgrade: websocket
Connection: Upgrade
Host: localhost:16000
Origin: http://localhost:16000
Cookie: ring-session=2a5669f9-9233-4e73-adaf-8b1a98e79403
Pragma: no-cache
Cache-Control: no-cache
Sec-WebSocket-Key: gaZD1uAyClGQiKKNiE6yrA==
Sec-WebSocket-Version: 13
Sec-WebSocket-Extensions: x-webkit-deflate-frame
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_3) AppleWebKit/600.6.3 (KHTML, like Gecko) Version/8.0.6 Safari/600.6.3

HTTP/1.1 101 Switching Protocols
Sec-Websocket-Accept: 5rbuZsHopy/NhUXHoOCBPUAJaQA=
Connection: Upgrade
Upgrade: websocket
Content-Length: 0
Server: http-kit
Date: Sun, 21 Jun 2015 18:10:22 GMT

HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
X-Xss-Protection: 1; mode=block
X-Frame-Options: SAMEORIGIN
X-Content-Type-Options: nosniff
Content-Length: 19
Server: http-kit
Date: Sun, 21 Jun 2015 18:10:22 GMT

{"welcome":"Hello"}

And again, this is the error reported for this transaction:

[Error] WebSocket connection to 'ws://localhost:16000/ws' failed: Compressed bit must be 0 if no negotiated deflate-frame extension (ws, line 0)