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

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)?

Start with the protocol specification's URI guidance and trace the cases named in the issue: publishDiagnostics responses and URIs obtained from file-system watchers. Done means the specification documents an unambiguous rule for dotted segments, normalization, and casing, including whether clients may receive a URI that differs from the one they sent.