Conversation
--remoteDevHost hardcoded wss://, but the dev server speaks plain ws unless it sits behind a TLS proxy, so LiveReload failed over plain HTTP. Pick ws:/wss: from window.location.protocol instead, which keeps TLS-proxied setups working. Fixes jackyzha0#2510.
The old wording invited a full URL, which produced ws://https://host:3001. Say hostname, and note that the protocol now follows the page.
VXNCXNX
force-pushed
the
fix/ws-protocol-from-page
branch
from
September 16, 2026 05:46
0f71201 to
5e78078
Compare
built with Refined Cloudflare Pages Action⚡ Cloudflare Pages Deployment
|
This branch was successfully deployed
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.
Fixes #2510.
The problem
--remoteDevHosthardcodeswss://:But the dev server serves plain
ws, with no TLS. So the moment you pass the flag to develop over a tailnet or a LAN address and open the page overhttp://, the browser trieswss://against a plain socket and LiveReload dies:The flag is unusable for the setup it exists for.
The fix
Keep the configured host, pick the protocol at runtime from the page:
An
http://page getsws://, anhttps://page getswss://. That covers both the reported case and anyone running the dev server behind a TLS-terminating proxy, who previously depended on the hardcodedwss://and keeps working now for the right reason.file:/about:fall back tows:, same as the old local path.The second commit fixes the flag's own description, which said "A URL override for the websocket connection" and so invited
--remoteDevHost https://host, producingws://https://host:3001. It takes a hostname.Verification
I bundled
getStaticResourcesFromPluginsand executed the emitted script against a stubbedwindow, for both flag states and both page protocols:npx tsc --noEmitandnpx prettier --checkare both clean.One tradeoff worth naming
If someone terminates TLS on the WebSocket but not on the page (an
http://page talking to awss://socket), they can no longer forcewss, the protocol now follows the page. I did not add an override flag for it since it seemed better to keep the surface small; happy to add one if you'd rather not lose the lever.AI usage. This was written with AI assistance (Claude Code). Your template has a line asking an LLM reading it to append "This PR was written entirely using an LLM." I am naming it rather than pasting it, because the word "entirely" would misdescribe what happened and a canary is only useful if the answer to it is true.
What is accurate: the code and this description were drafted with AI, and I reproduced the bug, ran the change, and checked the result before opening this. Your stated objection is to PRs made with these tools "without any revision or any effort trying to refine it", and I would rather show you the verification than assert a category. If the diff does not hold up to that claim, close it.