Introduction

Dealing with incoming request parameters (both query and body parameters) is something nearly all Perl Catalyst applications need to cope with. Unfortunately Catalyst punts here and doesn't give you a lot of guidance and the built in handling leaves a lot to be desired. In this blog I will first example how the default handling works, some of the problems with it and how Catalyst developers have tried to improve it over the years (with minor success IMHO; I can say that since half the redos are my fault ;)).

How Catalyst Handles Request Bodies and Query Parameters

By default incoming query and body parameters get mapped to the Catalyst Request object:

  $c->request->query_parameters

  $c->request->body_parameters

query_parameters gives you access to parameters passed in the 'query' section of your request URL. For example if your URL is https://example.com/page/?aaa=1&bbb=2 then query_parameters will return the following hashref:

  +{

    aaa => "1",

    bbb => "2",

  }

The body_parameters method gives you access to classic HTML Form POST bodies. For example if you have an HTML Form like this:

<form action="/login" method="post">

    <label for="username">Username:</label>

    <input type="text" id="username" name="username">

    <label for="password">Password:</label>

    <input type="password" id="password" name="password">

    <button type="submit">Login</button>

</form>

When the user clicks the submit button you would expect the following hashref in body_parameters:

  +{

    username => "$USERNAME",

    password => "$PASSWORD",

  }

(Substitute $USERNAME and $PASSWORD for whatever the user typed into the form).

Both method return a hashref of key value pairs where the key in the field or parameter and the value is a scalar or arrayref (depending on if there is one or several values for the given field in the request).

For basic applications this has worked acceptably but there's a number of issues. First of all the fact that the key can be either a scalar or arrayref is annoying, requiring you to write tons of defensive code like:

my $username = $c->req->body_parameters->{username};

$username = ref $username eq 'ARRAY' ? $username[-1] : ($username);

Or just ignore the problem and potentially open yourself to security issues. Speaking of security issues I don't know how many times I've seen code like this, passing incoming body parameters straight into a DBIx::Class object:

  my $new_user = $c->model('Schema::User')->create($c->req->body_parameters);

This is a world of hurt since you are basically passing whatever the user submitted (or your site hacker is submitting) directly to DBIC create. You need to be more choosey about the incoming at the very least:

  my $new_user = $c->model('Schema::User')->create(

    username => ref($c->req->body_params->{username}) eq 'ARRAY' ? $c->req->body_params->{username}[-1] : $c->req->body_params->{username},

    password => ref($c->req->body_params->{password}) eq 'ARRAY' ? $c->req->body_params->{password}[-1] : $c->req->body_params->{password},

  );

At which point you are starting to have a lot of ugly code and you haven't even started on form validation yet. And with all this repeated code its easy to have a hard to spot typo:

  my $new_user = $c->model('Schema::User')->create(

    username => ref($c->req->body_params->{username}) eq 'ARRAY' ? $c->req->body_params->{usrname}[-1] : $c->req->body_params->{usernme},

  ...

I've seen a lot of typo issues in Catalyst applications just like this, and they can lead to hard to spot problems since in Perl having a typo in the hash de-reference will not lead to a hard runtime error generally, you just get 'undef' for a value in an unexpected location. I've seen this problem in Catalyst code which existed for years in the wild.

Another thing I've seen a lot of is line after line of parameter processing code stuck into controllers. As it turns out parameter munging is one of the bigger jobs a programmer in a web application can have, especially as the application gets older and you need to introduce new features without breaking backward compatibility. This can lead to very long and ugly controllers that make following the flow of logic in your request to response cycle difficult.

You can solve the 'is it a value or an arrayref?' problem by enabled the use_hash_multivalue_in_request configuration option. This gives you a Hash::MultiValue object instead of a hashref of request parameters. Amongst other things it make it easy to say 'when there's more than one value give me only the last one', which is nearly always the right thing as legitimate uses for this typically revolve around HTML Form tricks where some field types like checkboxes don't make it easy to know when the user is explicitly setting an 'off' state. See . Other approaches on CPAN that can do similar would be and Valiant

Bonus Idea

I often use a similar approach to wrap the Catalyst session (also represented as a hash reference) in a model, to offer a strongly typed interface to the session. Can you figure out the code for that?