runtime: [Uri] Inconsistent treatment of %20 in file Uri with/without unicode chars

Based on .NET Framework bug report: https://developercommunity.visualstudio.com/content/problem/89895/uri-constructor-not-encode-character-after-net-45.html Reproduced on .NET Core 2.1 (and .NET Framework 4.7.2 which is out of scope here - just for completeness)

static void Main()
{
    Console.WriteLine(new Uri(@"C:\##\%20").AbsoluteUri); // Prints: file:///C:/%23%23/%2520
    Console.WriteLine(new Uri(@"C:\Ã\%20").AbsoluteUri);  // Prints: file:///C:/%C3%83/%20

    // Works fine for other sequences, e.g. %23
    Console.WriteLine(new Uri(@"C:\Ã\%23").AbsoluteUri);  // Prints: file:///C:/%C3%83/%2523
    // It is consistent for http URIs:
    Console.WriteLine(new Uri(@"http://my.com/  /%20").AbsoluteUri); // Prints: http://my.com/%20%20/%20
    Console.WriteLine(new Uri(@"http://my.com/Ã/%20").AbsoluteUri);  // Prints: http://my.com/%C3%83/%20
}

Note that treating of %20 is inconsistent in the first 2 URIs - first one gets % encoded (%2520), second one gets % kept as is (%20). The difference seems to be just usage of multi-byte Unicode char in 2nd case. As the additional 3 cases above show, http URIs are fine and so are file URIs with other sequences like %23.

About this issue

Original URL
State: open
Created 6 years ago
Reactions: 3
Comments: 15 (14 by maintainers)

Most upvoted comments

To wrap up, @fredeil confirmed offline that he cannot reproduce the problem anymore. cc @ManickaP

karelz on Oct 17, 2019

We had troubles to reproduce the same symptoms. @fredeil can you please ping me directly on gitter, Twitter, or via email? (see my GH profile for contacts) Thanks!

karelz on Oct 8, 2019

Hi @karelz! I did try to solve this a few times.

The findings was a bit odd, often the results would print out just fine when debugging the code (walking through literally every step) and when running it without a debugger it would yield the wrong results.

Whenever I found a solution that produced the right results on every run for this particular problem something else would break.

I would still really like to solve this but I got stuck. So if you have any tips to offer me it would be greatly appreciated!

Btw loved your talk on NDC Oslo 👍

fredeil on Oct 2, 2019

Those tests are verifying the behavior of explicit (starting with “file://”) and implicit (starting with a drive name, ie "C:"). They’re encoding the same path explicitly and implicitly, then testing each property to see if it matches between the two.

Interestingly, the test actually expects some properties to be different! I think it’s worth manually checking the failed test cases to see what changed. It’s possible that those tests are encoding some undesirable behavior that we actually do want to change. On the other hand, it may be that this change has unexpected side effects, and in that case we may not be able to make a fix for compat reasons.

rmkerr on Sep 21, 2018

UriEscapingTests.cs looks like an appropriate location. I would add the tests to the file URI escaping section, and would try to stay consistent with the existing tests there. https://github.com/dotnet/corefx/blob/99211937b4f1735b7912f0a064b91ba60c8e9ca9/src/System.Private.Uri/tests/FunctionalTests/UriEscapingTest.cs#L443-L445

rmkerr on Sep 17, 2018

Awesome 😄

I’ll assign you the issue. Feel free to reach out if you have any questions.

rmkerr on Sep 17, 2018

Would like to take this ☝️

fredeil on Sep 16, 2018