Allow matching routes without capturing arguments

[davidfowl]

For proxy scenarios where routes need to be parameterized for matching but not for capture support a syntax to avoid allocating anything after matching.

e.g.

// ProxyRequest is a made up method that proxies the HttpRequest to another server

endpoints.Map("/api/v1/{*path}", context =>
{
     return context.ProxyRequest("http://localhost/old/" + context.Request.Path);
});

endpoints.Map("/api/v2/{*path}", context =>
{
     return context.ProxyRequest("http://localhost/new/" + context.Request.Path);
});

cc @Tratcher

[Dotnet-GitSync-Bot]

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

[Tratcher]

What do you expect the path for the proxied request to be in this example? /old/api/v1/...?

[davidfowl]

Preserving the entire path.

[javiercn]

@davidfowl can you give more details?

I'm not sure I understand the E2E

[davidfowl]

I host a proxy on localhost:80, then I map all requests to /api/v1/{path} to http://localhost/old/api/v1/{*path}, same for v2. Made it a bit clearer in the description.

I want to avoid the cost of storing captures when I only care about matching because the other server is the one that's going to be doing the matching and parsing.

[ghost]

Thanks for contacting us.
We're moving this issue to the Next sprint planning milestone for future evaluation / consideration. We will evaluate the request when we are planning the work for the next milestone. To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.

[davidfowl]

Do you have an idea of the cost of this @javiercn ?

[javiercn]

It should be doable, a few days up to a week at most.

• We would need new syntax for it, but it can already be reflected on the model I think.

[ghost]

We've moved this issue to the Backlog milestone. This means that it is not going to be worked on for the coming release. We will reassess the backlog following the current release and consider this item at that time. To learn more about our issue management process and to have better expectation regarding different types of issues you can read our Triage Process.

[ghost]

Thanks for contacting us.

We're moving this issue to the .NET 7 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.

[ghost]

We've moved this issue to the Backlog milestone. This means that it is not going to be worked on for the coming release. We will reassess the backlog following the current release and consider this item at that time. To learn more about our issue management process and to have better expectation regarding different types of issues you can read our Triage Process.