Have you stated correct method on the form?

<form method="post">

Hi @Johan Peterson,

my form looks like that bellow:

@using (Html.BeginForm("MyPostAction", "MyController", FormMethod.Post, new {id= "myForm",enctype = "multipart/form-data", @class = "epi-FormArea"}))
{
@Html.AntiForgeryToken()
...
<div class="epi-buttonContainer">
<span class="epi-cmsButton">
<input class="epi-cmsButton-text epi-cmsButton-tools epi-cmsButton-Import" id="submitButton" type="submit" value="Submit">
</span>
<span class="epi-cmsButton">
@* <input class="" id="submitButton2" type="button" value="Import #2" onclick="document.getElementById('myForm').submit()"> *@
<a href="javascript:document.getElementById('myForm').submit()">Submit!</a>
</span>
</div>
}


None of the submit trials above hit the POST-method MyPostAction. That action does not have a HttpGet counterpart, so the error is 404. If I use the Index Action instead (which has HttpGet and HttpPost variants), then the click on the submit-button (link) hits the GET-version of the action.

Many thanks and kind regards.

The form seems correct. And are you sure that this is a GET, is that what the browser console (F12 tools) says as well?

Hi @Johan Peterson,

I can see three entries in the Network tab:

• first is a POST request with status code 301 (moved permanently), the initiator is "Other"
• second is a GET request with the same status - 301, the initiator is MyController
• third is a GET request with status 404 (not found), the initiator is the Route / MyController

This leads me to the conclusion, the route seems to be not correct... I've configured it this way:

RouteTable.Routes.MapRoute(
"MyPlugin",
"MyController/{action}",
new { controller = "MyController", action = "Index" } );

Do you recognize here something wrong?

Many thanks and kind regards.

Depends on where you have put your controller (in which namespace). Please see https://blog.novacare.no/creating-episerver-admin-plugins-using-mvc/

Here's the controller's declaration:

namespace MyApplication.Controllers
{
using System.Web.Mvc;
using EPiServer.PlugIn;
using EPiServer.ServiceLocation;
using Models.ViewModels;

[GuiPlugIn(Area = PlugInArea.AdminMenu, DisplayName = "Custom Tool Plugin", Url = "/MyController")]
[Authorize(Roles = "CmsAdmins, WebAdmins")]
public class MyController : Controller
{
...
}

}

Your controller must have an action called MyPostAction that accepts a posts as well.

Yes, the controller has that action, also it has the GET+POST Index actions.

Is the form posted to the correct URL? Either inspect the html and check the action attribute on the form or network tab in the F12 tools.

I think so - the form gets posted to a URL like this http://localhost:12345/MyController/MyPostAction (or in case of using the Index action http://localhost:12345/MyController). But the question here would be why the POST comes from "Other" and gets responded with 301 from the server... To my understanding, this would really mean the controller has not been configured correctly... But how to configure it correctly?! And finally then why the GET request goes straight to the right controller action? Like on the same controller the GET is correct, the POST is wrong... 

Do you have any rewrite rules that are doing redirects? A 404 handler? Other routes that triggers before this one? Try putting this route first in the route table.

For handling 404-errors, I'm using the BVN 404 Handler:

Web.config:
<bvn404Handler handlerMode="On">
</bvn404Handler>

And I also have a redirect.config with redirect rules (good catch from your side!), whose last action on the configured rule (one single rule has been configured) is:

<action type="Redirect" url="{ToLower:{URL}}" redirectType="Permanent" />

And this seems the reason why the redirection gets status 301 (permanent) and it seems the controller MyController has not been listed in the conditions block of the rule... I'll look at this and will change the rule's conditions to see if when I add the controller to the conditions, it will start to behave correctly... Will report here as soon as I've results...

Many thanks and kind regards.

Thanks @Johan Peterson, for your help on solving my problem.

I can confirm the problem has been solved after the redirect rule has been extended with a condition for the MyController route.

Kind regards.