Allow specifying subdirectory to open when port forwarding detected

[heaths]

We would like a way to configure a path (subdirectory) of a site to open from a devcontainer. In VSCode, for example, clicking the browse button - or from the automatic prompt to open a browser when a port is forwarded - we could open a site like http://127.0.0.1:4000/azure-sdk instead of only http://127.0.0.1:4000. For GitHub Codespaces, this would be forwarded port to a remote continer.

To portAttributes or otherPortAttributes, this would add:

Property	Type	Description
path	string	Optional path relative to the site root to open in a browser e.g., "/blog" on forwarded port 4000 would open http://127.0.0.1:4000/blog on localhost.

To the schema for both portAttributes or otherPortAttributes¹, this would look like:

"portsAttributes": {
    "type": "object",
    "patternProperties": {
            "(^\\d+(-\\d+)?$)|(.+)": {
                    "type": "object",
                    "description": "A port, range of ports (ex. \"40000-55000\"), or regular expression (ex. \".+\\\\/server.js\").  For a port number or range, the attributes will apply to that port number or range of port numbers. Attributes which use a regular expression will apply to ports whose associated process command line matches the expression.",
                    "properties": {
+                      "path": {
+                          "type": "string",
+                          "description": "Optional path relative to the site root to open in a browser e.g., '/blog' on forwarded port 4000 would open `http://127.0.0.1:4000/blog` on localhost."
+                      },
                       "onAutoForward": {

See microsoft/vscode-remote-release#9518 for additional context.

¹ Since portAttributes and otherPortAttributes appear to be the same schema, wouldn't a $ref to a single object definition be sufficient and easier to maintain?

[samruddhikhandale]

Hi 👋

This sounds cool, thanks for putting this up 💡

Quick clarifying question, as portsAttributes apply to all the ports specified in forwardPorts property. Is this something you are expecting? or do you prefer to only add path property to certain/specific forwarded ports?

[heaths]

Quick clarifying question, as portsAttributes apply to all the ports specified in forwardPorts property. Is this something you are expecting? or do you prefer to only add path property to certain/specific forwarded ports?

How do they apply to all ports when you're required to specify a port specification (single integer or string range) e.g.,

"portAttributes": {
  "4000": {
    "path": "/azure-sdk"
  }
}

I certainly wouldn't want this to apply to all ports specified in the "forwardPorts": [] array.

[samruddhikhandale]

Thanks for clarifying, your request makes sense to me. Along with the cli, spec and schema changes, I believe this will also require a change in VS Code, looping in @chrmarti for his insights.

[chrmarti]

/cc @alexr00 for the VS Code side.

[SteveBombardier]

• ["portAttributes": { "4000": { "path": "/azure-sdk" }

  434

[SteveBombardier]

Je sais pas comment faire

[alexr00]

This seems reasonable to me!

[heaths]

This seems reasonable to me!

@alexr00 what would be the next steps? Is this something you'd like help with, if I can? I looked in the VSCode repo originally and didn't find any code that seemed to process portAttributes - just the schemas or something. I may have time for working on this.

[chrmarti]

@samruddhikhandale @alexr00 Is this something Codespaces can adopt too? I remember the implementation there to be more involved than when the VS Code UI runs in a local window.

[samruddhikhandale]

@samruddhikhandale @alexr00 Is this something Codespaces can adopt too? I remember the implementation there to be more involved than when the VS Code UI runs in a local window.

Looping in @osortega who can help answer this question.

[alexr00]

The next steps:

1. Find someone to do the work to support this. That would usually be me. I can see if we can fit it into an upcoming plan, or someone else can work on it and I'd accept a PR.
2. Do the work to support this from the remote.portsAttributes VS Code setting. Code pointer: https://github.com/microsoft/vscode/blob/573a9ff995c4a63624eede783d6daa99da01c012/src/vs/workbench/services/remote/common/tunnelModel.ts#L192-L193
3. Once this is supported by VS Code I think it makes sense to add support to devcontainers schema.

@alexr00 Is this something Codespaces can adopt too? I remember the implementation there to be more involved than when the VS Code UI runs in a local window.

I would expect that there should be any additional work from Codespaces to make this happen. This would just be a property in the portsAttributes setting, and I think we should be able handle everything else from within VS Code. I would need to check how things currently work in Codespaces in the browser, but so long as they already support navigating to a subdirectory it should be fine.

@heaths when would you expect the subdirectory to be applied?

• When the url opened from the Ports view? (very doable)
• When the url is opened from an onAutoForward action in the portsAttributes? (very doable)
• When the url is opened from clicking on a link in the terminal (even if that link doesn't include the subdirectory)? (harder to do)
• Any other places?

[heaths]

• When the url opened from the Ports view? (very doable)
• When the url is opened from an onAutoForward action in the portsAttributes? (very doable)

Just those two. The link in the terminal window - at least as output from jekyll serve - is already correct e.g., http://localhost:4000/azure-sdk.

I'd be happy to submit PRs to respective repos, but it seems all those - including the one you linked to that I found previously - are just parsing/processing the config. Is the code that actually uses it and does all the forwarding / browser work elsewhere? Is that internal/private and would need to be done by you or someone on your team?

[alexr00]

I don't think we actually need to make any changes to how the port is forwarded. If a process is listening at localhost:4000 on the remote machine and you want to access http://localhost:4000/azure-sdk, then we should be able to just forward localhost:4000 locally to localhost:4000 then adding a path like /azure-sdk should "just work".

The thing that we need to do is make sure to append the path (eg. /azure-sdk) to the local URI in the correct places:

• When the url is opened from the Ports view: https://github.com/microsoft/vscode/blob/68f565d32a8248b1c5677426621c34a875c1a8da/src/vs/workbench/contrib/remote/browser/tunnelView.ts#L1340-L1346
• When the url is opened from an onAutoForwardAction: (this actually just calls the above) https://github.com/microsoft/vscode/blob/68f565d32a8248b1c5677426621c34a875c1a8da/src/vs/workbench/contrib/remote/browser/remoteExplorer.ts#L332-L336

I would suggest adding a preferredPath property here:

https://github.com/microsoft/vscode/blob/68f565d32a8248b1c5677426621c34a875c1a8da/src/vs/workbench/services/remote/common/tunnelModel.ts#L49-L66

Updating the parsing somewhere here:

https://github.com/microsoft/vscode/blob/68f565d32a8248b1c5677426621c34a875c1a8da/src/vs/workbench/services/remote/common/tunnelModel.ts#L217-L251

The merging of attributes here: https://github.com/microsoft/vscode/blob/68f565d32a8248b1c5677426621c34a875c1a8da/src/vs/workbench/services/remote/common/tunnelModel.ts#L964-L965

Then ensuring the preferredPath gets applied correctly here:

https://github.com/microsoft/vscode/blob/68f565d32a8248b1c5677426621c34a875c1a8da/src/vs/workbench/services/remote/common/tunnelModel.ts#L720-L734

here:

https://github.com/microsoft/vscode/blob/68f565d32a8248b1c5677426621c34a875c1a8da/src/vs/workbench/services/remote/common/tunnelModel.ts#L482-L497

and here:

https://github.com/microsoft/vscode/blob/68f565d32a8248b1c5677426621c34a875c1a8da/src/vs/workbench/services/remote/common/tunnelModel.ts#L449-L468