Websockets handshake problem

I created a websockets server in Python (based in this gist) that works in localhost but not in production server.

For example, in localhost I have the following Handshake's messages:

//Message from webbrowser client

GET / HTTP/1.1
Upgrade: WebSocket
Connection: Upgrade
Host: 127.0.0.1:8080
Origin: null
Sec-WebSocket-Key1: ]2 415       401   032v
Sec-WebSocket-Key2: 2y7   9Y2o 80049 5
Cookie: (...)

t��t`��


//Response of server

HTTP/1.1 101 Web Socket Protocol Handshake
Upgrade: WebSocket
Connection: Upgrade
WebSocket-Origin: null
WebSocket-Location: ws://127.0.0.1:8080/
Sec-Websocket-Origin: null
Sec-Websocket-Location: ws://127.0.0.1:8080/

�@2�J��3@5��ƶ

When I run the same webssocket's server in production, the connection fails. In Chrome's console I get following error: "Error during WebSocket handshake: 'Connection' header value is not 'Upgrade'" - But in Handshake's messages between server and client the connection (from server) have the right value:

//Message from webbrowser client

GET / HTTP/1.0
Host: myserver.com
X-Forwarded-Host: myserver.com
X-Forwarded-Server: myserver.com
X-Forwarded-For: 189.6.133.224
Connection: close
Upgrade: WebSocket
Origin: http://myserver.com
Sec-WebSocket-Key1: 2 1)Gz 11919la 978
Sec-WebSocket-Key2: c94Q6b9^ef#`6 2v {652
Cookie: (...)


//Response of server

HTTP/1.1 101 Web Socket Protocol Handshake
Upgrade: WebSocket
Connection: Upgrade
WebSocket-Origin: http://myserver.com
WebSocket-Location: ws://myserver.com/websocket/server
Sec-Websocket-Origin: http://mys开发者_StackOverflow社区erver.com
Sec-Websocket-Location: ws://myserver.com/websocket/server

yz�~�r}��+�4J

In production I got some strangers values in client's message:

• Where is the crazy code at the end of message?
• The value of 'Connection' header is 'close'?!

Someone has any idea of why I got this error and why the client handshake have these values?

---

• What is the crazy code at the end of the messages?

The 8 raw bytes at the end of the client handshake is essentially the third key value . The 16 raw bytes sent back by the server is the digest that was generated from the 3 key values in the client handshake. This is how the digest works in the current Hixie-76 version of the protocol. In the new IETF/HyBi versions of the protocol (that will soon be released in browsers), the digest mechanism doesn't use special raw bytes anymore.

• Why is the value of 'Connection' header set to 'close'?

It looks to me like there is an intermediary (i.e. web proxy or transparent proxy) that is modifying the handshake from the client before it reaches the server. It's not only the Connection header that is wrong, but the client handshake is also missing the third key value either. In fact, one of the reasons the HyBi versions of the protocol use a different digest mechanism is to be more compatible with intermediaries.

Suggestions:

If you client and server are on the same network and you have a proxy setting in Chrome, try disabling the proxy temporarily and see if that works.

If the client and server are not on the same network and you have control of two machines on the same network, then try running the client on one and the server on the other (and still make sure you have no proxy settings in Chrome). That should eliminate the possibility of a transparent proxy/intermediary messing with the handshake.

If you are certain that Chrome is at fault, and not an intermediary, you can check for sure by running wireshark on the client while you make the connection and you can inspect the actual packets. If Chrome is really sending that exact handshake then it's possible that something about your configuration is triggering a Chrome bug.