kit: --https mode causes issues in dev by trying to connect to wss://localhost:24678
Describe the bug
In --https
mode, the site is served at https://localhost:3000
and so the Vite websocket connection that is attempted fails, because it tries to make it at wss://localhost:24678
when it exists at ws://localhost:24678
. This results in the page being periodically reloaded.
Logs
Firefox can’t establish a connection to the server at wss://localhost:24678/.
[vite] server connection lost. polling for restart... client:340:13
[vite] connecting...
To Reproduce
npx svelte-kit dev --https
Open console and/or network logs and wait. Turn on timestamps on the console to help see what’s happening. The page refresh rate seems to vary widely, and I haven’t figured out what causes that to happen.
Expected behavior I don’t think we can force an HTTPS page to load a non-secured websocket, so we’ll have to figure out how to serve a secure websocket over that port. This will also still probably cause issues because it will be a self-signed cert. I don’t know how to resolve this.
Severity High. HTTPS mode is not very usable if the browser refreshes periodically.
Additional context I told you HTTPS mode was a mistake and you didn’t believe me.
About this issue
- Original URL
- State: closed
- Created 3 years ago
- Reactions: 12
- Comments: 24 (16 by maintainers)
Commits related to this issue
- #844 fix for SSL HMR websockets (#1517) Co-authored-by: Ben McCann <322311+benmccann@users.noreply.github.com> — committed to sveltejs/kit by JBusillo 3 years ago
https://github.com/sveltejs/kit/issues/581#issuecomment-805398830 hinted at a way that seems to work for me:
This problem has stopped me dead in my tracks. I’m working on a new project w/ oauth and I need an https callback to receive my login token. I hope this gets addressed soon but I’m open to workarounds in the meantime. Thank you.
Vite lets this websocket server be configured with https://vitejs.dev/config/#server-hmr so we should be able to disable it and have a command line argument to control it.
This is just part of a larger issue with not being able to reach the hmr (?) server on that port. Rich had suggested trying to disable it when in https mode, but really it would be better if the port were configurable, if you could disable the feature separately from enabling https mode, and if its existence was documented for people who are e.g. running Kit inside Docker. Also ideally the whole page wouldn’t reload when the server can’t be reached.