Catalyst - The Elegant MVC Web Application Framework
See the Catalyst::Manual distribution for comprehensive documentation and tutorials.
# Install Catalyst::Devel for helpers and other development tools # use the helper to create a new application catalyst.pl MyApp # add models, views, controllers script/myapp_create.pl model MyDatabase DBIC::Schema create=static dbi:SQLite:/path/to/db script/myapp_create.pl view MyTemplate TT script/myapp_create.pl controller Search # built in testserver -- use -r to restart automatically on changes # --help to see all available options script/myapp_server.pl # command line testing interface script/myapp_test.pl /yada ### in lib/MyApp.pm use Catalyst qw/-Debug/; # include plugins here as well ### In lib/MyApp/Controller/Root.pm (autocreated) sub foo : Global { # called for /foo, /foo/1, /foo/1/2, etc. my ( $self, $c, @args ) = @_; # args are qw/1 2/ for /foo/1/2 $c->stash->{template} = 'foo.tt'; # set the template # lookup something from db -- stash vars are passed to TT $c->stash->{data} = $c->model('Database::Foo')->search( { country => $args[0] } ); if ( $c->req->params->{bar} ) { # access GET or POST parameters $c->forward( 'bar' ); # process another action # do something else after forward returns } } # The foo.tt TT template can use the stash data from the database [% WHILE (item = data.next) %] [% item.foo %] [% END %] # called for /bar/of/soap, /bar/of/soap/10, etc. sub bar : Path('/bar/of/soap') { ... } # called for all actions, from the top-most controller downwards sub auto : Private { my ( $self, $c ) = @_; if ( !$c->user_exists ) { # Catalyst::Plugin::Authentication $c->res->redirect( '/login' ); # require login return 0; # abort request and go immediately to end() } return 1; # success; carry on to next action } # called after all actions are finished sub end : Private { my ( $self, $c ) = @_; if ( scalar @{ $c->error } ) { ... } # handle errors return if $c->res->body; # already have a response $c->forward( 'MyApp::View::TT' ); # render template } ### in MyApp/Controller/Foo.pm # called for /foo/bar sub bar : Local { ... } # called for /blargle sub blargle : Global { ... } # an index action matches /foo, but not /foo/1, etc. sub index : Private { ... } ### in MyApp/Controller/Foo/Bar.pm # called for /foo/bar/baz sub baz : Local { ... } # first Root auto is called, then Foo auto, then this sub auto : Private { ... } # powerful regular expression paths are also possible sub details : Regex('^product/(\w+)/details$') { my ( $self, $c ) = @_; # extract the (\w+) from the URI my $product = $c->req->captures->[0]; }
See Catalyst::Manual::Intro for additional information.
Catalyst is a modern framework for making web applications without the pain usually associated with this process. This document is a reference to the main Catalyst application. If you are a new user, we suggest you start with Catalyst::Manual::Tutorial or Catalyst::Manual::Intro.
See Catalyst::Manual for more documentation.
Catalyst plugins can be loaded by naming them as arguments to the "use Catalyst" statement. Omit the Catalyst::Plugin:: prefix from the plugin name, i.e., Catalyst::Plugin::My::Module becomes My::Module.
Catalyst::Plugin::
Catalyst::Plugin::My::Module
My::Module
use Catalyst qw/My::Module/;
If your plugin starts with a name other than Catalyst::Plugin::, you can fully qualify the name by using a unary plus:
use Catalyst qw/ My::Module +Fully::Qualified::Plugin::Name /;
Special flags like -Debug and -Engine can also be specified as arguments when Catalyst is loaded:
-Debug
-Engine
use Catalyst qw/-Debug My::Module/;
The position of plugins and flags in the chain is important, because they are loaded in the order in which they appear.
The following flags are supported:
Enables debug output. You can also force this setting from the system environment with CATALYST_DEBUG or <MYAPP>_DEBUG. The environment settings override the application, with <MYAPP>_DEBUG having the highest priority.
This sets the log level to 'debug' and enables full debug output on the error screen. If you only want the latter, see $c->debug.
Forces Catalyst to use a specific engine. Omit the Catalyst::Engine:: prefix of the engine name, i.e.:
Catalyst::Engine::
use Catalyst qw/-Engine=CGI/;
Forces Catalyst to use a specific home directory, e.g.:
use Catalyst qw[-Home=/usr/mst];
This can also be done in the shell environment by setting either the CATALYST_HOME environment variable or MYAPP_HOME; where MYAPP is replaced with the uppercased name of your application, any "::" in the name will be replaced with underscores, e.g. MyApp::Web should use MYAPP_WEB_HOME. If both variables are set, the MYAPP_HOME one will be used.
CATALYST_HOME
MYAPP_HOME
MYAPP
If none of these are set, Catalyst will attempt to automatically detect the home directory. If you are working in a development envirnoment, Catalyst will try and find the directory containing either Makefile.PL, Build.PL or dist.ini. If the application has been installed into the system (i.e. you have done make install), then Catalyst will use the path to your application module, without the .pm extension (ie, /foo/MyApp if your application was installed at /foo/MyApp.pm)
make install
use Catalyst '-Log=warn,fatal,error';
Specifies a comma-delimited list of log levels.
Enables statistics collection and reporting.
use Catalyst qw/-Stats=1/;
You can also force this setting from the system environment with CATALYST_STATS or <MYAPP>_STATS. The environment settings override the application, with <MYAPP>_STATS having the highest priority.
Stats are also enabled if debugging is enabled.
Returns a Catalyst::Action object for the current action, which stringifies to the action name. See Catalyst::Action.
Returns the namespace of the current action, i.e., the URI prefix corresponding to the controller of the current action. For example:
# in Controller::Foo::Bar $c->namespace; # returns 'foo/bar';
Returns the current Catalyst::Request object, giving access to information about the current client request (including parameters, cookies, HTTP headers, etc.). See Catalyst::Request.
Forwards processing to another action, by its private name. If you give a class name but no method, process() is called. You may also optionally pass arguments in an arrayref. The action will receive the arguments in @_ and $c->req->args. Upon returning from the function, $c->req->args will be restored to the previous values.
process()
@_
$c->req->args
Any data returned from the action forwarded to, will be returned by the call to forward.
return
my $foodata = $c->forward('/foo'); $c->forward('index'); $c->forward(qw/Model::DBIC::Foo do_stuff/); $c->forward('View::TT');
Note that forward implies an eval { } around the call (actually execute does), thus de-fatalizing all 'dies' within the called action. If you want die to propagate you need to do something like:
eval { }
die
$c->forward('foo'); die join "\n", @{ $c->error } if @{ $c->error };
Or make sure to always return true values from your actions and write your code like this:
$c->forward('foo') || return;
Another note is that $c->forward always returns a scalar because it actually returns $c->state which operates in a scalar context. Thus, something like:
$c->forward
return @array;
in an action that is forwarded to is going to return a scalar, i.e. how many items are in that array, which is probably not what you want. If you need to return an array then return a reference to it, or stash it like so:
$c->stash->{array} = \@array;
and access it from the stash.
Keep in mind that the end method used is that of the caller action. So a $c->detach inside a forwarded action would run the end method from the original action requested.
end
$c->detach
The same as forward, but doesn't return to the previous action when processing is finished.
When called with no arguments it escapes the processing chain entirely.
Almost the same as forward, but does a full dispatch, instead of just calling the new $action / $class->$method. This means that begin, auto and the method you go to are called, just like a new request.
$action
$class->$method
begin
auto
In addition both $c->action and $c->namespace are localized. This means, for example, that $c->action methods such as name, class and reverse return information for the visited action when they are invoked within the visited action. This is different from the behavior of forward, which continues to use the $c->action object from the caller action even when invoked from the callee.
$c->action
$c->namespace
$c->stash is kept unchanged.
$c->stash
In effect, visit allows you to "wrap" another action, just as it would have been called by dispatching from a URL, while the analogous go allows you to transfer control to another action as if it had been reached directly from a URL.
The relationship between go and visit is the same as the relationship between forward and detach. Like $c->visit, $c->go will perform a full dispatch on the specified action or method, with localized $c->action and $c->namespace. Like detach, go escapes the processing of the current request chain on completion, and does not return to its caller.
go
$c->visit
$c->go
detach
@arguments are arguments to the final destination of $action. @captures are arguments to the intermediate steps, if any, on the way to the final sub of $action.
Returns the current Catalyst::Response object, see there for details.
Returns a hashref to the stash, which may be used to store data and pass it between components during a request. You can also set hash keys by passing arguments. The stash is automatically sent to the view. The stash is cleared at the end of a request; it cannot be used for persistent storage (for this you must use a session; see Catalyst::Plugin::Session for a complete system integrated with Catalyst).
$c->stash->{foo} = $bar; $c->stash( { moose => 'majestic', qux => 0 } ); $c->stash( bar => 1, gorch => 2 ); # equivalent to passing a hashref # stash is automatically passed to the view for use in a template $c->forward( 'MyApp::View::TT' );
Returns an arrayref containing error messages. If Catalyst encounters an error while processing a request, it stores the error in $c->error. This method should only be used to store fatal error messages.
my @error = @{ $c->error };
Add a new error.
$c->error('Something bad happened');
Contains the return value of the last executed action. Note that << $c->state >> operates in a scalar context which means that all values it returns are scalar.
Clear errors. You probably don't want to clear the errors unless you are implementing a custom error screen.
This is equivalent to running
$c->error(0);
Gets a Catalyst::Controller instance by name.
$c->controller('Foo')->do_stuff;
If the name is omitted, will return the controller for the dispatched action.
If you want to search for controllers, pass in a regexp as the argument.
# find all controllers that start with Foo my @foo_controllers = $c->controller(qr{^Foo});
Gets a Catalyst::Model instance by name.
$c->model('Foo')->do_stuff;
Any extra arguments are directly passed to ACCEPT_CONTEXT.
If the name is omitted, it will look for - a model object in $c->stash->{current_model_instance}, then - a model name in $c->stash->{current_model}, then - a config setting 'default_model', or - check if there is only one model, and return it if that's the case.
If you want to search for models, pass in a regexp as the argument.
# find all models that start with Foo my @foo_models = $c->model(qr{^Foo});
Gets a Catalyst::View instance by name.
$c->view('Foo')->do_stuff;
If the name is omitted, it will look for - a view object in $c->stash->{current_view_instance}, then - a view name in $c->stash->{current_view}, then - a config setting 'default_view', or - check if there is only one view, and return it if that's the case.
If you want to search for views, pass in a regexp as the argument.
# find all views that start with Foo my @foo_views = $c->view(qr{^Foo});
Returns the available names which can be passed to $c->controller
Returns the available names which can be passed to $c->model
Returns the available names which can be passed to $c->view
Gets a component object by name. This method is not recommended, unless you want to get a specific component by full class. $c->controller, $c->model, and $c->view should be used instead.
$c->controller
$c->model
$c->view
If $name is a regexp, a list of components matched against the full component name will be returned.
$name
If Catalyst can't find a component by name, it will fallback to regex matching by default. To disable this behaviour set disable_component_resolution_regex_fallback to a true value.
__PACKAGE__->config( disable_component_resolution_regex_fallback => 1 );
Returns or takes a hashref containing the application's configuration.
__PACKAGE__->config( { db => 'dsn:SQLite:foo.db' } );
You can also use a YAML, XML or Config::General config file like myapp.conf in your applications home directory. See Catalyst::Plugin::ConfigLoader.
YAML
XML
myapp.conf
The config method is present on all Catalyst components, and configuration will be merged when an application is started. Configuration loaded with Catalyst::Plugin::ConfigLoader takes precedence over other configuration, followed by configuration in your top level MyApp class. These two configurations are merged, and then configuration data whose hash key matches a component name is merged with configuration for that component.
MyApp
The configuration for a component is then passed to the new method when a component is constructed.
new
For example:
MyApp->config({ 'Model::Foo' => { bar => 'baz', overrides => 'me' } }); MyApp::Model::Foo->config({ quux => 'frob', overrides => 'this' });
will mean that MyApp::Model::Foo receives the following data when constructed:
MyApp::Model::Foo
MyApp::Model::Foo->new({ bar => 'baz', quux => 'frob', overrides => 'me', });
It's common practice to use a Moose attribute on the receiving component to access the config value.
package MyApp::Model::Foo; use Moose; # this attr will receive 'baz' at construction time has 'bar' => ( is => 'rw', isa => 'Str', );
You can then get the value 'baz' by calling $c->model('Foo')->bar (or $self->bar inside code in the model).
NOTE: you MUST NOT call $self->config or __PACKAGE__->config as a way of reading config within your code, as this will not give you the correctly merged config back. You MUST take the config values supplied to the constructor and use those instead.
$self->config
__PACKAGE__->config
Returns the logging object instance. Unless it is already set, Catalyst sets this up with a Catalyst::Log object. To use your own log class, set the logger with the __PACKAGE__->log method prior to calling __PACKAGE__->setup.
__PACKAGE__->log
__PACKAGE__->setup
__PACKAGE__->log( MyLogger->new ); __PACKAGE__->setup;
And later:
$c->log->info( 'Now logging with my own logger!' );
Your log class should implement the methods described in Catalyst::Log.
Returns 1 if debug mode is enabled, 0 otherwise.
You can enable debug mode in several ways:
sub debug { 1 }
The first three also set the log level to 'debug'.
Calling $c->debug(1) has no effect.
$c->debug(1)
Returns the dispatcher instance. See Catalyst::Dispatcher.
Returns the engine instance. See Catalyst::Engine.
Merges @path with $c->config->{home} and returns a Path::Class::Dir object. Note you can usually use this object as a filename, but sometimes you will have to explicitly stringify it yourself by calling the ->stringify method.
@path
$c->config->{home}
->stringify
$c->path_to( 'db', 'sqlite.db' );
Helper method for plugins. It creates a class data accessor/mutator and loads and instantiates the given class.
MyApp->plugin( 'prototype', 'HTML::Prototype' ); $c->prototype->define_javascript_functions;
Note: This method of adding plugins is deprecated. The ability to add plugins like this will be removed in a Catalyst 5.81. Please do not use this functionality in new code.
Initializes the dispatcher and engine, loads any plugins, and loads the model, view, and controller components. You may also specify an array of plugins to load here, if you choose to not load them in the use Catalyst line.
use Catalyst
MyApp->setup; MyApp->setup( qw/-Debug/ );
A hook to attach modifiers to. This method does not do anything except set the setup_finished accessor.
setup_finished
Applying method modifiers to the setup method doesn't work, because of quirky things done for plugin setup.
setup
Example:
after setup_finalize => sub { my $app = shift; ## do stuff here.. };
Constructs an absolute URI object based on the application root, the provided path, and the additional arguments and query parameters provided. When used as a string, provides a textual URI. If you need more flexibility than this (i.e. the option to provide relative URIs etc.) see Catalyst::Plugin::SmartURI.
If no arguments are provided, the URI for the current action is returned. To return the current action and also provide @args, use $c->uri_for( $c->action, @args ).
$c->uri_for( $c->action, @args )
If the first argument is a string, it is taken as a public URI path relative to $c->namespace (if it doesn't begin with a forward slash) or relative to the application root (if it does). It is then merged with $c->request->base; any @args are appended as additional path components; and any %query_values are appended as ?foo=bar parameters.
$c->request->base
@args
%query_values
?foo=bar
If the first argument is a Catalyst::Action it represents an action which will have its path resolved using $c->dispatcher->uri_for_action. The optional \@captures argument (an arrayref) allows passing the captured variables that are needed to fill in the paths of Chained and Regex actions; once the path is resolved, uri_for continues as though a path was provided, appending any arguments or parameters and creating an absolute URI.
$c->dispatcher->uri_for_action
\@captures
uri_for
The captures for the current request can be found in $c->request->captures, and actions can be resolved using Catalyst::Controller->action_for($name). If you have a private action path, use $c->uri_for_action instead.
$c->request->captures
Catalyst::Controller->action_for($name)
$c->uri_for_action
# Equivalent to $c->req->uri $c->uri_for($c->action, $c->req->captures, @{ $c->req->args }, $c->req->params); # For the Foo action in the Bar controller $c->uri_for($c->controller('Bar')->action_for('Foo')); # Path to a static resource $c->uri_for('/static/images/logo.png');
A private path to the Catalyst action you want to create a URI for.
This is a shortcut for calling $c->dispatcher->get_action_by_path($path) and passing the resulting $action and the remaining arguments to $c->uri_for.
$c->dispatcher->get_action_by_path($path)
$c->uri_for
You can also pass in a Catalyst::Action object, in which case it is passed to $c->uri_for.
Note that although the path looks like a URI that dispatches to the wanted action, it is not a URI, but an internal path to that action.
For example, if the action looks like:
package MyApp::Controller::Users; sub lst : Path('the-list') {}
You can use:
$c->uri_for_action('/users/lst')
and it will create the URI /users/the-list.
Returns the Catalyst welcome HTML page.
These methods are not meant to be used by end users.
Returns a hash of components.
Returns or sets the context class.
Returns a hashref containing coderefs and execution counts (needed for deep recursion detection).
Returns the number of actions on the current internal execution stack.
Dispatches a request to actions.
Returns or sets the dispatcher class.
Returns a list of 2-element array references (name, structure) pairs that will be dumped on the error page in debug mode.
Returns or sets the engine class.
Execute a coderef in given class and catch exceptions. Errors are available via $c->error.
Finalizes the request.
Finalizes body.
Finalizes cookies.
Finalizes error.
Finalizes headers.
An alias for finalize_body.
Finalizes the input after reading is complete.
Finalizes uploads. Cleans up any temporary files.
Gets an action in a given namespace.
Gets all actions of a given name in a namespace and all parent namespaces.
Called to handle each HTTP request.
Creates a Catalyst context from an engine-specific request (Apache, CGI, etc.).
Prepares action. See Catalyst::Dispatcher.
Prepares message body.
Prepares a chunk of data before sending it to HTTP::Body.
See Catalyst::Engine.
Prepares body parameters.
Prepares connection.
Prepares cookies.
Prepares headers.
Prepares parameters.
Prepares path and base.
Prepares query parameters.
Writes information about the request to the debug logs. This includes:
Request method, path, and remote IP address
Query keywords (see "query_keywords" in Catalyst::Request)
Request parameters
File uploads
Writes information about the response to the debug logs by calling $c->log_response_status_line and $c->log_response_headers.
$c->log_response_status_line
$c->log_response_headers
Writes one line of information about the response to the debug logs. This includes:
Response status code
Content-Type header (if present)
Content-Length header (if present)
Hook method which can be wrapped by plugins to log the responseheaders. No-op in the default implementation.
Logs request parameters to debug logs
Logs file uploads included in the request to the debug logs. The parameter name, filename, file type, and file size are all included in the debug logs.
Hook method which can be wrapped by plugins to log the request headers. No-op in the default implementation.
Logs HTTP::Headers (either request or response) to the debug logs.
Prepares the input for reading.
Prepares the engine request.
Prepares uploads.
Prepares the output for writing.
Returns or sets the request class. Defaults to Catalyst::Request.
Returns or sets the response class. Defaults to Catalyst::Response.
Reads a chunk of data from the request body. This method is designed to be used in a while loop, reading $maxlength bytes on every call. $maxlength defaults to the size of the request if not specified.
$maxlength
You have to set MyApp->config(parse_on_demand => 1) to use this directly.
MyApp->config(parse_on_demand => 1)
Warning: If you use read(), Catalyst will not process the body, so you will not be able to access POST parameters or file uploads via $c->request. You must handle all body parsing yourself.
Starts the engine.
Sets an action in a given namespace.
Sets up actions for a component.
This method is called internally to set up the application's components.
It finds modules by calling the locate_components method, expands them to package names with the expand_component_module method, and then installs each component into the application.
The setup_components config option is passed to both of the above methods.
setup_components
Installation of each component is performed by the setup_component method, below.
This method is meant to provide a list of component modules that should be setup for the application. By default, it will use Module::Pluggable.
Specify a setup_components config option to pass additional options directly to Module::Pluggable. To add additional search paths, specify a key named search_extra as an array reference. Items in the array beginning with :: will have the application class name prepended to them.
search_extra
::
Components found by locate_components will be passed to this method, which is expected to return a list of component (package) names to be set up.
locate_components
Sets up dispatcher.
Sets up engine.
Adds the following Plack middlewares to your application, since they are useful and commonly needed:
Plack::Middleware::ReverseProxy, (conditionally added based on the status of your $ENV{REMOTE_ADDR}, and can be forced on with using_frontend_proxy or forced off with ignore_frontend_proxy), Plack::Middleware::LighttpdScriptNameFix (if you are using Lighttpd), Plack::Middleware::IIS6ScriptNameFix (always applied since this middleware is smart enough to conditionally apply itself).
using_frontend_proxy
ignore_frontend_proxy
Additionally if we detect we are using Nginx, we add a bit of custom middleware to solve some problems with the way that server handles $ENV{PATH_INFO} and $ENV{SCRIPT_NAME}
Returns a PSGI application code reference for the catalyst application $c. This is the bare application without any middlewares applied. ${myapp}.psgi is not taken into account.
$c
${myapp}.psgi
This is what you want to be using to retrieve the PSGI application code reference of your Catalyst application for use in .psgi files.
Sets up the home directory.
Sets up log by instantiating a Catalyst::Log object and passing it to log(). Pass in a comma-delimited list of levels to set the log to.
log()
This method also installs a debug method that returns a true value into the catalyst subclass if the "debug" level is passed in the comma-delimited list, or if the $CATALYST_DEBUG environment variable is set to a true value.
debug
$CATALYST_DEBUG
Note that if the log has already been setup, by either a previous call to setup_log or by a call such as __PACKAGE__->log( MyLogger->new ), that this method won't actually set up the log object.
setup_log
__PACKAGE__->log( MyLogger->new )
Sets up plugins.
Sets up timing statistics class.
Returns a sorted list of the plugins which have either been stated in the import list or which have been added via MyApp->plugin(@args);.
MyApp->plugin(@args);
If passed a given plugin name, it will report a boolean value indicating whether or not that plugin is loaded. A fully qualified name is required if the plugin name does not begin with Catalyst::Plugin::.
if ($c->registered_plugins('Some::Plugin')) { ... }
Returns an arrayref of the internal execution stack (actions that are currently executing).
Returns the current timing statistics object. By default Catalyst uses Catalyst::Stats, but can be set otherwise with stats_class.
Even if -Stats is not enabled, the stats object is still available. By enabling it with $c-stats->enabled(1) >, it can be used to profile explicitly, although MyApp.pm still won't profile nor output anything by itself.
$c-
Returns or sets the stats (timing statistics) class. Catalyst::Stats is used by default.
Returns 1 when stats collection is enabled.
Note that this is a static method, not an accessor and should be overridden by declaring sub use_stats { 1 } in your MyApp.pm, not by calling $c->use_stats(1).
sub use_stats { 1 }
$c->use_stats(1)
Writes $data to the output stream. When using this method directly, you will need to manually set the Content-Length header to the length of your output data, if known.
Content-Length
Returns the Catalyst version number. Mostly useful for "powered by" messages in template systems.
There are a number of 'base' config variables which can be set:
default_model - The default model picked if you say $c->model. See "$c->model($name)".
default_model
default_view - The default view to be rendered or returned when $c->view is called. See "$c->view($name)".
default_view
disable_component_resolution_regex_fallback - Turns off the deprecated component resolution functionality so that if any of the component methods (e.g. $c->controller('Foo')) are called then regex search will not be attempted on string values and instead undef will be returned.
disable_component_resolution_regex_fallback
$c->controller('Foo')
undef
home - The application home directory. In an uninstalled application, this is the top level application directory. In an installed application, this will be the directory containing MyApp.pm.
home
MyApp.pm
ignore_frontend_proxy - See "PROXY SUPPORT"
name - The name of the application in debug messages and the debug and welcome screens
name
parse_on_demand - The request body (for example file uploads) will not be parsed until it is accessed. This allows you to (for example) check authentication (and reject the upload) before actually recieving all the data. See "ON-DEMAND PARSER"
parse_on_demand
root - The root directory for templates. Usually this is just a subdirectory of the home directory, but you can set it to change the templates to a different directory.
root
search_extra - Array reference passed to Module::Pluggable to for additional namespaces from which components will be loaded (and constructed and stored in $c->components).
$c->components
show_internal_actions - If true, causes internal actions such as _DISPATCH to be shown in hit debug tables in the test server.
show_internal_actions
_DISPATCH
use_request_uri_for_path - Controlls if the REQUEST_URI or PATH_INFO environment variable should be used for determining the request path.
use_request_uri_for_path
REQUEST_URI
PATH_INFO
Most web server environments pass the requested path to the application using environment variables, from which Catalyst has to reconstruct the request base (i.e. the top level path to / in the application, exposed as $c->request->base) and the request path below that base.
There are two methods of doing this, both of which have advantages and disadvantages. Which method is used is determined by the $c->config(use_request_uri_for_path) setting (which can either be true or false).
$c->config(use_request_uri_for_path)
This is the default (and the) traditional method that Catalyst has used for determining the path information. The path is synthesised from a combination of the PATH_INFO and SCRIPT_NAME environment variables. The allows the application to behave correctly when mod_rewrite is being used to redirect requests into the application, as these variables are adjusted by mod_rewrite to take account for the redirect.
SCRIPT_NAME
mod_rewrite
However this method has the major disadvantage that it is impossible to correctly decode some elements of the path, as RFC 3875 says: "Unlike a URI path, the PATH_INFO is not URL-encoded, and cannot contain path-segment parameters." This means PATH_INFO is always decoded, and therefore Catalyst can't distinguish / vs %2F in paths (in addition to other encoded values).
Unlike a URI path, the PATH_INFO is not URL-encoded, and cannot contain path-segment parameters.
This method uses the REQUEST_URI and SCRIPT_NAME environment variables. As REQUEST_URI is never decoded, this means that applications using this mode can correctly handle URIs including the %2F character (i.e. with AllowEncodedSlashes set to On in Apache).
AllowEncodedSlashes
On
Given that this method of path resolution is provably more correct, it is recommended that you use this unless you have a specific need to deploy your application in a non-standard environment, and you are aware of the implications of not being able to handle encoded URI paths correctly.
However it also means that in a number of cases when the app isn't installed directly at a path, but instead is having paths rewritten into it (e.g. as a .cgi/fcgi in a public_html directory, with mod_rewrite in a .htaccess file, or when SSI is used to rewrite pages into the app, or when sub-paths of the app are exposed at other URIs than that which the app is 'normally' based at with mod_rewrite), the resolution of $c->request->base will be incorrect.
using_frontend_proxy - See "PROXY SUPPORT".
Catalyst uses internal actions like _DISPATCH, _BEGIN, _AUTO, _ACTION, and _END. These are by default not shown in the private action table, but you can make them visible with a config parameter.
_BEGIN
_AUTO
_ACTION
_END
MyApp->config(show_internal_actions => 1);
The request body is usually parsed at the beginning of a request, but if you want to handle input yourself, you can enable on-demand parsing with a config parameter.
MyApp->config(parse_on_demand => 1);
Many production servers operate using the common double-server approach, with a lightweight frontend web server passing requests to a larger backend server. An application running on the backend server must deal with two problems: the remote user always appears to be 127.0.0.1 and the server's hostname will appear to be localhost regardless of the virtual host that the user connected through.
127.0.0.1
localhost
Catalyst will automatically detect this situation when you are running the frontend and backend servers on the same machine. The following changes are made to the request.
$c->req->address is set to the user's real IP address, as read from the HTTP X-Forwarded-For header. The host value for $c->req->base and $c->req->uri is set to the real host, as read from the HTTP X-Forwarded-Host header.
Additionally, you may be running your backend application on an insecure connection (port 80) while your frontend proxy is running under SSL. If there is a discrepancy in the ports, use the HTTP header X-Forwarded-Port to tell Catalyst what port the frontend listens on. This will allow all URIs to be created properly.
X-Forwarded-Port
In the case of passing in:
X-Forwarded-Port: 443
All calls to uri_for will result in an https link, as is expected.
Obviously, your web server must support these headers for this to work.
In a more complex server farm environment where you may have your frontend proxy server(s) on different machines, you will need to set a configuration option to tell Catalyst to read the proxied data from the headers.
MyApp->config(using_frontend_proxy => 1);
If you do not wish to use the proxy support at all, you may set:
MyApp->config(ignore_frontend_proxy => 1);
Catalyst has been tested under Apache 2's threading mpm_worker, mpm_winnt, and the standalone forking HTTP server on Windows. We believe the Catalyst core to be thread-safe.
mpm_worker
mpm_winnt
If you plan to operate in a threaded environment, remember that all other modules you are using must also be thread-safe. Some modules, most notably DBD::SQLite, are not thread-safe.
IRC:
Join #catalyst on irc.perl.org.
Mailing Lists:
http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst-dev
Web:
http://catalyst.perl.org
Wiki:
http://dev.catalyst.perl.org
sri: Sebastian Riedel <sri@cpan.org>
abw: Andy Wardley
acme: Leon Brocard <leon@astray.com>
abraxxa: Alexander Hartmaier <abraxxa@cpan.org>
Andrew Bramble
Andrew Ford <A.Ford@ford-mason.co.uk>
Andrew Ruthven
andyg: Andy Grundman <andy@hybridized.org>
audreyt: Audrey Tang
bricas: Brian Cassidy <bricas@cpan.org>
Caelum: Rafael Kitover <rkitover@io.com>
chansen: Christian Hansen
chicks: Christopher Hicks
Chisel Wright pause@herlpacker.co.uk
pause@herlpacker.co.uk
Danijel Milicevic me@danijel.de
me@danijel.de
David Kamholz <dkamholz@cpan.org>
David Naughton, naughton@umn.edu
naughton@umn.edu
David E. Wheeler
dhoss: Devin Austin <dhoss@cpan.org>
dkubb: Dan Kubb <dan.kubb-cpan@onautopilot.com>
Drew Taylor
dwc: Daniel Westermann-Clark <danieltwc@cpan.org>
esskar: Sascha Kiefer
fireartist: Carl Franks <cfranks@cpan.org>
frew: Arthur Axel "fREW" Schmidt <frioux@gmail.com>
gabb: Danijel Milicevic
Gary Ashton Jones
Gavin Henry ghenry@perl.me.uk
ghenry@perl.me.uk
Geoff Richards
groditi: Guillermo Roditi <groditi@gmail.com>
hobbs: Andrew Rodland <andrew@cleverdomain.org>
ilmari: Dagfinn Ilmari Mannsåker <ilmari@ilmari.org>
jcamacho: Juan Camacho
jester: Jesse Sheidlower jester@panix.com
jester@panix.com
jhannah: Jay Hannah <jay@jays.net>
Jody Belka
Johan Lindstrom
jon: Jon Schutz <jjschutz@cpan.org>
Jonathan Rockway <jrockway@cpan.org>
<jrockway@cpan.org>
Kieren Diment kd@totaldatasolution.com
kd@totaldatasolution.com
konobi: Scott McWhirter <konobi@cpan.org>
marcus: Marcus Ramberg <mramberg@cpan.org>
miyagawa: Tatsuhiko Miyagawa <miyagawa@bulknews.net>
mst: Matt S. Trout <mst@shadowcatsystems.co.uk>
mugwump: Sam Vilain
naughton: David Naughton
ningu: David Kamholz <dkamholz@cpan.org>
nothingmuch: Yuval Kogman <nothingmuch@woobling.org>
numa: Dan Sully <daniel@cpan.org>
obra: Jesse Vincent
Octavian Rasnita
omega: Andreas Marienborg
Oleg Kostyuk <cub.uanic@gmail.com>
phaylon: Robert Sedlacek <phaylon@dunkelheit.at>
rafl: Florian Ragwitz <rafl@debian.org>
random: Roland Lammel <lammel@cpan.org>
Robert Sedlacek <rs@474.at>
<rs@474.at>
SpiceMan: Marcel Montes
sky: Arthur Bergman
szbalint: Balint Szilakszi <szbalint@cpan.org>
t0m: Tomas Doran <bobtfish@bobtfish.net>
Ulf Edvinsson
Viljo Marrandi vilts@yahoo.com
vilts@yahoo.com
Will Hawes info@whawes.co.uk
info@whawes.co.uk
willert: Sebastian Willert <willert@cpan.org>
wreis: Wallace Reis <wallace@reis.org.br>
Yuval Kogman, nothingmuch@woobling.org
nothingmuch@woobling.org
rainboxx: Matthias Dietrich, perl@rainboxx.de
perl@rainboxx.de
dd070: Dhaval Dhanani <dhaval070@gmail.com>
Copyright (c) 2005, the above named PROJECT FOUNDER and CONTRIBUTORS.
This library is free software. You can redistribute it and/or modify it under the same terms as Perl itself.
1 POD Error
The following errors were encountered while parsing the POD:
Non-ASCII character seen before =encoding in 'Mannsåker'. Assuming UTF-8
To install Catalyst::Runtime, copy and paste the appropriate command in to your terminal.
cpanm
cpanm Catalyst::Runtime
CPAN shell
perl -MCPAN -e shell install Catalyst::Runtime
For more information on module installation, please visit the detailed CPAN module installation guide.