This may not be applicable to pure "Web API", and probably not for popular public-facing sites, but if you have this error 405 - Method Not Allowed issue on a website with IIS 10, with application built using AspNetCore 2.2, MVC 2 (or 3) and Angular 9, this was my experience. The error msg tells me that I could reach the MVC controller, but that "PUT" was not allowed (or found or listed) as one of my Http verb options on my MVC controller.
I could login with POST (because "Login()" was the name of my MVC controller method decorated with [HttpPost(route)]) and I could use the GET verb successfully. I use Routes for navigation.
But I could not use POST to create a new entry, PUT to edit them or DELETE to remove them. I received the "405" error.
In my case, removing the WebDAV references from web.config only changed the error I was receiving from a "405" to "400 - Bad Request".
But, this info was helpful, too, so I went back to Development mode, changed my MVC Controller methods names to match the HTTP Verb names, like "PUT" now matches to controller method "Put()" - even using [FromBody]. "DELETE" verb now matches to "Delete()" method name and POST matches to "Post()". I did not remove or change any necessary parameters like "id", etc, from the new method name.
I began testing again and received errors in dotnet server compile showing a problem with cross-site antiforgery issues in MVC Controllers paths.
I am also using antiforgery header/cookies in StartUp.cs, and it works in login POST, so I did not change anything in StartUp.cs.
But my MVC controller classes were decorated with the [AutoValidateAntiforgeryToken] attribute (don't fully understand why I used it, just followed my example), and my MVC controller methods were decorated with [HttpPut], etc.
So, because of the dotnet compile error, I removed the class-level attribute [AutoValidateAntiforgeryToken], but left the [HttpPut], etc, attributes in place at method-level for each MVC controller.
This was my solution, edited the web.config to remove WebDAV, made controller method names match http verbs and removed [AutoValidateAntiforgeryToken] attribute from MVC controller classes - since my website is private, not public facing.
I still have the Login header x-xsrf-token / cookies / antiforgery stuff in my StartUp.cs, and it still works on login. Still investigating how to get it to work at the MVC controller class level however.
But, for now, I can POST, PUT and DELETE with no error.
Update - from reading a few other posts about the **400 - Bad Request" issue, I found this link to "ASP.NET Core Web Api Antiforgery". It was very helpful. After doing the updates that the article suggested which included adding an MVC AntiForgeryController and an Angular Injectable service, I am able to PUT, POST and DELETE with CRSF turned on for my Controllers, using "ValidateAntiForgeryToken" on most controllers, but "Ignoring" some methods(), like the article suggests.
Besides the changes in the article, I also had this app registration in my StartUp.cs in the Configure() method - I have no public-facing routes except "login":
app.Use(nextDelegate => context =>
{
string path = context.Request.Path.Value;
string[] directUrls = { "/<first restricted url route>", "/<second restricted url route>", "/<third>" };
if (path.StartsWith("/api") || string.Equals("/", path) ||
directUrls.Any(url => path.StartsWith(url)))
{
var tokens = antiforgery.GetAndStoreTokens(context);
context.Response.Cookies.Append("XSRF-REQUEST-TOKEN", tokens.RequestToken,
new CookieOptions()
{
HttpOnly = false,
Secure = false,
IsEssential = true
});
}
return nextDelegate(context);
});
