Summary:This is a follow up of 9b87e6c860.
- Allows custom headers on connection request
- Adds a default `origin` header to Android, just like iOS
**Introduces no breaking changes.**
I was working on something similar and would like to propose a few changes that make the API more consistent across both iOS and Android platforms and brings this closer to [spec](https://tools.ietf.org/html/rfc6455).
I believe aprock first implementation of adding custom `headers` was correct. It makes sense naming this argument `headers` since we have no other general options available, and the current `options` field is being used to pass in a header anyway.
My use case for custom headers was attaching a token to the `Authorization` header on the connection request. I have been testing this by passing a JWT inside the `Authorization` header and verifying it on the server before establishing a connection.
Closes https://github.com/facebook/react-native/pull/6016
Differential Revision: D3040735
fb-gh-sync-id: 183744d2415b895f9d9fd8ecf6023a546e18a546
shipit-source-id: 183744d2415b895f9d9fd8ecf6023a546e18a546
Summary:This is a follow up of 9b87e6c860.
- Allows custom headers on connection request
- Adds a default `origin` header to Android, just like iOS
**Introduces no breaking changes.**
I was working on something similar and would like to propose a few changes that make the API more consistent across both iOS and Android platforms and brings this closer to [spec](https://tools.ietf.org/html/rfc6455).
I believe aprock first implementation of adding custom `headers` was correct. It makes sense naming this argument `headers` since we have no other general options available, and the current `options` field is being used to pass in a header anyway.
My use case for custom headers was attaching a token to the `Authorization` header on the connection request. I have been testing this by passing a JWT inside the `Authorization` header and verifying it on the server before establishing a connection.
Closes https://github.com/facebook/react-native/pull/6016
Differential Revision: D3040735
Pulled By: nicklockwood
fb-gh-sync-id: f81bd14ccbdba36309b9d4b4850fb66fe4deae11
shipit-source-id: f81bd14ccbdba36309b9d4b4850fb66fe4deae11
Summary:Motivation: Developer expects `onclose` to be called before/during close of the websocket. The `websocketFailed` event triggers a close but does not invoke onclose.
Testplan: Connect to a websocket server from android, terminate the server, observe that onerror is called, the websocket is closed, but onclose is not called.
Note: the observed bug is in android only because in iOS the underlying websocket implementation fires the `websocketClosed` rather than `websocketFailed` event when the server terminates. Nevertheless, the justification for this change stands that regardless of the cause of the close, if `this.close` is called it is expected this.onclose should be called as well.
Closes https://github.com/facebook/react-native/pull/6307
Differential Revision: D3017458
fb-gh-sync-id: c9e2dfefa597b4e99ee85eaa991667c347f86d83
shipit-source-id: c9e2dfefa597b4e99ee85eaa991667c347f86d83
Summary: Check that the WS state is set to OPEN before trying to close it when the ```websocketFailed``` event fires. Otherwise the app throws an error at the Android level.
Fixes#3346
Closes https://github.com/facebook/react-native/pull/3347
Reviewed By: @svcscm
Differential Revision: D2535807
Pulled By: @mkonicek
fb-gh-sync-id: bb70c551ea2e582cfaa80139a265dbbca6d990d2
Summary: The JavaScript code for Android is same as the iOS counterpart, I just added few new lines and used arrow functions instead of binding `this`.
Closes https://github.com/facebook/react-native/pull/2839
Reviewed By: @svcscm, @vjeux
Differential Revision: D2498703
Pulled By: @mkonicek
fb-gh-sync-id: 3fe958dd5af0efba00df07515f8e33b5d87eb05b
Alexey Dodonov
Christopher Dro
Zack
Satyajit Sahoo
Andy Prock
Johan Lindskogen
Yuri Zarubin