NAME¶
Catalyst::Response - stores output responding to the current client request
SYNOPSIS¶
$res = $c->response;
$res->body;
$res->code;
$res->content_encoding;
$res->content_length;
$res->content_type;
$res->cookies;
$res->header;
$res->headers;
$res->output;
$res->redirect;
$res->status;
$res->write;
DESCRIPTION¶
This is the Catalyst Response class, which provides methods for responding to
the current client request. The appropriate Catalyst::Engine for your
environment will turn the Catalyst::Response into a HTTP Response and return
it to the client.
METHODS¶
$res->body( $text | $fh | $iohandle_object )¶
$c->response->body('Catalyst rocks!');
Sets or returns the output (text or binary data). If you are returning a large
body, you might want to use a IO::Handle type of object (Something that
implements the read method in the same fashion), or a filehandle GLOB.
Catalyst will write it piece by piece into the response.
When using a IO::Handle type of object and no content length has been already
set in the response headers Catalyst will make a reasonable attempt to
determine the size of the Handle. Depending on the implementation of your
handle object, setting the content length may fail. If it is at all possible
for you to determine the content length of your handle object, it is
recommended that you set the content length in the response headers yourself,
which will be respected and sent by Catalyst in the response.
Please note that the object needs to implement "getline", not just
"read".
Starting from version 5.90060, when using an IO::Handle object, you may want to
use Plack::Middleware::XSendfile, to delegate the actual serving to the
frontend server. To do so, you need to pass to "body" an IO object
with a "path" method. This can be achieved in two ways.
Either using Plack::Util:
my $fh = IO::File->new($file, 'r');
Plack::Util::set_io_path($fh, $file);
Or using IO::File::WithPath
my $fh = IO::File::WithPath->new($file, 'r');
And then passing the filehandle to body and setting headers, if needed.
$c->response->body($fh);
$c->response->headers->content_type('text/plain');
$c->response->headers->content_length(-s $file);
$c->response->headers->last_modified((stat($file))[9]);
Plack::Middleware::XSendfile can be loaded in the application so:
__PACKAGE__->config(
psgi_middleware => [
'XSendfile',
# other middlewares here...
],
);
Beware that loading the middleware without configuring the webserver to
set the request header "X-Sendfile-Type" to a supported type
("X-Accel-Redirect" for nginx, "X-Sendfile" for Apache and
Lighttpd), could lead to the disclosure of private paths to malicious clients
setting that header.
Nginx needs the additional X-Accel-Mapping header to be set in the webserver
configuration, so the middleware will replace the absolute path of the IO
object with the internal nginx path. This is also useful to prevent a buggy
app to server random files from the filesystem, as it's an internal redirect.
An nginx configuration for FastCGI could look so:
server {
server_name example.com;
root /my/app/root;
location /private/repo/ {
internal;
alias /my/app/repo/;
}
location /private/staging/ {
internal;
alias /my/app/staging/;
}
location @proxy {
include /etc/nginx/fastcgi_params;
fastcgi_param SCRIPT_NAME '';
fastcgi_param PATH_INFO $fastcgi_script_name;
fastcgi_param HTTP_X_SENDFILE_TYPE X-Accel-Redirect;
fastcgi_param HTTP_X_ACCEL_MAPPING /my/app=/private;
fastcgi_pass unix:/my/app/run/app.sock;
}
}
In the example above, passing filehandles with a local path matching
/my/app/staging or /my/app/repo will be served by nginx. Passing paths with
other locations will lead to an internal server error.
Setting the body to a filehandle without the "path" method bypasses
the middleware completely.
For Apache and Lighttpd, the mapping doesn't apply and setting the
X-Sendfile-Type is enough.
$res->has_body¶
Predicate which returns true when a body has been set.
$res->code¶
Alias for $res->status.
$res->content_encoding¶
Shortcut for $res->headers->content_encoding.
$res->content_length¶
Shortcut for $res->headers->content_length.
$res->content_type¶
Shortcut for $res->headers->content_type.
This value is typically set by your view or plugin. For example,
Catalyst::Plugin::Static::Simple will guess the mime type based on the file it
found, while Catalyst::View::TT defaults to "text/html".
$res->cookies¶
Returns a reference to a hash containing cookies to be set. The keys of the hash
are the cookies' names, and their corresponding values are hash references
used to construct a CGI::Simple::Cookie object.
$c->response->cookies->{foo} = { value => '123' };
The keys of the hash reference on the right correspond to the
CGI::Simple::Cookie parameters of the same name, except they are used without
a leading dash. Possible parameters are:
- value
- expires
- domain
- path
- secure
- httponly
Shortcut for $res->headers->header.
Returns an HTTP::Headers object, which can be used to set headers.
$c->response->headers->header( 'X-Catalyst' => $Catalyst::VERSION );
$res->output¶
Alias for $res->body.
$res->redirect( $url, $status )¶
Causes the response to redirect to the specified URL. The default status is 302.
$c->response->redirect( 'http://slashdot.org' );
$c->response->redirect( 'http://slashdot.org', 307 );
This is a convenience method that sets the Location header to the redirect
destination, and then sets the response status. You will want to " return
" or "$c->detach()" to interrupt the normal processing flow
if you want the redirect to occur straight away.
Note: do not give a relative URL as $url, i.e: one that is not fully
qualified (= "
http://...", etc.) or that starts with a slash (=
"/path/here"). While it may work, it is not guaranteed to do the
right thing and is not a standard behaviour. You may opt to use
uri_for() or
uri_for_action() instead.
$res->location¶
Sets or returns the HTTP 'Location'.
$res->status¶
Sets or returns the HTTP status.
$c->response->status(404);
$res->code is an alias for this, to match HTTP::Response->code.
$res->write( $data )¶
Writes $data to the output stream.
$res->write_fh¶
Returns a PSGI $writer object that has two methods, write and close. You can
close over this object for asynchronous and nonblocking applications. For
example (assuming you are using a supporting server, like Twiggy
package AsyncExample::Controller::Root;
use Moose;
BEGIN { extends 'Catalyst::Controller' }
sub prepare_cb {
my $write_fh = pop;
return sub {
my $message = shift;
$write_fh->write("Finishing: $message\n");
$write_fh->close;
};
}
sub anyevent :Local :Args(0) {
my ($self, $c) = @_;
my $cb = $self->prepare_cb($c->res->write_fh);
my $watcher;
$watcher = AnyEvent->timer(
after => 5,
cb => sub {
$cb->(scalar localtime);
undef $watcher; # cancel circular-ref
});
}
$res->print( @data )¶
Prints @data to the output stream, separated by $,. This lets you pass the
response object to functions that want to write to an IO::Handle.
Writes headers to response if not already written
from_psgi_response¶
Given a PSGI response (either three element ARRAY reference OR coderef expecting
a $responder) set the response from it.
Properly supports streaming and delayed response and / or async IO if running
under an expected event loop.
Example:
package MyApp::Web::Controller::Test;
use base 'Catalyst::Controller';
use Plack::App::Directory;
my $app = Plack::App::Directory->new({ root => "/path/to/htdocs" })
->to_app;
sub myaction :Local Args {
my ($self, $c) = @_;
$c->res->from_psgi_response($app->($c->req->env));
}
Please note this does not attempt to map or nest your PSGI application under the
Controller and Action namespace or path.
DEMOLISH¶
Ensures that the response is flushed and closed at the end of the request.
Provided by Moose
AUTHORS¶
Catalyst Contributors, see Catalyst.pm
COPYRIGHT¶
This library is free software. You can redistribute it and/or modify it under
the same terms as Perl itself.
