[Bug]: The audio web socket incorrectly uses SSL on reverse proxies run in network_mode: host

[MiningMarsh]

Describe the Bug

I'm running steam-headless in privileged mode, with betwork_mode host. If I expose the ports over http, audio works correctly when I connect externally, as long as I open the 32041 port used as the audio websocket.

If I switch to HTTPS, however, the webaudio patch (or maybe just webaudio itself) chooses to connect to that socket over SSL. That will not work against websockify. Additionally, since I am on network_mode: host, I cannot reverse proxy this port to add SSL to it, as that would require two different listeners on the same port (in my case Apache and websockify).

I believe that this could be fixed by either adding an env var to configure the audio web socket protocol between ws or wss, or by adding an env var that lets you specify the audio port the frontend will connect to, which would allow me to reverse proxy the websocket with SSL correctly.

As far as I can tell the included audio.patch for noVNC isn't applied at all, as I can manually apply it within the container against /opt/frontend/noVNC. I'm not actually sure where in the codebase is causing the connection directly against that 32041 socket, which is why I haven't attempted to supply a patch myself. The described behavior was observed against an unpatched noVNC.

Steps to Reproduce

Run steam-headless with network_mode: host and then reverse proxy it with SSL. In the Firefox debugging window, you will see failures to connect against hostname:32041. Remove the reverse proxy and it will function correctly.

Expected Behavior

Audio functions correctly in a reverse proxies environment.

Screenshots

No response

Relevant Settings

No response

Version

Build: [2025-01-04 02:59:19] [master] [920bfa7] [debian]

Platform

Gentoo with standard docker environment, with an Apache reverse proxy in an SSL configuration.

Relevant log output

No response