python - Websockets handshake problem -

i created websockets server in python (based in gist) works in localhost not in production server.

for example, in localhost have following handshake's messages:

//message webbrowser client  / 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 run same webssocket's server in production, connection fails. in chrome's console following error: "error during websocket handshake: 'connection' header value not 'upgrade'" - in handshake's messages between server , client connection (from server) have right value:

//message webbrowser client  / 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://myserver.com sec-websocket-location: ws://myserver.com/websocket/server  yz�~�r}��+�4j 

in production got strangers values in client's message:

• where crazy code @ end of message?
• the value of 'connection' header 'close'?!

someone has idea of why got error , why client handshake have these values?

• what crazy code @ end of messages?

the 8 raw bytes @ end of client handshake third key value . 16 raw bytes sent server digest generated 3 key values in client handshake. how digest works in current hixie-76 version of protocol. in new ietf/hybi versions of protocol (that released in browsers), digest mechanism doesn't use special raw bytes anymore.

• why value of 'connection' header set 'close'?

it looks me there intermediary (i.e. web proxy or transparent proxy) modifying handshake client before reaches server. it's not connection header wrong, client handshake missing third key value either. in fact, 1 of reasons hybi versions of protocol use different digest mechanism more compatible intermediaries.

suggestions:

if client , server on same network , have proxy setting in chrome, try disabling proxy temporarily , see if works.

if client , server not on same network , have control of 2 machines on same network, try running client on 1 , server on other (and still make sure have no proxy settings in chrome). should eliminate possibility of transparent proxy/intermediary messing handshake.

if chrome @ fault, , not intermediary, can check sure running wireshark on client while make connection , can inspect actual packets. if chrome sending exact handshake it's possible configuration triggering chrome bug.