textDocument/hover sends escaped colon after drive letter #58985
Comments
|
@jrieken assigning to you as our URI expert. I call on the URI I get in the vscode API |
|
Please assign back if there is something you think needs to be done in the LSP client. |
|
This is the design, as we do minimal to none scheme specific encoding. To encode minimal you can use @rjmholt How do you use the URI? What library to you use to parse an uri-object from that string? I am asking because escaping too much shouldn't be a problem. |
|
We're using the URI to resolve a workspace file on the filesystem. We use .NET's
If you have a Windows machine, the easiest way to verify this is with PowerShell: > [uri]::new('file:///e%3A/%23Folder/')
AbsolutePath : /e%3A/%23Folder
AbsoluteUri : file:///e%3A/%23Folder
LocalPath : /e:/#Folder
Authority :
HostNameType : Basic
IsDefaultPort : True
IsFile : True
IsLoopback : True
PathAndQuery : /e%3A/%23Folder
Segments : {/, e%3A/, %23Folder}
IsUnc : False
Host :
Port : -1
Query :
Fragment :
Scheme : file
OriginalString : file:///e%3A/%23Folder
DnsSafeHost :
IdnHost :
IsAbsoluteUri : True
UserEscaped : False
UserInfo :RFC 8089 Appendix E.2 is the best resource I've found that describes the unescaped colon expected for DOS-style paths. The mismatch between the URI that VSCode sends and the one that |
The things is there are so many RFCs that you always find one for whatever point you wanna make. We mostly stick to https://tools.ietf.org/html/rfc3986 which doesn't define any scheme-specific things and actually try to avoid that... So, from playing with dotnetfiddle it seems that the URI is all happy and can be parsed, no exception or so. The
|
Honestly, the RFCs are pretty complex as you say.
But the real problem is that .NET (Core and Framework) expect something different to what we receive — and even if we got traction in corefx (where we also open the odd issue), it's still this way forever in .NET 451 (and .NET 461, which we're changing to later). In the original issue description I listed a few other references that expect an unescaped colon.
While true, only the ones with the unescaped colon yield a path from either At the end of the day, we've handled the issue. In fact, we've handled it so that if this behaviour changes, we're still doing the right thing. I was surprised that nobody had opened this issue before, but perhaps that means everyone else has adapted. It looks like Omnisharp does something similar to us — see OmniSharp/omnisharp-roslyn#1125. Looks like the Haskell LSP hit this too. The other language servers I looked at either use the VSCode TypeScript APIs to decode the URI (the OCaml and MS C++ LSPs) or seem to handle it properly in the standard library (Java (notice the special handling for Windows), Python (although MS's python language server is written in C# so might have a similar issue) and Rust LSPs). |
|
@rjmholt there is a way in the LSP client were you can intercept all translations from vscode.URI => string and string => vscode.URI. (see https://github.com/Microsoft/vscode-languageserver-node/blob/master/client/src/client.ts#L463) So you could plug in our own converters to overcome this problem for now. But please be aware that this might make the server dependent on running in VS Code. |
Acknowledged - lets see what we can do during October. It's not the first time this comes up and the also weird .NET behaviour is reason to change this |
|
I have pushed a fix for this and we will see how well it works, depending on that there is chance that we revert this. |
|
Thanks @jrieken |
|
It happened: #60163 (comment) |
|
If you want to revert, there's no harm to us (or, I don't think, omnisharp. I looked at the F# extension, but I couldn't find any handling). Stability on this is probably more important -- I don't want to have broken all the other extensions out there. Ideally this is documented wherever VSCode's message URI format is so that anyone else writing a .NET back end doesn't hit the Thanks for giving it a shot @jrieken |
|
Not yet reverted. I have pushed a different fix for #60163 (comment) and I am still optimistic :-) |
|
@rjmholt this will be reverted because it causes too much trouble (#61504). We will clarify the documentation. What you can do is call |
I work on the PowerShell extension/language service for VSCode, and we have a bug report where PowerShellEditorServices crashes because we render the wrong path; there's a
#character in the path andSystem.Uriin C# drops everything after the#as a fragment. Easy fix -- we shouldn't escape the path prematurely, but I wondered why it was done in the first place (since it's more effort).I was working on the fix PR and @SeeminglyScience noticed I haven't escaped the
:after drive letters in the URIs in the tests. I escape it and everything crashes.But looking at the logs I notice that VSCode itself is sending the colon escaped:
I notice that in the examples I can find of
file://scheme URIs, the drive letter's colon is never escaped:The only issue I can find on this with VSCode is about needing to use the right method on the node
Uriclass to avoid this issue.But we're seeing this problem in the encoding of a message VSCode itself is sending.
Is this intended behaviour? Is there a standard way to handle this?
The text was updated successfully, but these errors were encountered: