"405: Method not allowed" = Misleading error message → Replace with better HTTP status code

[SetTrend]

Is your feature request related to a problem? Please describe.

If HttpPost/HttpDelete attributes won't precisely reflect the Web API endpoint, HTTP status 405 Method not allowed is returned to the client.

I believe this status message to be inappropriate, confusing and misleading.

Describe the solution you'd like

I suggest to, instead, return one of the following status codes in the above case:

• 400 Bad Request
• 404 Not Found
• 501 Not Implemented

Additional context

See the following two StackOverflow issues:

• ASP.NET Core Web API / Kestrel: HTTP Verbs PUT and DELETE: 405 Method not allowed - how to allow?
• ASP.NET Core Web API: Routing by method name?

[analogrelay]

If HttpPost/HttpDelete attributes won't precisely reflect the Web API endpoint

To clarify, do you mean you have a situation where you specify HttpPost but the user sends a GET or DELETE or other non-POST method?

I believe this status message to be inappropriate, confusing and misleading.

I'm not sure I understand why you think this is an inappropriate response assuming I understand your scenario correctly. The server is making clear (via the attributes) which HTTP Method is allowed (POST, DELETE, etc.) and if the client uses a different one, we return a 405 error, to tell the client they used the wrong HTTP Method.

Can you provide a small runnable sample that reproduces the problem and describe what behavior you'd expect to see?

[SetTrend]

At this time I'm in a critical project phase at my customers'. So, I currently don't have time/resources to create a sample project.

Let me give you a brief example:

[Route("api/[controller]")]
[ApiController]
public class MyController
{
  public ActionResult Delete(int id)
  {...}
}

-or-

[Route("api/[controller]")]
[ApiController]
public class MyController
{
  [HttpDelete]
  public ActionResult Delete(int id)
  {...}
}

Both return "405 Method not allowed" on a request like

DELETE http://localhost/api/my/1 HTTP/1.1

[analogrelay]

Ah, I see. So you are using an HTTP method allowed by the request. Thanks for the extra context! Someone from MVC would need to look at this further (they'll look at it during their regular triage process). Getting a runnable sample project would certainly help diagnose the issue.

[mkArtakMSFT]

Thanks for contacting us, @SetTrend.
Please share the full controller code.

[SetTrend]

Thanks, @anurse and @mkArtakMSFT, for your kind help.

At this time my controller works as expected because I found the reason for this issue after a while and corrected the code.

I may be able to get some spare time in 2-3 weeks to create a sample project. If that'd be sufficient for you?

[mkArtakMSFT]

Sure, that will be fine. I hope, though, that we may be able to find time and try to repro this on our own before then.

/cc @rynowak , @pranavkm

[mkArtakMSFT]

@ryanbrandenburg please work with @pranavkm and try to repro this.

[pranavkm]

@SetTrend my guess is that you have another action with the exact route but a different HTTP method constraint. It's the most likely explanation for why you're seeing a 405. If you think this isn't the case and have an application that reproduces the issue, feel free to reopen this issue.

[silkfire]

@SetTrend What did you change in your code in order to resolve this issue?

@rynowak @mkArtakMSFT @pranavkm Coming from 2.2, I find it strange that I'm getting 405 instead of 404. The Method Not Allowed status code indicates that the resource does exist, but not under the requested verb, shouldn't this be considered a security issue as this exposes the knowledge of resource to a caller that they should not even know the existence of?