Attribute-based routing returns 404 in cases that should be 405. This is similar to Issue#274
```
[RoutePrefix("api/v1/Echo")]
public class EchoController : ApiController
{
[HttpGet("{x}")]
public string Get(int x)
{
return x.ToString();
}
}
```
GET "api/v1/Echo/23" succeeds
DELETE "api/v1/Echo/23" should return 405. it returns 404.
DELETE "api/v2/Echo/23" can return 404 since there's no valid route for that.
It looks like the reason is that routes are added with method constraints, so the 404 comes from a different spot in the stack than regular routing. (See HttpRoutingDispatcher.SendAsync).
This is also related to Issue #954 (cors doesn't work with attribute routing), since cors also sends a different verb (options) than specified in the route.
Comments: Verified.
```
[RoutePrefix("api/v1/Echo")]
public class EchoController : ApiController
{
[HttpGet("{x}")]
public string Get(int x)
{
return x.ToString();
}
}
```
GET "api/v1/Echo/23" succeeds
DELETE "api/v1/Echo/23" should return 405. it returns 404.
DELETE "api/v2/Echo/23" can return 404 since there's no valid route for that.
It looks like the reason is that routes are added with method constraints, so the 404 comes from a different spot in the stack than regular routing. (See HttpRoutingDispatcher.SendAsync).
This is also related to Issue #954 (cors doesn't work with attribute routing), since cors also sends a different verb (options) than specified in the route.
Comments: Verified.