Relative paths with Microsoft.AspNetCore.Rewrite not working

[iqmeta]

Is there an existing issue for this?

• [X] I have searched the existing issues

Describe the bug

I expect the Rewriter to redirect exactly to the String in the Options, but it adds a leading slash, which makes it impossible to have realtive redirects.

This are the Options of Microsoft.AspNetCore.Rewrite

var options = new RewriteOptions()
    .AddRedirect(@"^app$", "app/")
    .AddRedirect(@"^approval$", "approval/");

This is the Redirect it Results in

This does a redirect to the root of the domain instead to an subfolder. If your running in k8s cluster, or whatever container which is mounted by external rewrite rules as sub directory, this leads to big problems ;-(

Line with Problem in Code:
https://github.com/dotnet/aspnetcore/blob/main/src/Middleware/Rewrite/src/RedirectRule.cs#L87

Also in this context the docs are strange/wrong ^regex should not match on leading '/' https://learn.microsoft.com/en-us/aspnet/core/fundamentals/url-rewriting?view=aspnetcore-7.0

2nd Bad Code (change string before Regex!): => https://github.com/dotnet/aspnetcore/blob/main/src/Middleware/Rewrite/src/RedirectRule.cs#L47

our current custom middleware working work-around which works ;-)

app.Use(async (context, next) =>
{
    if (context.Request.Path.ToString().ToLower().Equals("/app")) { context.Response.Redirect("app/"); return; }
    if (context.Request.Path.ToString().ToLower().Equals("/approval")) { context.Response.Redirect("approval/"); return; }
    await next.Invoke();
});

Expected Behavior

302 or 301 => Redirect.Location = "app/" not "/app/" as long I don't put "/" in the redirect string in the options

Steps To Reproduce

see bug description.

try to do a relative redirect from subfolder trailing slash with the rewriteoptions domain/appname/app => domain/appname/app/

Exceptions (if any)

🚀 keep on rocking with the net core framework. great work!

.NET Version

net core >=6

Anything else?

No response

[adityamandaleeka]

Triage: we need to check if this was done for consistency with IIS's rewriting rules.

We could make this an option on the middleware if needed.

[ghost]

Thanks for contacting us.

We're moving this issue to the .NET 8 Planning milestone for future evaluation / consideration. We would like to keep this around to collect more feedback, which can help us with prioritizing this work. We will re-evaluate this issue, during our next planning meeting(s). If we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues. To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.