sock.send support for ArrayBuffer/Blob

[aajtodd]

Looks like SockJS send method currently only supports sending of strings, and encodes values as such.
https://github.com/sockjs/sockjs-client/blob/master/dist/sockjs.js#L741

SockJS claims to follow the Websockets API as closely as possible (https://w3c.github.io/websockets/#websocket), which includes support for other data types. This seems like a large deviation and drawback to SockJS.

Support should be added for ArrayBuffer and Blob data types. Encoding binary data in a string is error prone.

Thanks for all the hard work!

[brycekahle]

The trick to supporting those other data types is making them work across all transports and browser support. I'm not saying it can't be done, but it will certainly not be trivial.

[aajtodd]

Sure, I think it's worth a discussion. I'm curious what are the main limitations/difficult parts of supporting say an ArrayBuffer of binary data?

[brycekahle]

For one, ArrayBuffer isn't supported until IE10.

[aajtodd]

Sure but to be fair Web Sockets aren't supported until IE10 either.

This is not a reason to exclude support, if someone wants to use ArrayBuffer and doesn't care about IE9 for example (or they use a polyfill) SockJS should not preclude it.

Forgive my rudimentary JavaScript but something along the lines of

_ArrayBufferDefined = typeof window.ArrayBuffer !== 'undefined';

sock.send(data){ // ArrayBuffer | Blob | string
    if (_ArrayBufferDefined && data instanceof ArrayBuffer){ 
    }
    // etc for Blob & string

}

Anyway point being is that part doesn't seem insurmountable for the API, my guess is random binary data would present more of a problem for other transport mechanisms, anyone care to fill in which ones may (or definitely would) have a problem?

In that case the protocol could fall back on an encoding for binary data (e.g. base64). This obviously gets into details about server implementation and the protocol itself having to know what is coming down the pipe and be able to detect such messages and decode them back before delivering them to the final endpoint.

I'm just throwing out ideas for people to think about. I agree it isn't trivial, I would suspect most people would be OK with sensible fallbacks such as this when the transport doesn't support such data and be ok incurring the extra encode/decode cost.

[brycekahle]

Emulating Websockets is the point of this library, so browsers that don't support Websockets is a major part of it. I'm not opposed to adding binary support. Given that it touches both client and server, will require protocol changes, and needs quite a bit of research into how to handle it for each transport, I don't think it tops my priority list. I'm also skeptical about the real demand for binary support. The realities of this library is that there are features of Websockets that are difficult/impossible to emulate.

That being said, if you have ideas about how to implement it, I would love to discuss your strategy and/or comment on your pull requests.

[aajtodd]

Looks like this has already been discussed for the protocol (as I'm sure you are aware having commented on one of them)

sockjs/sockjs-protocol#74
sockjs/sockjs-protocol#30

Looks like my suggestion was not far off from what was suggested in issue 74. My naive mind says if the underlying transport does not support binary (likely most of them), base64 encode it. I'm going to throw out some ideas and let you poke holes. Truth be told I am not an expert in web technology/protocols so be gentle.

Outgoing data from client-server

If the data being sent is binary and the transport does not support binary then add a header to let the server know the data has been encoded. The server can read the header and do the reverse decode if appropriate.

When websockets are supported, I believe providing an ArrayBuffer/Blob to send will automatically set a binary opcode for the frame, correct me if I'm wrong.

Incoming data from server-client

This is the trickier one I suspect. For example I would guess making an xhr request you would have to set the response type before making the request? If that's the case for one or more of the protocols then the server would have to send a message indicating 'binary data' available and the client would have to make a second request with the appropriate responseType.

I see what you mean when you say it's non-trivial but I would like to hear thoughts or suggestions especially with respect to incoming data since that seems like the more difficult piece.

[austinzmchen]

any updates please? now that IE browser is out of the picture.

[clnnn]

As @austinzmchen mentioned Microsoft will drop support for IE in August 2021 (Source)

Is there an official roadmap for the future which include binary support?