Aspnetcore: Routing template: support catch-all not the last part

[iron9light]

I wanna routing template like:

"{controller}/{**path}/{action}/{id?}"

or at least

"{controller}/{**path}/myaction1"

I just found the routing matching is all depends on this internal class:
https://github.com/aspnet/AspNetCore/blob/master/src/Http/Routing/src/Patterns/RoutePatternMatcher.cs

If this feature will not be supported officially. How can I do this?

[rynowak]

You could implement something like this using a regex constraint.

C# "{controller}/{**path:regex(.*/myaction)}"

[mkArtakMSFT]

@rynowak I assume there is nothing else for us to do here, is there?

[iron9light]

I think @rynowak 's solution is a tradeoff.
It only supports case2 and I need to remove subfix of path by myself.

It's really useful if this feature can be implemented.
In my project, we use {controller}/{**path}/{action} for all our API.
The path is kinda resource id and it's hierarchy.
In the previous version, the path has only one level. So routing looks like this:
{controller}/{path}/{action}
Then we wanna support 2 level path:
{controller}/{path1}/{path2?}/{action}
Now we are trying to support multi-level path, that's why we wanna:
{controller}/{**path}/{action}

How about we extends the routing template rule:

1. At most one catch-all segment.
2. All segment after catch-all segment must be required.

This should be implementable.
And I think we just need to modify RoutePatternMatcher class.

Or is it possible to make RoutePatternMatcher user controllerable?
e.g. Add a Type parameter for HttpGetAttribute

[HttpGet("{controller}/{**path}/{action}", typeof(MyRoutePatternMatcher)]

[tuespetre]

I was just wanting this exact functionality myself 👀

[bjorn-ali-goransson]

@rynowak regarding your suggestion; that would include the ending part in the catch-all.

Generally speaking, having a catch-all before a text segment would definitely be possible (and quite simple to implement) using a catch-all segment with "ends-with x, y" constraints.

Would you guys agree?

[bjorn-ali-goransson]

Just made a deep dive into the 2.2 source code related to parsing and matching.

Perhaps the RoutePatternParser (edit: RoutePatternMatcher as well) has seen a bit too much organic growth to easily be able to support non-final catch-all parameters. It's not very clear at all what's going on anymore... From what I can see it allows/parses templates like "lorem/.{ext?}" which isn't successfully matched and won't even be sent from Chrome without the dot being stripped out first.

How does a rewrite PR sound to you guys. Currently it doesn't even seem possible to fix bugs in these classes. With a rewrite, one could even allow/disallow non-terminal catch-all simple segment parameters, perhaps by a flag of some sort.

[msftbot[bot]]

Thank you for contacting us. Due to no activity on this issue we're closing it in an effort to keep our backlog clean. If you believe there is a concern related to the ASP.NET Core framework, which hasn't been addressed yet, please file a new issue.