Hi Chris, I'm quickly jumping into this thread because I'm seeing something strange :
On Wed, Feb 27, 2013 at 10:35:16AM -0500, Chris Yang wrote: > Hello again, > > Regarding the second problem (failure to establishing websocket connections > in supported browsers), I can confirm that it happens on both Chrome and > Firefox. And below is what I see for the '101 Switching Protocols' request > in Firefox when it happened: > > Request URL: https://www.myexample.com/sockjs/673/nw56jyoj/websocket > > <https://www.playmymodel.com/sockjs/chat/673/nw56jyoj/websocket> > > Request Method: GET > > Status Code: HTTP/1.1 101 Switching Protocols > > *Request Headers > > *User-Agent:Mozilla/5.0 (Windows NT 6.1; rv:18.0) Gecko/20100101 > > Firefox/18.0 > > Upgrade:websocket > > Sec-WebSocket-Version:13 > > Sec-WebSocket-Key:Fg8Z/EASgn6AlVh0hMYLtw== > > Pragma:no-cache > > Origin:https://www.playmymodel.com > > Host:www.playmymodel.com > > Connection:keep-alive, Upgrade > > Cache-Control:no-cache > > Accept-Language:en-US,en;q=0.5 > > Accept-Encoding:gzip, deflate > > Accept:text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 It's unusual to see the client write both keep-alive and Upgrade in the connection header. Thus, I suspect that something between the client and the server (eg: a proxy on the client side or the application server itself) has added it. If it's a proxy on the client side, this proxy might be responsible for this. Not all proxies support WebSocket yet. You should try to take a capture of the front traffic (between client and haproxy), and isolate a session which exhibits this behaviour (based on the IP address logged as reporting the problem). In such a capture, we'll see if the server response is valid, and if it is the client which closes. If we see the client close, we'll know that there's something between the client and haproxy which doesn't support WebSocket. > > *Response Headers > > *Upgrade:websocket > > Sec-WebSocket-Accept:NxU0HFQKbhwr7VBCHf23qLXH/Ic= > > Connection:Upgrade > > > and below is what follows from the SockJS side: > > Closed transport: websocket SimpleEvent(type=close, code=2007, > > reason=Transport timeouted, wasClean=false) > > > This failure of establishing websocket connection happen relatively often > now, with 4 - 5 Chrome processes running on my laptop, I can almost always > get at least 1 Chrome which encounters this. In addition, I have also > tested this with HAProxy 1.5-dev15, and the problem persists. For > completeness, I attach the updated config as below: Hmmm if you can easily reproduce it, this becomes more of a concern. Are you sure you're directly connected ? Would you happen to be running windows on your laptop with some anti-virus/anti-malware or such software ? We've seen that in the past, it was Trend Micro's OfficeScan. It would let traffic to port 8000 pass without issue, but 80 was improperly analysed and the connection was frozen. It would be possible that a similar type of software is causing the issue. There's nothing abnormal in your configuration. I'm seeing a redirect for http->https, have you tried without SSL ? Willy
