aspnetcore: Slashes incorrectly encoded when building URL with catchall param?

From @Daniel15 on Saturday, September 10, 2016 10:27:27 PM

Consider this controller:

public class TestController : Controller
{
  [Route("foo/{*path}")]
  public IActionResult Index(string path)
  {
    var url = Url.Action("Index", new { path = "hello/world" });
    return Content("Path = [" + path + "], built URL = " + url);
  }
}

When you hit http://example.com/foo/some/url, ASP.NET MVC Core will display:

Path = [some/url], built URL = /foo/hello%2Fworld

Whereas ASP.NET MVC 5 will display:

Path = [some/url], built URL = /foo/hello/world

Notice that the URL returned by Url.Action encodes / as %2F, whereas the previous MVC version did not do this.

Is this an expected change? If so, how do I render the URL such that the slash is not encoded?

Copied from original issue: aspnet/Routing#363

About this issue

Original URL
State: closed
Created 6 years ago
Reactions: 2
Comments: 51 (27 by maintainers)

Most upvoted comments

Closing this as done!

mkArtakMSFT on Oct 22, 2018

From @Daniel15 on Saturday, April 29, 2017 11:01:09 PM

This is still broken 😦

I worked around it by using Url.Action then calling .Replace("%2F", "/") on the resulting string. Ugly but it works: https://github.com/Daniel15/Website/commit/26b1d2ad8c307afda07d70769265ea71ce775d2c

aspnet-hello on Jan 2, 2018

We’ve decided to add a new feature to support this scenario in 2.2.0 We will add a new syntax {**catchAll} that will parse catchAll segments as PathString instances. Users will be able to generate urls without encoded slashshes in catch all values by passing a PathString as the value (or if its on the ambient values)

mkArtakMSFT on Mar 30, 2018

@javiercn It’s obviously a bug on encoding when using catchall routing. I think there is nobody will relying on this feature and the workaround right now is not affecting if you patched this bug. If user’s backend server is using IIS, no matter what they apply this patch no not, they won’t be affected either. If user use Apache Web server, there is same things. No one will be affected. So I don’t think it’s a breaking change.

doggy8088 on Feb 5, 2018

Hope this bug can be fixed in ASP.NET Core 2.1. There are tons of potential ASP.NET MVC devs are going to migrate their website to ASP.NET Core. The inconsistence of the routing feature are really annoying. 😢

doggy8088 on Feb 23, 2018

@valeriob for example, if you want to use Url.Link with <a> tag, you could create a helper class, like this:

public static class MyUrlHelper
{
    public static string LinkFixedSlash(this IUrlHelper urlHelper, string routeName, object values)
    {
        return urlHelper.Link(routeName, values).Replace("%2f", "/");
    }
}

Example of usage in a view:

<a href="@Url.LinkFixedSlash(RouteNames.PostsRoute, new { path = post.UrlPath })">
    @Model.PostHeader
</a>

And don’t forget to add to the view the namespace where your helper class is scoped.

P.S. This makes the syntax more familiar:

public static class MyUrlHelper
{
    public static string Link(this IUrlHelper urlHelper, string routeName, object values, bool decodeSlashes)
    {
        string link = urlHelper.Link(routeName, values);
            
        if (decodeSlashes)
            link = link.Replace("%2f", "/");

        return link;
    }
}

Usage:

<a href="@Url.Link(RouteNames.PostsRoute, new { path = post.UrlPath }, true)">
    @Model.PostHeader
</a>

develax on Mar 7, 2018

@doggy8088 The odd thing is that we have the catchall option for routes. But this option is not supported by route-helpers in Core.

develax on Feb 21, 2018

Can anyone clarify if it is going to be fixed soon? I couldn’t grasp it from the discussion. I’m doing migration from MVC 5 to Core and have to use workaround everywhere the catchall is used.

develax on Feb 21, 2018