.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

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.

[TDroogers]

Seems like an reincarnation of issue #28965 witch was fixed in #33364

[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!