RedirectToAction() makes the link to HttpPost action instead of GET

[IgorXq]

Hi ! For GET and POST methods with the same action names,

Microsoft.AspNetCore.Routing.DefaultLinkGenerator[105]
      [2020-06-18 14:05:13.651]: Link generation succeeded for endpoints 

generates lincorrect link that in my case eventually led to "too many redirects". (as far as I have investigated, it happens because the link is generated to HttpPost method instead of HttpGet when they both have the same name)

The issue happens for route patterns such as [Route("[controller]/{parameter}/action}")]

and does not happen for the route patterns like [Route("[controller]/action/{parameter}")]

Just to mention, HttpPost action has route pattern [Route("[controller]/action")] (parameter passes in ViewModel)

I have managed with the issue having renamed POST methods so that their names don't match with GET methods.

As for me, such behavior seems incorrect (as well as that RedirectToAction considers POST methods at all to generate links) or I might have lack of knowledge about ASP.Net core MVC routing.

[javiercn]

@IgorXq thanks for contacting us.

Can you provide a minimal repro project and host it somewhere public (GH repo or upload it as a zip here) so that can make sure we are not missing any detail?

[IgorXq]

@javiercn thank you for a quick response.

Please check the demo project here

https://github.com/IgorXq/mvcdemo

If you run it, you can open the URL

http://localhost:5105/Dashboard/mytenant/same

that leads to the example page with correct and incorrect links formed by asp tag helpers.

The page http://localhost:5105/Dashboard/mytenant which should redirect to the url above, indeed ends up with "too many redirects" failure because of the link to the action

[ghost]

We've moved this issue to the Backlog milestone. This means that it is not going to be worked on for the coming release. We will reassess the backlog following the current release and consider this item at that time. To learn more about our issue management process and to have better expectation regarding different types of issues you can read our Triage Process.

[ghost]

Thanks for contacting us. We're moving this issue to the .NET 8 Planning milestone for future evaluation / consideration. Because it's not immediately obvious that this is a bug in our framework, we would like to keep this around to collect more feedback, which can later help us determine the impact of it. We will re-evaluate this issue, during our next planning meeting(s). If we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues. To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.

[MackinnonBuck]

I was able to reproduce this behavior. This seems like a bug IMO.

[muttonny]

Has this issue been resolved. And if so, which versions of .Net?