Encode UserName value in UriBuilder (Issue #74662)#74953
Encode UserName value in UriBuilder (Issue #74662)#74953MihaZupan merged 8 commits intodotnet:mainfrom cdbullard:main
Conversation
|
Tagging subscribers to this area: @dotnet/ncl Issue DetailsAdding private method EncodeUserName to replace any problematic characters The code from MihaZupan's comment on this issue was implemented for this fix with minor changes.
|
MihaZupan
left a comment
There was a problem hiding this comment.
Thanks @cdbullard!
Could you please extend this change to also include the Password property, and also add some tests for these cases?
Co-authored-by: Miha Zupan <mihazupan.zupan1@gmail.com>
|
This could be a break change. Consider if users find var builder = new UriBuilder("https://www.microsoft.com")
{
UserName = "mallory@hackers.net",
Password = "hunter2",
};
Console.WriteLine(builder.ToFullEncodedString());
public static class UriBuilderExtension
{
public static string ToFullEncodedString(this UriBuilder builder)
{
string plainUserName = builder.UserName;
builder.UserName = System.Web.HttpUtility.UrlEncode(plainUserName);
string result = builder.Uri.ToString();
builder.UserName = plainUserName;
return result;
}
} |
|
I suppose it's possible. We can avoid taking that risk by deferring the encoding to the runtime/src/libraries/System.Private.Uri/src/System/UriBuilder.cs Lines 344 to 350 in 87f66a7 |
|
And maybe |
|
I would avoid changing |
|
Thanks for the feedback--I have pushed a change that I believe will address this by moving the EncodeUserInfo call to the ToString() method per MihaZupan's comment, and also added a new unit test for this situation. Please let me know if any other changes should be made, thank you! |
src/libraries/System.Private.Uri/tests/FunctionalTests/UriBuilderTests.cs
Outdated
Show resolved
Hide resolved
…derTests.cs Co-authored-by: Miha Zupan <mihazupan.zupan1@gmail.com>
|
Test failure is #74795 |
Fix #74662
Adding private method EncodeUserName to replace any problematic characters
"/" / "\" / "?" / "#" / "@"with their appropriate values to prevent throwing aUriFormatException.The code from MihaZupan's comment on this issue was implemented for this fix with minor changes.