fix: Connection.resolveExternalWSUri should return ws or wss schema

[scbrubaker02]

Modifies the behavior Connection.resolveExternalWSUri so that it returns as URI with a "ws" or "wss" scheme instead of a "http" or "https" scheme as it does currently.

This avoids the need for callers of this function to correct the scheme in the results. Most importantly in the WebviewComm the scheme was always replaced with a "ws" scheme, resulting in errors like

Mixed Content: The page at 'https://example.com' was loaded over HTTPS, but attempted to connect to the insecure WebSocket endpoint 'ws://example.com'. This request has been blocked; this endpoint must be available over WSS.

in secure contexts.

No other clients of the Connection class seem to rely on the behavior of returning an "http" or "https" schema.

[scbrubaker02]

@microsoft-github-policy-service agree company="Udacity"

[microsoft-github-policy-service]

@scbrubaker02 the command you issued was incorrect. Please try again.

Examples are:

@microsoft-github-policy-service agree

and

@microsoft-github-policy-service agree company="your company"

[andreamah]

Can you create an issue associated with this?

[scbrubaker02]

@andreamah , this addresses #645

[andreamah]

This seems right, as it's making the behavior in

vscode-livepreview/src/server/serverUtils/HTMLInjector.ts

Lines 79 to 80 in 8573123

	const wsURL = `${httpUri.scheme === 'https' ? 'wss' : 'ws'}://${wsUri.authority
	}${wsUri.path}`;

more universal across the repo. Currently, once I manually navigate to the websocket URL (as discussed in the FAQ, it seems to update just fine for me.

In your case, do you do this and it still doesn't update properly?

[scbrubaker02]

Actually, this change does not fix #645, which is the problem addressed in the FAQ, as pointed out by @andreamah .

The only consequence that been able to observe while running the branch in codespaces is that a "Content-Security-Policy: Upgrading insecure request" warning disappears. The websocket where behavior is affected is not the one responsible for refresh but the one that handles the page history.

Nevertheless, I do think that this is an improvement to code. It can be seen as an alternative fix for #175.