Summary:
On Flipper Desktop, rawCall uses sendExpectResponse from the client connection.
RSocket only rejects the promise if there's an error in the transport layer and thus is unable to send data over the wire.
WebSocket sends without errors as errors will always be reported via a different callback api.
Having said that, WebSocket client connections were rejecting the promise for a valid client response that contained an error instead of success, which in this specific case is expected.
The solution is to always resolve the promise with the response and let the Client interpret the response accordingly.
Changelog: Fixes an issue whereas client errors were erroneously disconnecting a client from the Desktop side
Reviewed By: aigoncharov
Differential Revision: D32983969
fbshipit-source-id: 4215d9234235a9e2035b1d743c317ebdf2f656a2
Summary:
Standardize WS implementation for JS environments.
Why do we need a separate server implementation for browsers?
Browser targets cannot authenticate via the default certificate exchange flow. For browser targets we verify the origin instead.
Moreover, for already forgotten reasons the initial implementation of the WS server for browsers used a different kind of message structure and added extra `connect`/`disconnect` messages. After examination, it seems the `connect`/`disconnect` flow is redundant.
Major changes:
1. Updated class hierarchy for WS server implementations.
2. Updated browser WS server to support the modern and the legacy protocols.
3. Now a websocket connection with the device is closed on error. The idea is it is highly unlikely to handle any subsequent messages properly once we observe an error. It is better to bail and reconnect. What do you think?
Reviewed By: mweststrate
Differential Revision: D31532172
fbshipit-source-id: f86aa63a40efe4d5263353cc124fac8c63b80e45
