Currently, the server assumes it knows what transfer modes a transport supports and decides whether to base64 encode messages for binary transport. This assumption may not be correct. One example is an XmlHttpRequest polyfill which does not support XmlHttpRequest Level 2 features. Trying to use a binary transport with this polyfill fails - the client (after teaching it to use non-level-2 xhr) will base64 encode binary messages but the server assumes it is fine to send binary data over longpolling transport does not encode the message which causes failures on the client.
One way of solving this problem would be to send transfer mode along with protocol in the negotiation message
This actually isn't resolved. I also discussed this with @anurse recently. There are other scenarios where this could be useful information to have in the handshake.
Currently, the server assumes it knows what transfer modes a transport supports and decides whether to base64 encode messages for binary transport. This assumption may not be correct. One example is an XmlHttpRequest polyfill which does not support XmlHttpRequest Level 2 features. Trying to use a binary transport with this polyfill fails - the client (after teaching it to use non-level-2 xhr) will base64 encode binary messages but the server assumes it is fine to send binary data over longpolling transport does not encode the message which causes failures on the client. One way of solving this problem would be to send transfer mode along with protocol in the negotiation message