fix: derive WebSocket URL from page scheme/host (unblock HTTPS proxy)#19
Open
BernardJen wants to merge 1 commit into
Open
fix: derive WebSocket URL from page scheme/host (unblock HTTPS proxy)#19BernardJen wants to merge 1 commit into
BernardJen wants to merge 1 commit into
Conversation
Closes #18. The default URL was hardcoded as `ws://${location.hostname}:8717`. When the GUI is served via an HTTPS reverse proxy (Traefik, nginx, etc.), browsers refuse the `ws://` connection from an `https://` page as mixed content, and the GUI renders blank. Replace with a small helper that derives the URL from the page's own scheme + host: - http://10.32.8.62:8717 → ws://10.32.8.62:8717 (unchanged) - https://penplotter.example.io → wss://penplotter.example.io The WebSocketServer in gateway/server.ts is already attached to the same HTTP server, so the upgrade happens on the same origin as the page — no path routing needed in the proxy, no separate WS entrypoint. Direct access on the Pi is unchanged (location.port is empty when hitting http://host:8717 because 8717 IS the port; the helper falls back to the explicit :8717 in that case). SSR/Node guard included so tests that import this module without a window don't blow up. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #18.
Problem
`src/transport/GatewayClient.ts:51` hardcoded:
```ts
constructor(private url = `ws://${location.hostname}:8717`) {}
```
When the GUI is served behind an HTTPS reverse proxy (e.g. Traefik publishing the gateway at `https://penplotter.lab271.io\`), the browser refuses to open this `ws://` connection from the `https://` page — mixed content is blocked unconditionally — and the app renders a blank `<div id="root">`.
Direct access on the Pi (`http://10.32.8.62:8717\`) is unaffected because both the page and the WebSocket use `http`/`ws` from the same host.
Fix
Derive the URL from `window.location` at runtime:
The `WebSocketServer` in `gateway/server.ts` is already attached to the same `httpServer` instance (`new WebSocketServer({ server: httpServer })`), so the upgrade happens on the same origin as the page — no path routing required in the proxy, no separate WS entrypoint, nothing else to configure on the deployer's side.
Verified
SSR/Node guard
Added a `typeof window === 'undefined'` check so the module can be imported in test envs / SSR contexts that don't have `window` without crashing on load.
Out of scope