After a successful TLS handshake, leverage the (experimental) Forge prepareHeartbeatRequest mechanisms to cause pings to be sent from client to server. This is aimed at ensuring the websocket-based channel stays viable during periods when the webapp/user may be idle.

If a webapp is left idle over night, the websockets typically get closed. When the webapp attempt to send traffic the next day, we should just spin up a fresh channel to the edge router... but something currently goes awry, as shown here:

Uncaught (in promise) TypeError: Can't send data because WebSocket is not opened.
    at exports.throwIf (ziti.js:152980)
    at ZitiWebSocket.send (ziti.js:153687)
    at Object.tlsDataReady (ziti.js:132461)
    at Object.tls.flush (ziti.js:74391)
    at Object.c.prepare (ziti.js:75013)
    at ZitiTLSConnection.prepare (ziti.js:132527)
    at ZitiChannel._sendMarshaled (ziti.js:130366)
    at ziti.js:130292
    at PromiseController._callFn (ziti.js:119945)
    at PromiseController.call (ziti.js:119846)
    at Messages._createNewMessage (ziti.js:132134)
    at Messages.create (ziti.js:132106)
    at ZitiChannel.sendMessage (ziti.js:130291)
    at ziti.js:129984

If edge router closes websocket, we need to gracefully shut down the channel on JS-side, and then attempt to re-open a fresh channel.

Fill this gap in current enrollment operations.

ziti-sdk-js uses the browser/web API Blob.text() in its rest-client impl used to do REST calls to the Controller. e.g. to call the /.well-known/est/cacerts endpoint during enrollment operations.

The text() method in the Blob interface returns a Promise that resolves with a string containing the contents of the blob, interpreted as UTF-8.

The problem is... Safari doesn't support Blob.text() 👎
(as shown here: https://developer.mozilla.org/en-US/docs/Web/API/Blob/text)

I need to refactor this area with an eye towards using web APIs supported by all of the big three browsers.

Ensure that the CN in the server-side cert of the edge router we are doing the TLS handshake with is indeed the same edge router we are attempting to connect with based on hostname extracted from the network session we created on the controller.

Use the verify mechanism provided on the Forge tls.connection.

Today, we expect/assume that all services want/require encryption. Add support for connecting to non-encrypted services.

It is (currently) possible to configure the controller with a edge.wsapi section, but with that section lacking the identity,servercert or key. In this scenario, the JS-SDK will loop endlessly trying to get TLS connections over the websocket.

We need to detect this situation, and surface the problem for the user of the webapp.

When connections get closed, they are not being removed from the connections list maintained by the channel.

Seeing different behavior depending on which browser is used (with ziti-sdk-js 0.6.3+)

Although the tmdb web-app test-mule runs very solidly under Chrome (87.0.4280.67), it intermittently fails under Firefox (83.0) on a Macbook.

The problem manifests on the edge router as:

ERROR [foundation/channel2.(*channelImpl).rxer [ch{edge}->u{classic}->i{ORXE}] rx error (short read)

The edge router is attempting to read the 4-byte magic number for the edge-protocol message, but gets zero bytes instead. The error is unrecoverable on edge router side, so it closes the channel.

The client side then gets confused, and the attempt to decrypt incoming traffic/responses, manifests an error:

Could not decrypt record or bad MAC

There seems to be some kind of async/timing differences, or websocket data-chunking differences, concerning how things operate on these two browsers while running the exact same code.

If we are attempting to enroll with a Controller that does not have an edge.wsapi configured, we will receive incomplete data from the /protocols call. This eventually leads to corrupt coordinates of the WS listener on the controller, and an inability to make Ziti connections.

We need to fail the enrollment in this case, and make it obvious to the user what is going on.

We currently send entire userAgent as the envInfo.os value during /authenticate requests to Controller.

Instead, let's send only the last "portion" of the UA.

e.g., instead of:

5.0 (Macintosh; Intel Mac OS X 10_15_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/87.0.4280.88 Safari/537.36
let's try to send only:

Chrome/87.0.4280.88