Remotely hosted rerun web-viewer still tries to connect to incorrect (local) websocket

[jleibs]

Describe the bug

I have two computers on my home network:
server: 192.168.86.32
laptop: 192.168.68.100

I want to run the web-viewer on the server:

jleibs@server:~$ rerun --web-viewer data.rrd

But then connect to it from my laptop.

jleibs@laptop:~$ firefox 192.168.86.32:9090

Unfortunately when I do this, the browser just shows:

Waiting for data from ws://127.0.0.1:9877

Clearly this won't work since the websocket connection actually needs to be made to: ws://192.168.86.32:9877

Expected behavior

The web-viewer should connect to the correct websocket and receive the data.

Known work-arounds

The websocket address can be overridden via a url-parameter.

If I instead run:

firefox 192.168.86.32:9090?url=ws://192.168.68.32:9877

Then the client connects to the correct websocket and everything works.

The user needing to craft a complex url like this, however, is sub-optimal.

Proposed solution:

1. The default behavior of the client should be to use the same hostname used to connect to the webserver for the websocket, such as retrieved from window.location.hostname.
2. Additionally, the server should have a way of specifying which address(and port) to advertise as its hostname. This would be provided to any client connecting to the webserver, and will not always match the local hostname or ports. For example if connecting to the server through a NAT with port-mapping, or eventually splitting the web-host and websocket onto different machines.