JavaScript strings with NULL character are not handled properly when passed to Native Modules
nickspacek opened this issue · comments
Description
We are using STOMP over WebSockets to communicate with our API. On iOS everything is working as expected, on Android messages are not arriving intact. As we dug it, we discovered the trailing NULL (\0) character in the strings was not arriving.
As we sought to narrow down the cause we were able to confirm (using a sample Native Module based on the ToastAndroid module) that on Android a JavaScript string containing any NULL characters is not processed as expected; when the parameter arrives in the Java code, it has been truncated to the first occurrence of the NULL character, and the NULL character is also dropped.
For example "Hello World\0" arrives as "Hello World". "Hello\0World\0" arrives as "Hello".
Because the STOMP protocol is expecting a NULL-terminated string, it discards the WebSocket message as invalid.
Reproduction
Managed to reproduce in a fairly straightforward manner here: https://rnplay.org/apps/tkNMOQ
On Android, the element shows "Hello", presumably because the ws.send('Hello\0World\0') has been truncated. On iOS, the element shows "HelloWorld"
Solution
I'd love to understand where things are being translated from JavaScript to Java in React Native, and did start digging a bit. Ideally, NULL characters are escaped/allowed to be passed through to the Java side of things untouched, as they are on iOS.
Additional Information
- React Native version: 0.42
- Platform: Android
- Operating System: Linux
Could it be because the c++ bridge uses NULL terminated strings?
cc @mhorowitz
we have the same proble, did you resolve it? @nickspacek
if you are use spring websocket, you can try this
public void handleMessage(WebSocketSession session, WebSocketMessage<?> message) throws Exception {
if (message instanceof TextMessage) {
TextMessage msg = (TextMessage) message;
String payload = msg.getPayload();
message = new TextMessage(payload + "\u0000");
}
super.handleMessage(session, message);
}
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Maybe the issue has been fixed in a recent release, or perhaps it is not affecting a lot of people. If you think this issue should definitely remain open, please let us know why. Thank you for your contributions.