MapHost endpoint routing

[Tratcher]

Describe the bug

In endpoint routing today routes are defined around paths. There's an additional constraint you can add for a host, but only after already defining a path. Instead what I want to do is map all requests to a specific host as the primary pivot. This can be done today but it is inelegant (I have to define a catch-all route), and in-efficient (route values would still be extracted).

To Reproduce

Here's what I have to write today:

endpoints.Map("/{**path}", handler).RequireHost(host);

Proposal:

endpoints.MapHost(host, handler);

[javiercn]

@Tratcher can you add a bit more info here?

What is the scenario you have in mind.

• Would you map the host directly with an implicit catch-all route?
• Would you offer the ability to pass in the route pattern explicitly as an option?
• Do you mean for this to be literally equivalent to endpoints.Map("/{**path}", handler).RequireHost(host)?

[rynowak]

We had some discussion offline before this issue was created. I think the key points are:

• This can be done today but it is inelegant (I have to define a catch-all route)
• in-efficient (route values would still be extracted)

The proxy wants this, because it's a fairly common thing for proxies to route traffic solely on host. The behavior would be the same as a catch-all route.

• It's easy for us to make a first-class API for this, I just don't want it to cause confusion.
• I have a cool idea about how to make this non-allocating.

---

We should add support for unnamed route parameters (or optionally _ as a prefix for non-capturing`). Unnamed route parameters would not be used during URL parsing, and would not support parameter transformers, nor constraints (since they never have a value).

I haven't totally made up my mind yet whether I think a route with unnamed parameters should support link generation, or whether unnamed route parameters can be optional.

The ability to control capturing and matching separately is really nice.

There's a big difference when a route has parameters vs when it don't be. https://github.com/dotnet/aspnetcore/blob/master/src/Http/Routing/src/Matching/DfaMatcher.cs#L115 - routes with parameters allocate a string (for each value), a KeyValuePair<string, object>[] for the backing store, and a RouteValueDictionary.

A route without parameters doesn't allocate anything during matching. An RVD is allocated only if someone tries to access it - and they likely won't for the proxy case.

---

The option of supporting _ as a prefix requires more ceremony overall to use, but it's much more flexible. These routes can be used with link generation if you want (since the parameter has a name), so it's more obvious that they should follow all of the normal rules except for capturing.

[Tratcher]

For reference, this is how the proxy builds routes today:
https://github.com/microsoft/reverse-proxy/blob/1d8a868d7aa12cbc8345c93b40193234f7d400da/src/ReverseProxy/Service/DynamicEndpoints/RuntimeRouteBuilder.cs#L48-L68

[mkArtakMSFT]

@Tratcher do you want to tackle this?

[Tratcher]

We're not blocked by this at the moment, but we'll see how the perf benchmarks work out.

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

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.