Bug of Uri

[xiaorunOk]

Description

new Uri("http://localhost/db/$med#Anti.%E5%AE%8C%E6%88%90%28%29", UriKind.Absolute).IsWellFormedOriginalString() return false, it should be true

Notes

new Uri("http://localhost/db/$med#Anti.完成()", UriKind.Absolute).IsWellFormedOriginalString() will return true. the result of UnescapeDataString("%E5%AE%8C%E6%88%90%28%29") is 完成()

Tagging subscribers to this area: @dotnet/ncl
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Description

new Uri("http://localhost/db/$med#Anti.%E5%AE%8C%E6%88%90%28%29", UriKind.Absolute).IsWellFormedOriginalString() return false, it should be true

Reproduction Steps

as above

Expected behavior

Fix it

Actual behavior

As description

Regression?

No response

Known Workarounds

No response

Configuration

No response

Other information

No response

Author:	xiaorunOk
Assignees:	-
Labels:	area-System.Net, untriaged
Milestone:	-

[karelz]

Reproduced on .NET 6.0.

The difference is in the character following either of the two 3-byte Unicode character. For some characters (e.g. %20-%2C, %2F), the result is false, for other characters (e.g. %2D-%2E, %30 or no character), it is true:

        string[] uris = new string[]
            {
                "http://localhost/db/$med#Anti.%E5%AE%8C%E6%88%90%28%29", // False
                "http://localhost/db/$med#Anti.完成()", // True
                "http://a/%E6%88%90%28", // False
                "http://a/%E6%88%90%20", // False
                "http://a/%E6%88%90%2F", // False
                "http://a/%E6%88%90%3A",   // True
                "http://a/%E6%88%90",      // True
                "http://a/%E5%AE%8C%20", // False
                "http://a/%E5%AE%8C%21", // False
                "http://a/%E5%AE%8C%22", // False
                "http://a/%E5%AE%8C%23", // False
                "http://a/%E5%AE%8C%24", // False
                "http://a/%E5%AE%8C%25", // False
                "http://a/%E5%AE%8C%26", // False
                "http://a/%E5%AE%8C%27", // False
                "http://a/%E5%AE%8C%28", // False
                "http://a/%E5%AE%8C%29", // False
                "http://a/%E5%AE%8C%2A", // False
                "http://a/%E5%AE%8C%2B", // False
                "http://a/%E5%AE%8C%2C", // False
                "http://a/%E5%AE%8C%2D",   // True
                "http://a/%E5%AE%8C%2E",   // True
                "http://a/%E5%AE%8C%2F", // False
                "http://a/%E5%AE%8C%30",   // True
                "http://a/%E5%AE%8C",      // True
            };

        foreach (string uri in uris)
        {
            Console.WriteLine(uri + " ... " + new Uri(uri, UriKind.Absolute).IsWellFormedOriginalString());
        }

        Console.WriteLine(Uri.EscapeDataString("完")); // %E5%AE%8C
        Console.WriteLine(Uri.EscapeDataString("成")); // %E6%88%90

[MihaZupan]

The internal checks deciding whether a certain component is canonical or not (already well-formed) are wrong. In some cases, valid input will be considered as requiring additional escaping/unescaping.

For some logic, this results in having to take a more expensive code path only to reconstruct exactly the same value (e.g. AbsoluteUri).
For others like IsWellFormedOriginalString, this manifests as a wrong result.

I'm not yet sure what the fix for this would look like, but likely changes to the CheckCanonical helper & the code acting on its result (ParseRemaining).

[MihaZupan]

May be similar to #37634, #34031, #21626 which are milestoned to Future and 7.0.
These could have a similar/same underlying issue - we should at least figure it out in 7.0.

[MihaZupan]

Closing in favour of #72632