If you're writing a web application, not a framework, then you're encouraged to use one of the web application frameworks that support PSGI (http://plackperl.org/#frameworks), or see modules like HTTP::Engine to provide higher level Request and Response API on top of PSGI.

If you're looking for an easy-to-use API to convert existing CGI applications to run on PSGI, consider using CGI::PSGI or CGI::Emulate::PSGI as well. CGI::Emulate::PSGI documentation has a good summary of using them to convert existing CGI scripts to adapt to PSGI.

Returns a reference to a hash containing the cookies. Values are strings that are sent by clients and are URI decoded.

If there are multiple cookies with the same name in the request, this method will ignore the duplicates and return only the first value. If that causes issues for you, you may have to use modules like CGI::Simple::Cookie to parse $request->header('Cookie') by yourself.

Returns GET and POST parameters with a CGI.pm-compatible param method. This is an alternative method for accessing parameters in $req->parameters just in case you want the compatibility with CGI.pm objects.

You are not recommended to use this method since it is easy to misuse in a list context such as inside a hash constructor or method arguments. Use parameters and Hash::MultiValue instead.

Unlike CGI.pm, it does not allow setting or modifying query parameters.

Creates a new Plack::Response object. Handy to remove dependency on Plack::Response in your code for easy subclassing and duck typing in web application frameworks, as well as overriding Response generation in middlewares.

Parameters that can take one or multiple values (i.e. parameters, query_parameters, body_parameters and uploads) store the hash reference as a Hash::MultiValue object. This means you can use the hash reference as a plain hash where values are always scalars (NOT array references), so you don't need to code ugly and unsafe ref ... eq 'ARRAY' anymore.

And if you explicitly want to get multiple values of the same key, you can call the get_all method on it, such as:

my @foo = $req->query_parameters->get_all('foo');

You can also call get_one to always get one parameter independent of the context (unlike param), and even call mixed (with Hash::MultiValue 0.05 or later) to get the traditional hash reference,

my $params = $req->parameters->mixed;

where values are either a scalar or an array reference depending on input, so it might be useful if you already have the code to deal with that ugliness.

The methods to parse request body (content, body_parameters and uploads) are carefully coded to save the parsed body in the environment hash as well as in the temporary buffer, so you can call them multiple times and create Plack::Request objects multiple times in a request and they should work safely, and won't parse request body more than twice for the efficiency.

If your application or framework wants to dispatch (or route) actions based on request paths, be sure to use $req->path_info not $req->uri->path.

This is because path_info gives you the virtual path of the request, regardless of how your application is mounted. If your application is hosted with mod_perl or CGI scripts, or even multiplexed with tools like Plack::App::URLMap, request's path_info always gives you the action path.

Note that path_info might give you an empty string, in which case you should assume that the path is /.

You will also want to use $req->base as a base prefix when building URLs in your templates or in redirections. It's a good idea for you to subclass Plack::Request and define methods such as:

In version 0.99, many utility methods are removed or deprecated, and most methods are made read-only. These methods were deleted in version 1.0001.

All parameter-related methods such as parameters, body_parameters, query_parameters and uploads now contains Hash::MultiValue objects, rather than scalar or an array reference depending on the user input which is insecure. See Hash::MultiValue for more about this change.

$req->path method had a bug, where the code and the document was mismatching. The document was suggesting it returns the sub request path after $req->base but the code was always returning the absolute URI path. The code is now updated to be an alias of $req->path_info but returns / in case it's empty. If you need the older behavior, just call $req->uri->path instead.

Cookie handling is simplified, and doesn't use CGI::Simple::Cookie anymore, which means you CAN NOT set array reference or hash reference as a cookie value and expect it be serialized. You're always required to set string value, and encoding or decoding them is totally up to your application or framework. Also, cookies hash reference now returns strings for the cookies rather than CGI::Simple::Cookie objects, which means you no longer have to write a wacky code such as: