In general, a Catalyst application should dispatch all HTTP methods to a matching action, based only on the path. So, the code you posted which checks $c->req->method is a correct approach and should work. Since it doesn't work, the next question is whether you have any special middleware or Catalyst plugins that are affecting things. I didn't answer your previous question in hopes that someone would recognize the specific scenario, but I guess nobody did.

One of the powerful features of Catalyst is the great degree of "hooking" that you can do at all phases of handling the request. The downside is that a lot of the flow control of the application becomes hidden and makes a learning curve for the maintenance developer. A developer or plugin author might decide to make POST requests opt-in rather than manually switching inside of each action, or something like that. Your challenge is to find out where that happened.

First, check all the plugins loaded at the top level

use Catalyst qw/ PLUGIN1 PLUGIN2 PLUGIN3 ... /;
[download]

and read their CPAN documentation.

Then, check for the base class of the controller.

use Moose;
extends 'Catalyst::Controller';  # normal
# vs...
extends 'Catalyst::Controller::REST';  # changes behavior of things
[download]

Sometimes a project might also have a 'MyApp::Controller' base class used for all controllers where the author sets up the defaults they want to use for the project.

Check for the 'begin' and 'end' actions:

sub begin :SOME_MAGIC_ATTRIBUTE {}
[download]

or something more deliberate:

sub begin {
   my ($self, $c)= @_;
   if ($c->req->method ne 'GET') {
     $c->res->code(404);
     $c->detch;
   }
[download]

Then, check for behaviors of a parent controller, such as the root controller:

package MyApp::Controller::Root;

sub begin { ... }
[download]

and any controller in the filesystem hierarchy leading to the one that is giving you problems.

You can also put debug statements in each of the begin/end places to help log what is going on.

Hope that helps.