UnsupportedApiVersion when the request is redirected from HTTP (via 302).

[enihcam]

The redirect logic is
app.UseRewriter(new RewriteOptions().AddRedirectToHttps(StatusCodes.Status302Found, 44346));

Then when I accessed http://localhost:80/subscriptions/12345?api-version=2.0, I got:
{ "Error": { "Code": "UnsupportedApiVersion", "Message": "The HTTP resource that matches the request URI 'https://localhost:44346/subscriptions/12345?api-version=2.0' does not support the API version '2.0'." } }

But directly access to https://localhost:44346/subscriptions/12345?api-version=2.0 worked fine.

[commonsensesoftware]

This is odd. I'll have to setup a repro to test this. I would have expected the rewrite middleware to hijack the request before API versioning gets involved. There's a chance this is related to another issue I've only recently seen where the IActionSelector is called more than once, which is not expected. I'll see what I can find out. If you discover any other information, please share.

[commonsensesoftware]

I didn't get a chance to verify the cause before the release candidate, but whatever the cause was, it appears to be fixed now. I set up a repro with rewriting and it worked. Try updating to the 1.1 RC and see if that resolves your issue. Should nothing regress, I'm planning on releasing by the end of the week.

Also keep in mind that the configuration order matters. Your configuration method should be something like:

public void Configure( IApplicationBuilder app, IHostingEnvironment env )
{
    var options = new RewriteOptions();

    // TODO: add your rewrite options

    app.UseRewriter( options );
    app.UseMvc();
    app.UseApiVersioning();
}

[commonsensesoftware]

It seems you've figured out the issue or it was resolved in the RC release. In the event that this issue was hit by the RC1 regression, RC2 has been officially published. Let me know if you run into any other issues or reopen the issue if it's unresolved. Thanks.

[cleftheris]

Hi I wanted to report an additional use case that I experienced this error happening.

For instance when someone uses the [FormatFilter] attribute on an action.

the following fails upon calling the PUT method.

[Route("v{apiVersion}/products), ApiVersion("1.0")]
public class ProductsController 
{

    [HttpGet("{invoiceId}.{format?}")]
    [FormatFilter]
    IActionResult GetProduct([FromRoute]Guid productId, [FromRoute]string format) { ... }
    
    [HttpPut("{invoiceId}")]
    IActionResult UpdateProduct([FromRoute]Guid productId, [FromBody]Product model) { ... }
}

while this works. simply by changing the GET route not to use the format on the route itself but putting it in the querystring [FromQuery] string format.

[Route("v{apiVersion}/products), ApiVersion("1.0")]
public class ProductsController 
{

    [HttpGet("{invoiceId}")]
    [FormatFilter]
    IActionResult GetProduct([FromRoute]Guid productId, [FromQuery]string format) { ... }
    
    [HttpPut("{invoiceId}")]
    IActionResult UpdateProduct([FromRoute]Guid productId, [FromBody]Product model) { ... }
}

I believe that this could be a bug.

Cheers!

[commonsensesoftware]

Which package version are you using? This is should be fixed in the RCs. I'm imminently about to release RC3. The issue is that the router sees two overlapping candidates and goes through the action selection process multiple times, which was not [originally] expected. This causes the selection process to short-circuit and return the wrong result (too early). This is also why everything suddenly starts working when the route templates are the same. It has nothing to do with the GET or PUT methods.

If you're not a RC, give that a try. Also don't forget that you'll need app.UseMvc().UseApiVersioning() in your configuration now. Let me know how that goes.

[cleftheris]

Thanks for the answer @commonsensesoftware . I am using the latest stable version. I will switch to the prerelease track and report back next week.