Make sure SockJS works behind bad antiviruses

[majek]

@mrjoes says

http://groups.google.com/group/sockjs/browse_thread/thread/d4cf931f28e65858

that bad things can happen to websockets behind avast. We should understand the problem and make sure that SockJS behaves correctly.

Reference:  https://github.com/LearnBoost/socket.io/wiki/Socket.IO-and-firewall-software

[mrjoes]

Quick update:

Bug is even more interesting: on server-side, connection is considered open (it sent header handshake, etc), but client does not receive anything - headers are not sent over. Then, after server closes connection due to timeout, browser will receive all headers and any sent data and will trigger appropriate websocket callbacks, like onopen. So, as a result, if
you don't do any additional checks (or don't ignore onopen from non-current transport), everything will break. If you close websocket on client, because of additional close handshake in websocket protocol it is not getting closed immediately and has no effect.

[majek]

I have issues reproducing that. I install "Avast Internet Security" (set the network to "Public/High risk zone", "friends list" only contains 127.x.x.x), but websockets seems to be working fine (Chrome and Firefox, port 80, 8080 and 4000). Any clues? (tested on windows xp sp2 and windows 7)

(port 80 is tested against: http://sockjs.popcnt.org/example-cursors.html - with "websockets" selected)

[majek]

Surprisingly, "iframe-eventsource" and "iframe-htmlfile" seem to be not working. Interesting.

[mrjoes]

It is quite possible they fixed their issue. I'll try to update and test again.

[majek]

Or that I did something wrong. Pusher guys also say that avast doesn't work. Btw I have avast 6.0.1367, trial.

[mrjoes]

OK, here's what I have.

Avast! Free Antivirus, 6.0.1289.
Websockets are blocked:
[connecting] websocket
disconnected SimpleEvent(type=close, code=2000, reason=All transports
failed, wasClean=false, last_event=SimpleEvent(type=close, code=2007,
reason=Transport timeouted, wasClean=false))

iframe-xhr-polling works:
[connecting] iframe-xhr-polling
connected iframe-xhr-polling

When I updated to 6.0.1369, websockets worked. I think it is related to ESN
guys and http://battlelog.battlefield.com which requires websockets to
function. Avast forums were full of complaints from Battlefield 3 players
and they finally decided to add websocket support. Approximately after 1.5
years after first report.

Also, I checked how sockjs behaves in this case - it properly falls back to
the xhr-streaming. Related question though - will it use different
session_id when switching transport? If no, there's a bug - server might
sent something in its on_open handler. If uses different session_id - it
will be considered new connection and everything will work as expected.

[majek]

I can confirm this, websockets don't work with old avast (on port 80 and 8080, they do work on 4000) (btw, Download link for avast 6.0.1289)

I've raised the issue on client sockjs/sockjs-client#34 for the session_id reuse thing.

iframe-eventsource and iframe-htmlfile are not working, but there is nothing we can do about it. Timeouts should detect it.

Apart form that, SockJS behaves reasonably - it falls back to other transport after timeout.

I'll do similar investigation for AVG. Is there anything else left for this particular bug?

[majek]

With AVG Chrome and Firefox fail miserably. Looks like AVG is mangling the websockets connection.

[mrjoes]

Nothing else left, can be closed. SockJS behaves correctly (apart of session_id issue).

[majek]

I played a bit with AVG. The problem was in my configuration. Most importantly, AVG (similarly to AVAST) seem to block 'chunking/streaming' transports. No xhr-streaming or htmlfile working. But as opposed to AVAST, websockets seem to go through nicely.

It's important to test that SockJS falls back nicely (and quickly) behind AVG. But except from blocking streaming nothing is unusual.