.NET8 routing with UrlEncode(url) in parameter does not work

[TDroogers]

Is there an existing issue for this?

• I have searched the existing issues

Describe the bug

After updating from .NET7 (blazor server) to .NET8 the routing has broken.
On project A (still on .NET7) I forward to project B (.NET8)

var returnUrl = HttpUtility.UrlEncode("https://localhost:5001/authentication/login-callback");
Navigation.NavigateTo($"{url}/login/{returnUrl}");

returnUrl == https%3a%2f%2flocalhost%3a5001%2fauthentication%2flogin-callback

project B

@page "/login/{LoginUrl}"

url is not changed in the process https://localhost:44322/login/https%3a%2f%2flocalhost%3a5001%2fauthentication%2flogin-callback

However on project B I'm now forwarded to the 404 page.
If I change {returnUrl} to a non url like "text" I get on the page and the parameter gets the "text"

Expected Behavior

Should work like in .NET7
Encoded url should be read as a parameter and not forwarded to 404

Steps To Reproduce

See Describe the bug

Exceptions (if any)

No

.NET Version

8.0.100

Anything else?

Same issue in azure after deployment in release mode.

I have also tried adding some more optional paramaters, @page "/login/{LoginUrl}/{Test1?}/{Test2?}/{Test3?}" but I still got forwarded tot the 404

[ghost]

Thank you for filing this issue. In order for us to investigate this issue, please provide a minimal repro project that illustrates the problem without unnecessary code. Please share with us in a public GitHub repo because we cannot open ZIP attachments, and don't include any confidential content.

[TDroogers]

@javiercn I created TDroogers/BugUrlRouting to reproduce this issue.

[TDroogers]

I have added a second project in .NET7 in the same solution to prove the issue is new in .NET 8

[TDroogers]

I did some more investigation and the problem is that the encoded slash %2F is the problem. I have updated the reproduction project.

TDroogers/BugUrlRouting@e9ee2fb

My guess is that something goes wrong in the order of decoding the url and the decision what path to use.

[mtavares628]

I can also confirm that I have run into this same issue after upgrading my .NET 7 Blazor Server project to .NET 8.

[javiercn]

@TDroogers thanks for your patience.

I think I've tracked this down to this change https://github.com/dotnet/aspnetcore/blob/main/src/Components/Components/src/Routing/RouteContext.cs#L14 where we were previously splitting every segment and the URL decoding that and now we are URL decoding the entire path

The previous version of the code is https://github.com/dotnet/aspnetcore/blob/771532a3a31e8df2811a6201a2d3850a4171de15/src/Components/Components/src/Routing/RouteContext.cs

The key thing here is that the behavior needs to be the same between SSR (ASP.NET Routing) and whatever the Blazor router does. They share the same codebase, but it seems that some of the setup is slightly different.

Hopefully the behavior matches between the old implementation and the asp.net core implementation and we can "just" fix a bug. If the behavior is different, we'll likely need to go with the new behavior, as we aren't changing ASP.NET Core routing and both routing systems (interactive and SSR) need to offer the same results.

[javiercn]

Removing the decoding step makes the scenario "work consistently" across all the implementations, but I suspect there's more work to do or else we will break other scenarios.

SSR: Click on link -> Url: https:%2f%2flocalhost:5001%2fauthentication%2flogin-callback
Interactive Server click on link -> Url: https%3a%2f%2flocalhost%3a5001%2fauthentication%2flogin-callback
Interactive Server click on button -> Url: https%3a%2f%2flocalhost%3a5001%2fauthentication%2flogin-callback

The last part/diff then seems to be that in 7.0, the parameter is decoded https://localhost:5001/authentication/login-callback. So likely in addition to not decoding the path on the route context, we need to add an extra step to decode the values after we've captured the parameters.

[TDroogers]

Thanks for your response!

[javiercn]

#53470 This is now fixed in main and we'll probably backport it to 8.0 in a future patch

[mtavares628]

@javiercn Thanks for fixing this. Do you have an idea of when that 8.0 patch will be deployed? This bug is preventing me from upgrading my project to 8.0 because a lot of my navigation encodes a return url in the querystring.

[mkArtakMSFT]

@javiercn Thanks for fixing this. Do you have an idea of when that 8.0 patch will be deployed? This bug is preventing me from upgrading my project to 8.0 because a lot of my navigation encodes a return url in the querystring.

@mtavares628 we're probably looking to including this as part of the 8.0.3 release.
In the meantime, it would help if you could try out our nightly builds to confirm if the fix (in main) has addressed the issue you were facing.

[mtavares628]

@mkArtakMSFT What are the steps for targeting the nightly build in my project? I downloaded and installed the latest nightly build of the SDK for .NET 9, but when I try to change the target on my project, .NET 9 isn't listed as an option. Is there something that I'm missing to get this running?

[mkArtakMSFT]

Thanks for giving this a try, @mtavares628.
The guidance here includes information about the feeds to configure. Make sure you configure .NET 9 feeds. Basically, you create a nuget.config file with the content shown there and place it in the root of your project /solution.
Also make sure you update your project's .csproj file to have <TargetFramework>net9.0</TargetFramework>.

The option doesn't show up in the VS because most probably you are not using the latest VS preview which is required for the latest preview .NET SDKs.

[mtavares628]

Thanks @mkArtakMSFT, I was able to test it out and confirm that fix solves my problem. Is there a general time frame planned for the 8.0.3 release?

[mkArtakMSFT]

Thanks for confirming this, @mtavares628. Most probably yes - 8.0.3. In the worst case - 8.0.4, but hopefully it won't get to that.