URI provided by didOpen does not conform to RFC3986

[moosq]

opening a new file with code -r bar.ttcn3 on a remote linux host using the ssh-remote vscode extension supplies following URI as parameter of the didOpen notification:

[Trace - 10:12:35 AM] Sending notification 'textDocument/didOpen'.
Params: {
    "textDocument": {
        "uri": "untitled://ssh-remote%2B192.168.1.10/home/moosq/examples/bar.ttcn3",
        "languageId": "ttcn3",
        "version": 1,
        "text": ""
    }
}

Using %2B instead of the + character does not conform to the specification of the authority part from RFC3986 page 20 where such an encoding is solely reserved for non-ascii characters:

The reg-name syntax allows percent-encoded octets in order to
represent non-ASCII registered names in a uniform way that is
independent of the underlying name resolution technology. Non-ASCII
characters must first be encoded according to UTF-8 [STD63], and then
each octet of the corresponding UTF-8 sequence must be percent-
encoded to be represented as URI characters. URI producing
applications must not use percent-encoding in host unless it is used
to represent a UTF-8 character sequence.

[dbaeumer]

@jrieken any comment on this. I get this URI using toString(). Is this something we should handle correctly since the spec forbids these percentage encodings in the host part?

[jrieken]

@jrieken any comment on this. I get this URI using toString()

You can always use toString(true) to skip encoding. Unsure how LSP handles this because it's just a string - so theoretically you can have them encoded and/or decoded.

Is this something we should handle correctly since the spec forbids these percentage encodings in the host part?

"Should" yes, but "can" maybe. The uri implementation has a couple of well-known flaws and generally speaking its string-form isn't great to interop with other implementations. We largely guarantee that parse(uri.toString()) preserves the identity but that's mostly it.

[dbaeumer]

But using toString(true) skips all encodings right. This would I think even be worth.

[jrieken]

Yes, it skips all encoding except for those that are absolutely necessary - namely # and ? in path and # query

[moosq]

encoding of utf-8 still needs to be supported for the host part