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 > *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: global > log 127.0.0.1 local1 info > log 127.0.0.1 local1 notice > #log loghost local0 info > maxconn 4096 > chroot /usr/share/haproxy > uid 99 > gid 99 > daemon > #debug > #quiet > > defaults > log global > mode http > option httplog > option dontlognull > retries 3 > option redispatch > maxconn 500 > timeout connect 6s > timeout client 600s > timeout server 600s > timeout tunnel 1200s > > frontend public > mode http > bind 0.0.0.0:80 > bind 0.0.0.0:443 ssl crt /etc/haproxy/ssl_wc/mysite.pem > ciphers HIGH:!aNULL:!MD5 no-tlsv10 > timeout client 300s > option http-server-close > option forwardfor except 127.0.0.1 > reqadd X-Forwarded-Proto:\ https if { ssl_fc } > reqadd X-Forwarded-Proto:\ http if !{ ssl_fc } > # define ACLs below > acl is_https ssl_fc > redirect scheme https if !is_https > # and other ACLs and rules (omitted here) > > backend sockjs_1 > #timeout server 60s > server sock1 127.0.0.1:8000 > > backend sockjs_2 > #timeout server 60s > server sock2 127.0.0.1:8060 > > backend nginx > #timeout server 20s > server nginx 127.0.0.1:8484 > > backend stats > stats enable > stats uri /haproxy/stats > stats realm Haproxy\ Statistics > > backend www > #timeout server 300s > #option forwardfor header X-Client-IP > #no option httpclose > #option http-server-close > server content 127.0.0.1:8080 Again, backends sockjs_1 and sockjs_2 are what is being affected here. Could anyone comment on what may cause this undesirable websocket failures here? Thanks a lot! Best, Chris On Fri, Feb 22, 2013 at 8:40 AM, Chris Yang <[email protected]> wrote: > > Hello, > > I upgraded to dev17 from dev15. I am running Tornado servers behind > HAProxy with SockJS support. Comparing to before the upgrade, I've noticed > two problematic behaviors: > > 1. When a client is using IE with xhr-streaming protocol to connect to > servers, such connections are closed (seeing 'Connection get reset by peer' > error on the Python side) more often than before. Sometimes disconnection > happened soon after connection (half a minute). I guess it might be related > to timeout, but since I haven't changed any configuration on HAProxy, I > wonder if this behavior is related to the upgrade of HAProxy itself. > > 2. From time to time, Chrome failed to finish the websocket handshake with > the server, and instead used xhr-streaming. This didn't happen before the > upgrade, but I've noticed at least 5+ such cases during the testing with > dev17. > > I can confirm that both client-side library (sockjs-client) and > server-side library (sockjs-tornado) have stayed the same since their last > respective upgrade (months before dev17 came out). So the only variable > which might have produced the observations above could be HAProxy. > > I attach below my HAProxy config (excluding most of the acls), and I'd > much appreciate that if someone could take a quick look and let me know if > some setting(s) may not play well with dev17 which might have caused the > behavior above, or some new setting(s) should be added. Notice that > backends sockjs_1 and sockjs_2 are the ones experiencing the problems. > > global > log 127.0.0.1 local1 info > log 127.0.0.1 local1 notice > #log loghost local0 info > maxconn 4096 > chroot /usr/share/haproxy > uid 99 > gid 99 > daemon > #debug > #quiet > > defaults > log global > mode http > option httplog > option dontlognull > retries 3 > option redispatch > maxconn 500 > timeout connect 6s > > frontend public > mode http > bind 0.0.0.0:80 > bind 0.0.0.0:443 ssl crt /etc/haproxy/ssl_wc/mysite.pem > ciphers HIGH:!aNULL:!MD5 no-tlsv10 > timeout client 300s > option http-server-close > option forwardfor except 127.0.0.1 > reqadd X-Forwarded-Proto:\ https if { ssl_fc } > reqadd X-Forwarded-Proto:\ http if !{ ssl_fc } > #option http-pretend-keepalive > # define ACLs and use them below > acl is_https ssl_fc > redirect scheme https if !is_https > # other acls omitted here > > backend sockjs_1 > timeout server 60s > server sock_1 127.0.0.1:8000 > > backend sockjs_2 > timeout server 60s > server sock_2 127.0.0.1:8060 > > backend nginx > timeout server 20s > server nginx 127.0.0.1:8484 > > backend stats > stats enable > stats uri /haproxy/stats > stats realm Haproxy\ Statistics > > backend www > timeout server 300s > #option forwardfor header X-Client-IP > #no option httpclose > #option http-server-close > server content 127.0.0.1:8080 > > Thanks very much! > > > > Best, > Chris >
