On Thu, Jun 24, 2021 at 5:30 AM Martin Krellmann
<[email protected]> wrote:

> Hello Mike,
>
>
>
> thanks for your reply.
>
>
>
>    - The endpoint is definitely available. You are seeing a 404 because
>    it is a WebSocket endpoint, not an HTTP endpoint, and Tomcat is refusing to
>    continue routing the request without the correct headers.
>
>
>
> Okay you are right, I’ve checked the situation from the internal network
> with direct access to the docker container running guacamole. It uses the
> websocket tunnel then…
>
> However, I must say that the error message returned at a direct access to
> the uri (/guacamole/websocket-tunnel) is misleading. A 404 means “the
> resource does not exist or was not found” by definition. Because WebSocket
> connections are simply an upgrade of the http connect, it should instead
> return 400 “bad request” as the http endpoint (/guacamole/tunnel) indeed
> does!
>
> I have actually searched in the wrong place because of this 404 return
> code for a couple of days now.
>
>
>

This you'd need to take up with the Tomcat developers, as the 404 error
isn't generated by Guacamole, it's generated by Tomcat. I assume that they
have a good reason for doing things this way, but, as I've no familiarity
with Tomcat internals/development, I don't know.


> I’ll check what might be the problem with the ReverseProxy. As I have
> actually configured it like the doc states, I’m a bit curious what the
> problem could be. But let’s see…
>
>
>

Are you actually seeing that WebSockets is not used by the connections? Are
you seeing warnings that it is falling back to HTTP because WebSockets is
not available??

-Nick

Reply via email to