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

Most upvoted comments

https://github.com/sveltejs/kit/issues/581#issuecomment-805398830 hinted at a way that seems to work for me:

Adding the following to svelte.config.cjs fixed the issue for me (so it uses ws instead of wss and port 3001)

	kit: {
		vite: {
			server: {
				hmr: {
					protocol: 'ws',
					port: 3001
				}
			}
		}
}

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.