Copy core endpoint routing types to HttpAbstractions

[JamesNK]

Note that this is in master for 3.0 Will type forward from routing abstractions.

https://github.com/aspnet/Routing/issues/607

[JamesNK]

Why is there no package for the feature branch? https://dotnet.myget.org/feed/aspnetcore-dev/package/nuget/Microsoft.AspNetCore.Http.Abstractions

[Tratcher]

So why is all of this going into the Http.Abstractions package? I only see one type reference (RequestDelegate) that even relates to Http. I Also see a lot more implementation than I'd expect in the abstractions package. This seems like it would become its own thing like Microsoft.AspNetCore.Routing.Something.

[kichalla]

Why is there no package for the feature branch? https://dotnet.myget.org/feed/aspnetcore-dev/package/nuget/Microsoft.AspNetCore.Http.Abstractions

@JamesNK We would ultimately want to move to VSTS and it currently does not have support for feature branches, so @natemcmaster enabled feature branch support only for Routing and MVC last week on TeamCity as we were making cross-repo changes.

[JamesNK]

@natemcmaster Is it difficult to add feature branch builds to HttpAbstractions?

[natemcmaster]

Done. http://aspnetci/viewType.html?buildTypeId=Lite_HttpAbstractions&branch_Lite=endpoint-routing-types&tab=buildTypeStatusDiv

[JamesNK]

I have moved Invoker from IEndpointFeature to Endpoint from @davidfowl's offline feedback.

Outstanding decisions:

1. Namespaces
   • Should Endpoint+EndpointMetadataCollection live in Microsoft.AspNetCore.Routing?
   • Should IEndpointFeature live in Microsoft.AspNetCore.Routing.Features?
2. Package
   • Should these types (+RouteValueDictionary) be in Http.Abstractions or Http.Features?

These types flow through a lot of repositories and changing them later before 3.0 will be a pain so lets attempt to make the best decision now. If we don't lock these down online in the PR in the next day I'll organize a quick meeting.

[davidfowl]

Consumption:

• Endpoints are first class (metadata + RequestDelegate) and are not tied to routing
• Accessible via the IEndpointFeature
  • Middleware can get the selected Endpoint and make decisions based on metadata (or whatever else)
  • We'll invoke the RequestDelegate as the last implicit thing in the middleware chain. Today we set a 404 by default (https://github.com/aspnet/HttpAbstractions/blob/bfa183747f6fb528087554c3d6ec58ef05f1c10a/src/Microsoft.AspNetCore.Http/Internal/ApplicationBuilder.cs#L84). We'll need to figure out where this code goes (is it a startup filter, is it part of the ApplicationBuilder, is it in hosting as an IStartupFilter)
• Exposing the matched routes on HttpRequest via a new IRouteValuesFeature

public interface IEndpointFeature
{
    Endpoint Endpoint { get; set; }
}

public interface IRouteValuesFeature
{
    RouteValueDictionary RouteValues { get; set; }
}

public class HttpRequest
{
    RouteValueDictionary RouteValues { get; set; }
}

Open questions:

• We need to figure out how to handle re-execution after the request path changes. The 2 middleware features we know that need this are the ErrorHandler middleware and the Rewrite middleware

[Tratcher]

Put it in AppBuilder and fall back to 404 if it's missing.

Hmm, if you do that then Map can end up executing the same endpoint regardless of the branch taken. Not sure how expected that would be.

[JamesNK]

• Namespaces updated to Microsoft.AspNetCore.Http (except RVD which is being type forwarded to)
• IRouteValuesFeature added
• RouteValues added to HttpRequest

Everything is still in Http.Abstractions and not Http.Endpoints. FYI RequestDelegate lives in Http.Abstractions so if Endpoint was moved to Http.Endpoints then RequestDelegate would need to be forwarded.

[JamesNK]

🆙 📅

Added implicit call to Endpoint's RequestDelegate.

[JamesNK]

There are a lot of outstanding PRs on routing and MVC for 2.2, some that touch these types. Once there is an all clear to check the PRs in and they're merged to master then I'll flow this through feature branches to routing/MVC/consuming middleware so we can see what it looks like.

[JamesNK]

Should IRouteValuesFeature be in 2.2? We're going to need to remove route values from IEndpointFeature in 2.2 so I'm guessing yes unless we want to keep using IRoutingFeature in 2.2.

[rynowak]

I could be convinced either way. We don't need it in 2.2...... but the other details that we are locking in 2.2 will require the design to be the same. So I think it has the same effect with the only delta being things like naming.

[JamesNK]

🆙 📅

Synced with changes in Routing:

• Split IRouteValuesFeature into its own interface
• Endpoint is no longer abstract
• Types live in Microsoft.AspNetCore.Http and Microsoft.AspNetCore.Http.Features namespaces (apart from RouteValueDictionary)

[JamesNK]

I'm confused. The HttpRequest.RouteValues property has disappeared from this commit. Did we decide to remove it, or did I somehow delete it in a rebase gone wrong?

I remember writing it, and there are comments about it on the PR - https://github.com/aspnet/HttpAbstractions/pull/1030#discussion_r210463585

@rynowak @davidfowl

[rynowak]

I seem to remember that we wanted it...

[JamesNK]

As do I. Maybe there was some reason it needed to be left out of this PR.

I'll add it back.

[davidfowl]

How did it disappear?