test_xhr_server_encodes question and perhaps bug report about sockjs-protocol HOT 2 CLOSED

Okay, that's more complex.

SockJS uses JSON for all transports. But SockJS is only able to send back and forth strings. So why bother encoding stuff as JSON? Well, the problem is that some transports (AJAX/XHR based) mess up some characters.

If you send \u2000 from chrome using AJAX, it will be seen as something else on the wire. Yes. It's broken.

Similar mess is with receiving stuff. Some characters received by AJAX will be mangled by the browser. Whoops.

SockJS knows about this and tries to compensate that. If the client wants to send a character that might be mangled, it will be encoded in the 'long' form, ie \uXXXX literally. This way the string will still be a valid JSON string but will not be mangled (as we will send 6 characters instead of a single unicode codepoint).

So, in the sockjs-protocol you see a list of characters that SockJS expects to be encoded. There are two lists:

• one list, that says what characters must be encoded by the server
• other list that shows the characters that must be encoded by the client (browser).

The latter list is much longer BTW.

We use JSON-like encoding just for speed - that allows us to "decode" string using native code: JSON.parse is usually built in.

Does it make sense?

from sockjs-protocol.

Thanks majek, I forgot to handle the list of the selected characters, so it makes sense now.

Cheers,
Petr.

from sockjs-protocol.