$req->address

$req->arguments

    print $c->request->arguments->[0];

For example, if your action was

    package MyApp::Controller::Foo;

    sub moose : Local {
        ...
    }

and the URI for the request was "http://.../foo/moose/bah", the string "bah" would be the first and only argument.

Arguments get automatically URI-unescaped for you.

$req->args

$req->base

If your application was queried with the URI "http://localhost:3000/some/path" then "base" is "http://localhost:3000/".

$req->body

$req->body_data

If the POST is malformed in some way (such as undefined or not content that matches the content-type) we raise a Catalyst::Exception with the error text as the message.

If the POSTed content type does not match an available data handler, this will also raise an exception.

$req->body_parameters

    print $c->request->body_parameters->{field};
    print $c->request->body_parameters->{field}->[0];

These are the parameters from the POST part of the request, if any.

NOTE If your POST is multipart, but contains non file upload parts (such as an line part with an alternative encoding or content type) we do our best to try and figure out how the value should be presented. If there's a specified character set we will use that to decode rather than the default encoding set by the application. However if there are complex headers and we cannot determine the correct way to extra a meaningful value from the upload, in this case any part like this will be represented as an instance of Catalyst::Request::PartData.

Patches and review of this part of the code welcomed.

$req->body_params

$req->content_encoding

$req->content_length

$req->content_type

$req->cookie

    $cookie  = $c->request->cookie('name');
    @cookies = $c->request->cookie;

$req->cookies

    print $c->request->cookies->{mycookie}->value;

The cookies in the hash are indexed by name, and the values are CGI::Simple::Cookie objects.

$req->header

$req->headers

    print $c->request->headers->header('X-Catalyst');

$req->hostname

$req->input

$req->query_keywords

    http://localhost/path?some+keywords

    $c->request->query_keywords will contain 'some keywords'

$req->match

$req->method

$req->param

    $value  = $c->request->param( 'foo' );
    @values = $c->request->param( 'foo' );
    @params = $c->request->param;

Like CGI, and unlike earlier versions of Catalyst, passing multiple arguments to this method, like this:

    $c->request->param( 'foo', 'bar', 'gorch', 'quxx' );

will set the parameter "foo" to the multiple values "bar", "gorch" and "quxx". Previously this would have added "bar" as another value to "foo" (creating it if it didn't exist before), and "quxx" as another value for "gorch".

NOTE this is considered a legacy interface and care should be taken when using it. "scalar $c->req->param( 'foo' )" will return only the first "foo" param even if multiple are present; "$c->req->param( 'foo' )" will return a list of as many are present, which can have unexpected consequences when writing code of the form:

    $foo->bar(
        a => 'b',
        baz => $c->req->param( 'baz' ),
    );

If multiple "baz" parameters are provided this code might corrupt data or cause a hash initialization error. For a more straightforward interface see "$c->req->parameters".

NOTE Interfaces like this, which are based on CGI and the "param" method are known to cause demonstrated exploits. It is highly recommended that you avoid using this method, and migrate existing code away from it. Here's a whitepaper of the exploit:

<http://blog.gerv.net/2014/10/new-class-of-vulnerability-in-perl-web-applications/>

NOTE Further discussion on IRC indicate that the Catalyst core team from 'back then' were well aware of this hack and this is the main reason we added the new approach to getting parameters in the first place.

Basically this is an exploit that takes advantage of how \param will do one thing in scalar context and another thing in list context. This is combined with how Perl chooses to deal with duplicate keys in a hash definition by overwriting the value of existing keys with a new value if the same key shows up again. Generally you will be vulnerable to this exploit if you are using this method in a direct assignment in a hash, such as with a DBIx::Class create statement. For example, if you have parameters like:

    user?user=123&foo=a&foo=user&foo=456

You could end up with extra parameters injected into your method calls:

    $c->model('User')->create({
      user => $c->req->param('user'),
      foo => $c->req->param('foo'),
    });

Which would look like:

    $c->model('User')->create({
      user => 123,
      foo => qw(a user 456),
    });

(or to be absolutely clear if you are not seeing it):

    $c->model('User')->create({
      user => 456,
      foo => 'a',
    });

Possible remediations include scrubbing your parameters with a form validator like HTML::FormHandler or being careful to force scalar context using the scalar keyword:

    $c->model('User')->create({
      user => scalar($c->req->param('user')),
      foo => scalar($c->req->param('foo')),
    });

Upcoming versions of Catalyst will disable this interface by default and require you to positively enable it should you require it for backwards compatibility reasons.

$req->parameters

    print $c->request->parameters->{field};
    print $c->request->parameters->{field}->[0];

This is the combination of "query_parameters" and "body_parameters".

$req->params

$req->path

    http://localhost/path/foo

    $c->request->path will contain 'path/foo'

$req->path_info

$req->protocol

$req->query_parameters

$req->query_params

    print $c->request->query_parameters->{field};
    print $c->request->query_parameters->{field}->[0];

$req->read( [$maxlength] )

$req->read_chunk(\$buff, $max)

You have to set MyApp->config(parse_on_demand => 1) to use this directly.

$req->referer

$req->secure

$req->captures

    my @captures = @{ $c->request->captures };

$req->upload

    $upload  = $c->request->upload('field');
    @uploads = $c->request->upload('field');
    @fields  = $c->request->upload;

    for my $upload ( $c->request->upload('field') ) {
        print $upload->filename;
    }

$req->uploads

    my $upload = $c->request->uploads->{field};
    my $upload = $c->request->uploads->{field}->[0];

$req->uri

$req->mangle_params( { key => 'value' }, $appendmode);

A quick example:

  # URI query params foo=1
  my $hashref = $req->mangle_params({ foo => 2 });
  # Result is query params of foo=2

versus append mode:

  # URI query params foo=1
  my $hashref = $req->mangle_params({ foo => 2 }, 1);
  # Result is query params of foo=1&foo=2

This is the code behind "uri_with".

$req->uri_with( { key => 'value' } );

You may also pass an optional second parameter that puts "uri_with" into append mode:

  $req->uri_with( { key => 'value' }, { mode => 'append' } );

See "mangle_params" for an explanation of this behavior.

$req->remote_user

$req->user_agent

$req->io_fh

$self->prepare_headers()

$self->prepare_body()

$self->prepare_body_chunk()

$self->prepare_body_parameters()

$self->prepare_cookies()

$self->prepare_connection()

$self->prepare_parameters()

If parameters have already been set will clear the parameters and build them again.

$self->env

meta