Hi Willy, Thanks for your comments.
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. The extra keep-alive in connection header seems to be a Firefox thing. For example, SockJS mentions about it here: http://sockjs.github.com/sockjs-protocol/sockjs-protocol-0.3.3.html#section-73. The strange thing is that when I was testing using Firefox, sometimes it connects websocket fine, but sometimes not. I will try to capture the traffic as you've suggested, and compare the captures when it works and when it does not. I am using 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 ? Indeed, I am using SSL exclusively, because encrypted traffic actually increases the chance of websocket (and other supported protocols in SockJS) working, since those annoying proxies and antivirus may just let the traffic pass through without modifying them. In fact, given the same network environment I was in for testing, if I don't do https, things barely work, websocket and xhr-streaming just hang. I also read this article: http://www.infoq.com/articles/Web-Sockets-Proxy-Servers, which seems to suggest that, due to the fact many proxies do not support websocket, such connection failure is not uncommon. The article also suggests to use HTTPS to increase the success rate, which is exactly what I've done. Still, even though I haven't count precisely, the overall success rate is definitely below 90% for me. What else can I try here? Thanks! Best, Chris On Fri, Mar 1, 2013 at 1:39 AM, Willy Tarreau <w...@1wt.eu> wrote: > 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 > >
