Chrome正在加载长轮询，并且加载指示器不会停止。
为什么Chrome不使用WebSockets，如何在使用长轮询时阻止加载指示器旋转？
我正在使用最新的socket.io和nodejs v2.5
-
我第一次连接时，它使用Websocket，但立即断开连接并重新连接xhr-polling。
答案 0 :(得分：3)
我遇到了类似的问题，我发现有一个socketio cookie覆盖了“xhr-polling”的传输方法。我不知道cookie是如何到达那里的，但删除它就可以了。
这是对查找cookie的行的引用。 https://github.com/LearnBoost/Socket.IO/blob/master/socket.io.js#L1023
答案 1 :(得分：2)
看来socket.io.js有控制它的选项。
我相信如果'tryTransportsOnConnectTimeout'设置为'true'，那么socket.io将遍历连接上的所有传输机制并使用第一个成功的传输机制。
如果'rememberTransport'设置为'true'，则成功的传输将存储在cookie中。
在我的应用程序中，我实现了断开连接时重新连接的逻辑。我发现我必须将上述两个选项都设置为'false'，以防止重新回到不需要的传输。出现此问题的原因是断开连接后，服务器可能在任何时候都可用（例如客户端尝试长轮询而不是websockets）。如果发生这种情况，则设置cookie并且后续连接将继续使用不期望的传输。
答案 2 :(得分：0)
我正在使用Chrome 8和WebSockets似乎工作正常。
如果您正在使用socket.io，它应该在长轮询（或永远iframe）之前回退到FlashSockets甚至xhr-multipart。在服务器和客户端上初始化socket.io时检查传输选项。