false connection upgrading from polling to websocket when client is behind the buffering proxy/antivirus

[ghost]

Client is behind the buffering antivirus (Kaspersky 6.0).

When websockets are disabled in options, polling works fine.

When enabled - client (Latency example) switches to "websockets" and then updating stops.
Latency show stable 20-25 sec.intervals - close to timeout values in my understanding.

I think that it's necessary to change connection upgrading conditions to prevent engine switching to unavailable transport. (e.g. checking packet roundtrip success before switching).

[rauchg]

@kazan1000 checking packet roundtrip success is exactly what we do. We expect a ping/pong roundtrip with the custom text data probe

[rauchg]

Would you mind running a packet analyzer and showing me the network traffic?

[ghost]

Unfortunately i could not install packet analyser on my workstation.

Strange behavior of engine.io transport "probe" protocol with antivirus.
Incoming "pong" packets was delivered to client correctly, but "message" packets was not.
They are was eaten by antivirus buffer completely.

But some testing and patching was solved my problem.

1. Changed "probe" protocol protects from false connection upgrading in case of tested kind of buffering.
2. Base64 encoding of packets allows to use websockets with web shields of tested antivirus (Kaspersky).
   Without this encoding no false upgrading happens, websocket transport correctly goes down and polling works.

Changed files was sent for your consideration to [email protected]

Nice day.

[rauchg]

Can you give me an example of the message payload that was being eaten? Was it utf8?

[ghost]

No, it was pure 7bit ascii .

All of "message" packets was eaten (e.g. in my modified latency example without base64 encoding of packets query (HELO) message was delivered to server but the answer (EHLO) message was unable to reach client).

In original example it was on "upgrade" phase, so client was paused "polling" transport and tried to switch to broken "websocket" .

For people who are interested in the details, options of Kaspersky antivirus that broke websocket transport was:
"anti-fishing" and "anti-banner" in web-antivirus preferences.

[rauchg]

So I'm just trying to understand what exactly about the encoding in base64 is helping mitigate the issue?

[rauchg]

@kazan1000 please re-open if you have more details