WebSocket failover to HTTP Tunnel implementation

[Robert James <sr...@gmail.com>]

I'm embedding Guacamole in a application, and would like to failover
from WS to HTTP, similar to Guacamole itself.  However, the nature of
the Javascript in guacamole-common-js seems to preclude this.

My use case is a failure in the server implementation of WebSockets.
(Catching the browser not supporting WebSockets is easy.)

1. We can't use ChainedTunnel: Testing shows that ChainedTunnel will
*not* failover if the server fails in the initial establishment of the
WS Tunnel.

2. We can't use try... catch: Testing shows that when
Guacamole.WebSocketTunnel gets server side errors (in initial
establishment), a message is outputted to the console, but no
exception is thrown.

So: How can we attempt WS, but, if it fails, even at the server side,
even at the initial connect, failover to HTTP?   Ideally, I'd also
like to display this in the browser, so we can debug.

A related problem: The guacamole-common Java code provides a method to
send an error from the HttpServlet, but doesn't seem to provide any
method to send an error to the browser from the WebSocketEndpoint.
How, in WS, can we tell the browser about a server error?

Re: WebSocket failover to HTTP Tunnel implementation

[Robert James <sr...@gmail.com>]

On 5/12/19, Nick Couchman <vn...@apache.org> wrote:
>>
>> My error.  ChainedTunnel does fallback to HTTP; my testing was done
>> incorrectly.
>> So I'll reduce my question to:
>> 1. Is there a way to report this on the browser?
>>
>
> Kind of depends on what you mean by "report" - it does get "reported" to
> the browser and captured by the ChainedTunnel implementation, which turns
> around and tries the next tunnel.  I think if you wanted to do something
> else with it, like log it in the browser or display an error, you'd need to
> implement your own version of the ChainedTunnel that handles those failures
> as you require.  You could use the existing HTTP and WebSocket tunnels
> defined in the Tunnel.js file, but don't use ChainedTunnel and, instead,
> customize your own implementation that suits your needs.
>
> What is it that you mean by "report" and what are you trying to accomplish?

Yes, I'd like to log to the browser.  However, if this requires
implementing a new ChainedTunnel, I don't think the tradeoff is worth
it.  I'll keep the errors logged on server side only.

Re: WebSocket failover to HTTP Tunnel implementation

[Nick Couchman <vn...@apache.org>]

>
> My error.  ChainedTunnel does fallback to HTTP; my testing was done
> incorrectly.
> So I'll reduce my question to:
> 1. Is there a way to report this on the browser?
>

Kind of depends on what you mean by "report" - it does get "reported" to
the browser and captured by the ChainedTunnel implementation, which turns
around and tries the next tunnel.  I think if you wanted to do something
else with it, like log it in the browser or display an error, you'd need to
implement your own version of the ChainedTunnel that handles those failures
as you require.  You could use the existing HTTP and WebSocket tunnels
defined in the Tunnel.js file, but don't use ChainedTunnel and, instead,
customize your own implementation that suits your needs.

What is it that you mean by "report" and what are you trying to accomplish?


> 2. How can the server inform the browser of errors, especially if
> using a WebSocket?
>

This is a little vague - are you still talking tunnel errors, like failure
to establish a WebSocket tunnel, high latency, loss of connection, etc.?
Several of these error types are already handled within the Guacamole code
- for example, warnings are displayed when the network is unstable - but
these are more detected by the AngularJS side than they are "reported" by
the server.

Without knowing more specifically what errors you're trying to handle, I'd
point out that the REST API currently used by the Guacamole Client does
quite a bit of handling of messages between the client and server, and
gives the server the ability to throw exceptions back to the client with
data that the client can then interpret.  This is used extensively
throughout the Guacamole Client code, for everything from authentication
(which throws a HTTP 403 error with the requirements for logging in) to
permissions management and error handling, to establishing connections and
handle disconnects, etc.

-Nick

Re: WebSocket failover to HTTP Tunnel implementation

[Robert James <sr...@gmail.com>]

On 5/12/19, Robert James <sr...@gmail.com> wrote:
> I'm embedding Guacamole in a application, and would like to failover
> from WS to HTTP, similar to Guacamole itself.  However, the nature of
> the Javascript in guacamole-common-js seems to preclude this.
>
> My use case is a failure in the server implementation of WebSockets.
> (Catching the browser not supporting WebSockets is easy.)
>
> 1. We can't use ChainedTunnel: Testing shows that ChainedTunnel will
> *not* failover if the server fails in the initial establishment of the
> WS Tunnel.
>
> 2. We can't use try... catch: Testing shows that when
> Guacamole.WebSocketTunnel gets server side errors (in initial
> establishment), a message is outputted to the console, but no
> exception is thrown.
>
> So: How can we attempt WS, but, if it fails, even at the server side,
> even at the initial connect, failover to HTTP?   Ideally, I'd also
> like to display this in the browser, so we can debug.
>
> A related problem: The guacamole-common Java code provides a method to
> send an error from the HttpServlet, but doesn't seem to provide any
> method to send an error to the browser from the WebSocketEndpoint.
> How, in WS, can we tell the browser about a server error?
>


My error.  ChainedTunnel does fallback to HTTP; my testing was done incorrectly.
So I'll reduce my question to:
1. Is there a way to report this on the browser?
2. How can the server inform the browser of errors, especially if
using a WebSocket?