Ports for API calls are not being forwarded correctly when using VSCode in Codespaces

[ccastrotrejo]

ADD ISSUE DESCRIPTION HERE

Version: 1.86.0-insider
Commit: 8172579
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/121.0.0.0 Safari/537.36 Edg/121.0.0.0
Embedder: codespaces

General issue idea:

For Logic Apps (Standard) vscode extension we run a local func host start process which starts the local server in port 7071. (the port doesn't automatically starts, there are a series of steps you must do to make the server run), The port is automatically forwarded, which is good. However if we make API calls to the localhost:7071 the api calls don't go through it. It seems that isn't active. I tried making the calls manually by changing the localhost:7071 to the forwarded address and then it works. Is there a way the API calls can automatically go through the forwarded address?

All this works fine in a local environment. We are trying to make it work in a codespace environment.

Screenshots

Steps to Reproduce:

1. You can take a look on how to do this in here: https://learn.microsoft.com/en-us/azure/logic-apps/create-single-tenant-workflows-visual-studio-code#run-test-and-debug-locally
2. This is a really specific logic apps scenario, I am more than happy to help with this issue.

[alexr00]

Are you using Codespaces in desktop VS Code for from a browser?

[alexr00]

It looks like you're doing this from a browser, which means that forwarded ports are accessible at an internet URL that's provided by the Codespace. There's no way to make them available at localhost instead, as we have nothing running on your local machine where we can start a server and listen on localhost for you.

This should work fine if you use desktop VS Code though. In that case, since we have a desktop application, we do start a server and listen on localhost for forwarded ports.

[ccastrotrejo]

@alexr00 Yes, I am using Codespaces from a browser.
Yes, this whole thing works fine in VS Code desktop application. The local server in my local machine works fine and the API calls to it also (since everything is local), however If I want to use Codespaces the server also works fine but the API calls that are made to the https//localhost:7071 aren't picked up automatically since it needs to go through the forwarded address instead of the localhost and the port.
My question here is: Is there any way the codespaces or vscode can automatically pick the API calls that are made through the localhost and the port and forward them to the forwareded address?

[alexr00]

@ccastrotrejo what/who is making the API calls? If they're coming from a VS Code extension then this is possible.

[ccastrotrejo]

Hi @alexr00 , yes those API calls are coming from the VS Code extension.

[alexr00]

@ccastrotrejo in that case, the extension should be able to solve this by using the asExternalUri API before making those calls. asExternalUri will translate the localhost URI into the URI that VS Code knows the port is forwarded to locally. When not connected to a remote asExternalUri will have no effect.

vscode/src/vscode-dts/vscode.d.ts

Lines 10132 to 10185 in 03bd0bb

	/**
	* Resolves a uri to a form that is accessible externally.
	*
	* #### `http:` or `https:` scheme
	*
	* Resolves an *external* uri, such as a `http:` or `https:` link, from where the extension is running to a
	* uri to the same resource on the client machine.
	*
	* This is a no-op if the extension is running on the client machine.
	*
	* If the extension is running remotely, this function automatically establishes a port forwarding tunnel
	* from the local machine to `target` on the remote and returns a local uri to the tunnel. The lifetime of
	* the port forwarding tunnel is managed by the editor and the tunnel can be closed by the user.
	*
	* *Note* that uris passed through `openExternal` are automatically resolved and you should not call `asExternalUri` on them.
	*
	* #### `vscode.env.uriScheme`
	*
	* Creates a uri that - if opened in a browser (e.g. via `openExternal`) - will result in a registered {@link UriHandler}
	* to trigger.
	*
	* Extensions should not make any assumptions about the resulting uri and should not alter it in any way.
	* Rather, extensions can e.g. use this uri in an authentication flow, by adding the uri as callback query
	* argument to the server to authenticate to.
	*
	* *Note* that if the server decides to add additional query parameters to the uri (e.g. a token or secret), it
	* will appear in the uri that is passed to the {@link UriHandler}.
	*
	* **Example** of an authentication flow:
	* ```typescript
	* vscode.window.registerUriHandler({
	* handleUri(uri: vscode.Uri): vscode.ProviderResult<void> {
	* if (uri.path === '/did-authenticate') {
	* console.log(uri.toString());
	* }
	* }
	* });
	*
	* const callableUri = await vscode.env.asExternalUri(vscode.Uri.parse(vscode.env.uriScheme + '://my.extension/did-authenticate'));
	* await vscode.env.openExternal(callableUri);
	* ```
	*
	* *Note* that extensions should not cache the result of `asExternalUri` as the resolved uri may become invalid due to
	* a system or user action — for example, in remote cases, a user may close a port forwarding tunnel that was opened by
	* `asExternalUri`.
	*
	* #### Any other scheme
	*
	* Any other scheme will be handled as if the provided URI is a workspace URI. In that case, the method will return
	* a URI which, when handled, will make the editor open the workspace.
	*
	* @returns A uri that can be used on the client machine.
	*/
	export function asExternalUri(target: Uri): Thenable<Uri>;

[ccastrotrejo]

@alexr00 awesome, thank you so much. I will give it a try!

[ccastrotrejo]

@alexr00 it actually worked in resolving the external Uri. But I am getting 302. Do you know why this might be happening? If I paste the url in the browser I am able to get the data

[alexr00]

@ccastrotrejo I'm not sure, maybe it's auth related. You can check if it's auth related by changing the port to "public" from the Ports view before your API call. If it's works when the port is public but not when it's private then it's probably a problem with the context you're making the API call from not having the proper auth from GitHub. Are you making this API call from a webview in a VS Code extension? If so, then this is common problem. The only solution I can offer is to make the API call from the extension, not the webview, which I know is not ideal.