Skip to content

UnsupportedApiVersion error when route constraint prevents a match #423

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
sugarjig opened this issue Dec 31, 2018 · 4 comments
Closed

UnsupportedApiVersion error when route constraint prevents a match #423

sugarjig opened this issue Dec 31, 2018 · 4 comments
Assignees

Comments

@sugarjig
Copy link

I have a controller with an action that specifies a route constraint. Here is a snippet.

namespace Foo
{
    [ApiVersion("1.0")]
    [Produces("application/json")]
    [Route("api/v{version:apiVersion}/[controller]")]
    [ApiController]
    public sealed class ValuesController : ControllerBase
    {
        [HttpPut("{id:guid}")]
        public async Task<IActionResult> PutValueAsync(
            [FromRoute] Guid id,
            [FromBody] Value value)
        {
        }
    }

If I make a request with a valid GUID in the path (i.e. PUT /api/v1/12345678-90ab-cdef-1234-567890abcdef), everything works as expected. But if I use an invalid GUID in the path (e.g. PUT /api/v1/1234), I get a 400 with the following body:

{
    "error": {
        "code": "UnsupportedApiVersion",
        "message": "The HTTP resource that matches the request URI 'https://localhost:5001/api/v1/consumers/be4d7d66-f01d-4766-a71d-66c0d82d947/consumption' does not support the API version '1'.",
        "innerError": null
    }
}

I'm expecting a 404 because no route is supposed to match, according to the documentation.

I'm using ASP.NET Core 2.2 and API Versioning version 3.1.

@commonsensesoftware
Copy link
Collaborator

Technically, this has been the existing behavior for API versioning due to limitations in the routing system. Endpoint Routing addresses most of these limitations. I had things short-circuiting if a candidate is already invalid. This might exclude candidates that match the requested API version, but are already invalid (ex: due to an invalid route constraint) and ultimately produce an unexpected response. Since this wasn't the expected intent, I'll consider it a bug. I should have the fix out shortly.

For future reference, here are the behavioral differences:

Legacy Routing

Status Code Source Description
400 API Versioning No matching API versions
400 API Versioning Possible candidates, but no matches
400 ASP.NET Invalid model state
404 ASP.NET No matching candidates
405 API Versioning No matching HTTP method

Endpoint Routing

Status Code Source Description
400 API Versioning No matching API versions
400 ASP.NET Invalid model state
404 ASP.NET No matching candidates
405 ASP.NET No matching HTTP method

@commonsensesoftware
Copy link
Collaborator

3.1.1 with the fix is now available. Thanks.

@sugarjig
Copy link
Author

sugarjig commented Jan 2, 2019

It's working now! Thank you!

@pwdst
Copy link

pwdst commented Jan 11, 2021

This issue appears to have returned as a regression in version 4.2.0

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants