If an LSP server sends a URI like "my-foo:///C:/foo/bar" to VS Code, it will come back as "my-foo:/c%3A/foo/bar". In particular:
the // before the authority have been removed (because the authority is empty)
the first character of the path has been lowercased (because despite not being a file URI, VS Code's URI class has decided it is a drive letter and normalises to lowercase drive letters)
To ensure LSP clients and servers are all on the same page, it would be beneficial to document the kinds of changes client/servers are allowed to make to custom scheme URIs. In particular, the change of casing for non-file URIs seemed unexpected to me and it would be very easy for a server to that's not being tested with VS Code specifically to not handle this correctly.
If an LSP server sends a URI like "my-foo:///C:/foo/bar" to VS Code, it will come back as "my-foo:/c%3A/foo/bar". In particular:
//before the authority have been removed (because the authority is empty)To ensure LSP clients and servers are all on the same page, it would be beneficial to document the kinds of changes client/servers are allowed to make to custom scheme URIs. In particular, the change of casing for non-file URIs seemed unexpected to me and it would be very easy for a server to that's not being tested with VS Code specifically to not handle this correctly.
(I did raise this with VS Code in the hope it was a bug, but it's apparently by design: https://github.com/microsoft/vscode/issues/202071)