How should paths containing things like .. (or differing cases) be handled?

[DanTup]

If a client sends a URI to the server that contains dotted segments like file:///foo/bar/thing/../file.dart how should/must the server handle it? I believe it's a valid URI and could be treated the same as file:///foo/bar/file.dart, however clients may get confused if the URI we send back to them in things like publishDiagnostics doesn't seem to match the URIs they were sending us.

Can we assume it's fine for the server to normalise paths? Or can they be forbidden in the spec?

And along the same lines, but probably a huge can of worms - what about casing? If they send a URI where the casing doesn't match the case on disk (but they're on an case-insensitive file system), is it valid for us to send messages with differently-cased URIs (eg. if we get the path from another source, like a file system watcher, and it doesn't match)?

[LaurentTreguier]

I have a server where I normalize paths, for now it works but I don't think I've ever had a reason to receive a non-normalized path.
I think that casing is up to the OS. The server should simply trust the casing of the client's uri, and the client should keep the same casing as the OS.

[DanTup]

and the client should keep the same casing as the OS

Easier said than done! :-(

VS Code has a huge thread on this issue (expand the collapsed comments, and see how many issues are related/closed as dupes):

microsoft/vscode#12448

There's so much code/libraries written that make incorrect assumptions about paths (like not normalising them, treating them always as case-sensitive by using them as keys in hash tables, etc.) and it causes a lot of grief. For example, if you open a terminal and cd folderWITHWRONGCASE and then launch VS Code, it'll pass that "wrong casing" on to all the extensions, which they may send on to the language servers.

And there's also the issue of Windows drive letters - some APIs seem to return them uppercase, and some lowercase. In fact, VS Code's own APIs are inconsistent - Uri.fsPath always lowercases the drive letter (!) but all the debugger APIs uppercase it.

That's why I think it would be good for the spec to be very specific, because if it's just left for people to do their own thing, LSP will probably end up with a possibly-unfixable issue like that VS Code one.

[dbaeumer]

I think we should spec that paths should be normalized. With casing things get more complicated. For file system that are case sensitive it is easy: the casing must match. For file system that are case insensitive things get more complicated since a server could send an URI for a file that doesn't exist yet hence can't even as the disk what the real casing is. I would rather spec the following for case insensitive:

• the URI should be consistent. It shouldn't change from one call to the next in terms of its casing unless it denotes a different resource.

That basically means that the first one that brings in a URI into the system determines the case (I have to say that this is currently not honored that way in VS Code, but we were discussing applying the same solution internally).

But this still doesn't solve another case: on files system that support linking two paths can point to the same file :-). But we keep this as another topic :-)

[DanTup]

I think we should spec that paths should be normalized

Sounds good to me - so it's fine for a server to reject paths that contain things like /./ and /../?

the URI should be consistent. It shouldn't change from one call to the next in terms of its casing unless it denotes a different resource.

Does this mean the server must track the casing first sent by the client? Eg. if the client sends the "wrong" casing initially, then the servers gets events from a file system watcher that are the "right" case, must the server convert this? (I think it's important to know this, because if it does, there's work for the server, and if it doesn't, the client needs to be prepared to get different casing from events to what it was using).

[dbaeumer]

Does this mean the server must track the casing first sent by the client?

No, I would only argue that a client shouldn't change the casing from on call to the next. However in a case insensitive file system it still might not be the real casing on disk. A server operating on a case insensitive file system needs to take care of this. The API it is using might return files with different casing as well.

[DanTup]

To be more specific, if a client sends a workspace root of C:\MyFolder\ is it valid for the server to return errors for a file of c:\myfolder\file.foo? The server might used APIs that give it paths in different casing and I think it should be clearer what the responsibility is (if it's not specified, I think it'll just lead to lots of issues down the line, like the long-standing VS Code issue). Ideally both server and client would tolerate mismatched casing for a case-insensitive volume, but that can be tricky, especially if case sensitivity varies per volume/path segment/whatever 😞.