UseHttpMethodOverride not working in .NET 8.0 RC1

[andrewdavey]

Is there an existing issue for this?

• I have searched the existing issues

Describe the bug

I'm trying to upgrade a .NET 6 web application to .NET 8 RC1. I have app.UseHttpMethodOverride() to allow client to post with the X-Http-Method-Override header.

I'm getting 405 (Method Not Allowed) responses from the endpoints that are mapping non-POST methods. My code is not getting called at all. It's like the pipeline is failing to use the modified HTTP method to route correctly.

Expected Behavior

My endpoint for a non-POST HTTP method should be called.

Steps To Reproduce

Minimal reproduction:

var builder = WebApplication.CreateBuilder(args);
var app = builder.Build();
app.UseHttpMethodOverride();
app.MapDelete("/", () => "delete");
app.Run();

Run that, then make a request e.g. with powershell:

Invoke-WebRequest -Uri http://localhost:5070/ -Method POST -Headers @{ 'X-Http-Method-Override' = 'DELETE' }

Exceptions (if any)

No response

.NET Version

8.0.100-rc.1.23463.5

Anything else?

No response

[captainsafia]

Thanks for reporting this issue, @andrewdavey!

I believe this is related to the fact that the routing middleware is enabled implicitly in the WebApplication and runs before the HttpOverrides middleware. Can you see if invoking the middlewares explicitly in the correct order works for you? It works on my end.

var builder = WebApplication.CreateBuilder(args);
var app = builder.Build();

app.UseHttpMethodOverride();
app.UseRouting();

app.MapDelete("/", () => "delete");
app.Run();

[ghost]

Hi @andrewdavey. We have added the "Needs: Author Feedback" label to this issue, which indicates that we have an open question for you before we can take further action. This issue will be closed automatically in 7 days if we do not hear back from you by then - please feel free to re-open it if you come back to this issue after that time.

[andrewdavey]

Thanks for the quick response. Inserting UseRouting() does fix my initial example. However, my real application is using controllers. I'm still getting a 405 status response when requesting controller actions that use attribute mapping.

Example:

using Microsoft.AspNetCore.Mvc;

var builder = WebApplication.CreateBuilder(args);
builder.Services.AddControllers();

var app = builder.Build();

app.UseHttpMethodOverride();
app.UseRouting();
app.MapControllers();
app.Run();

public class TestController : Controller
{
    [HttpDelete("/")]
    public string Delete() => "delete";
}

[viliml]

builder.Services.AddControllers(); registers authorization services:

aspnetcore/src/Mvc/Mvc/src/MvcServiceCollectionExtensions.cs

Lines 132 to 138 in 46562b1

	private static IMvcCoreBuilder AddControllersCore(IServiceCollection services)
	{
	// This method excludes all of the view-related services by default.
	var builder = services
	.AddMvcCore()
	.AddApiExplorer()
	.AddAuthorization()

When authorization services are registered, the authorization middleware is inserted:

aspnetcore/src/DefaultBuilder/src/WebApplicationBuilder.cs

Lines 447 to 452 in 46562b1

	if (serviceProviderIsService?.IsService(typeof(IAuthorizationHandlerProvider)) is true)
	{
	if (!_builtApplication.Properties.ContainsKey(AuthorizationMiddlewareSetKey))
	{
	_builtApplication.Properties[AuthorizationMiddlewareSetKey] = true;
	app.UseAuthorization();

Before all the user-defined middlewares:

aspnetcore/src/DefaultBuilder/src/WebApplicationBuilder.cs

Lines 465 to 467 in 46562b1

	// Wire the source pipeline to run in the destination pipeline
	var wireSourcePipeline = new WireSourcePipeline(_builtApplication);
	app.Use(wireSourcePipeline.CreateMiddleware);

The authorization middleware inserts a new instance of routing middleware immediately after itself as long as global routing is already defined:

aspnetcore/src/Security/Authorization/Policy/src/AuthorizationAppBuilderExtensions.cs

Lines 36 to 43 in 46562b1

	// The authorization middleware adds annotation to HttpContext.Items to indicate that it has run
	// that will be validated by the EndpointsRoutingMiddleware later. To do this, we need to ensure
	// that routing has run and set the endpoint feature on the HttpContext associated with the request.
	if (app.Properties.TryGetValue(RerouteHelper.GlobalRouteBuilderKey, out var routeBuilder) && routeBuilder is not null)
	{
	return app.Use(next =>
	{
	var newNext = RerouteHelper.Reroute(app, routeBuilder, next);

However, global routing is always defined:

aspnetcore/src/DefaultBuilder/src/WebApplicationBuilder.cs

Lines 412 to 413 in 46562b1

	// Set the route builder so that UseRouting will use the WebApplication as the IEndpointRouteBuilder for route matching
	app.Properties.Add(WebApplication.GlobalEndpointRouteBuilderKey, _builtApplication);

The authorization rerouting middleware runs before the HTTP method override middleware and sends the request to 405, and the subsequent user-defined routing middleware doesn't dare question its predecessor's decision:

aspnetcore/src/Http/Routing/src/EndpointRoutingMiddleware.cs

Lines 61 to 67 in 46562b1

	// There's already an endpoint, skip matching completely
	var endpoint = httpContext.GetEndpoint();
	if (endpoint != null)
	{
	Log.MatchSkipped(_logger, endpoint);
	return _next(httpContext);
	}

Removing authorization fixes the problem in this particular scenario:

using Microsoft.AspNetCore.Mvc;

var builder = WebApplication.CreateBuilder(args);
builder.Services.AddMvcCore();

var app = builder.Build();

app.UseHttpMethodOverride();
app.UseRouting();
app.MapControllers();
app.Run();

public class TestController : Controller
{
    [HttpDelete("/")]
    public string Delete() => "delete";
}

To properly fix the underlying problem, the HTTP method override middleware needs to reroute the request after changing the method. I implemented that here (3aff15b) and verified it works, but I daren't open a pull request since I'm not sure I did it in the best possible way.

[viliml]

Would also be fixed by #50864

[captainsafia]

@viliml Spot on!

@andrewdavey Explicitly registering all the middlewares in the correct order should do the trick while we wait to roll out RC2.