ApiVersion status value causing routing issues (error 404)

[PascalWillems]

Is there an existing issue for this?

• I have searched the existing issues

Describe the bug

Defining the following ApiVersion causes endpoints that use this version to not be accessible (Error 404)
ApiVersion: "2.0-preview" (Major: 2, Minor: 0, status: "preview")

Expected Behavior

Endpoints for the ApiVersion are accessible, and actions can be called on it.

Steps To Reproduce

1. Create a simple (default) ASP.NET Web Api project and enable Api versioning with URL segments (using the Asp.Versioning.Mvc Nuget package).
2. Add the following Route attribute on the default controller: [Route("v{version:apiVersion}/[controller]/[action]")]
3. Add the following ApiVersion attributes on the default controller:

• [ApiVersion("1.0")]
• [ApiVersion("2.0-alpha")]
• [ApiVersion("2.0-preview")]

4. Run the Api
5. Try to call a action of version "2.0-alpha" -> Works
6. Try to call a action of version "2.0-preview" -> Doesn't work (error 404)

Exceptions (if any)

No response

.NET Version

8.0.403

Anything else?

After some early debugging, I came across the following method that seems to cause the issue: Microsoft.AspNetCore.Routing.RoutePatternMatcher.MatchComplexSegmentCore
More specifically the following portion:

int indexOfLiteral;
if (part.IsLiteral)
{
    var literal = (RoutePatternLiteralPart)part;
    indexOfLiteral = requestSegment.Slice(0, startIndex).LastIndexOf(
    literal.Content,
    StringComparison.OrdinalIgnoreCase);
}

Here it seems that the wrong index is calculated for the "v" literal that prefixes the version in the URL in the case of ApiVersion "2.0-preview".
It uses the index of the "v" in the word "preview" instead of the "v" at the start of the URL parameter "v2.0-preview".

[oussamatecnique]

I confirm the issue with this case: [ApiVersion("2.0-preview")]
for this route template: [Route("v{version:apiVersion}/[controller]/[action]")]

but I guess this is can be avoided just by removing literal v at the start, is there a specific need for it?

[captainsafia]

@PascalWillems Interesting bug report!

I'd typically be open to reviewing a PR to resolve this issue but I'm very cautious when it comes to make changes in the routing layer, especially since the changes can be subtle and might introduce breaks to existing scenarios.

In this case, it seems like the best option might be to require a workaround in the app code as @oussamatecnique mentioned and remove the v prefix.

I'll stick the issue in the backlog for now to given us a chance to evaluate the severity and whether it is worth investigating a change in the routing layer for this.

[PascalWillems]

@captainsafia @oussamatecnique Yes, removing the v prefix (or changing the version status) is the most straightforward and quickest workaround that you can use to avoid this issue. So for others that are experiencing this issue I would also recommend that if you need a speedy fix.

It is just that the error 404 this issue causes is a very unexpected error and unclear as to what would be causing it. In case that adding the v prefix (or in my case adding a version status 2.0-preview) is the only change you've made, then it is not so hard to identify that adding the version status is causing the 404. But if you've made more changes it could prove to be much more challenging, simply because you wouldn't immediately link an ApiVersion status flag value to this kind of error and because debugging the issue includes almost exclusively framework code.

@PascalWillems Interesting bug report!
I'll stick the issue in the backlog for now to given us a chance to evaluate the severity and whether it is worth investigating a change in the routing layer for this.

Perfect! That's the reason I posted the issue. I hope someone can find some time to take a look at it and hopefully fix it.