Cataly...sponse(3pm)

Cataly...sponse(3pm) 💅

okay bestie, this is the manual page for Catalyst::Response (the perl doc version, sitting in User Contributed Perl Documentation) and honestly? she's a baddie. let's get into it 🫶

---

✨ NAME ✨

Catalyst::Response — she stores the output responding to the current client request. that's the whole vibe. 💖

---

✨ 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;

like, that's the roster. iconic lineup fr fr 🌸

---

✨ DESCRIPTION ✨

so this is the Catalyst Response class, and she's the one providing all the methods for responding to the current client request. the appropriate Catalyst::Engine for your environment will turn this Catalyst::Response into an actual HTTP Response and hand it back to the client. no cap, that's literally her whole job and she ate. 👑

---

✨ METHODS ✨

$res->body( $text | $fh | $iohandle_object )

$c->response->body('Catalyst rocks!');

sets or returns the output — text or binary data, she doesn't discriminate 💅

now if you're returning a large body, you might wanna use an IO::Handle type of object (something that implements the getline method in the same fashion), or a filehandle GLOB. these get passed down to the PSGI handler you're using and might get optimized using server specific abilities — for example Twiggy will attempt to serve a real local file in a non blocking manner. fancy. ✨

bestie listen: if you're using a filehandle as the body response, you are responsible for making sure it conforms to the PSGI specification with regards to content encoding. unlike with scalar body values or when using the streaming interfaces, we currently do not attempt to normalize and encode your filehandle. in general this means you should be sure to be sending bytes, not UTF8 decoded multibyte characters. 😭

most of the time when you do:

open(my $fh, '<:raw', $path);

you should be fine. but if you open a filehandle with a PerlIO layer, you probably are not fine. you can usually fix this by explicitly using binmode to set the IOLayer to :raw. it's possible future versions of Catalyst will try to 'do the right thing'. 🙈

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. 💖

pls note: the object needs to implement getline, not just read. older versions of Catalyst expected your filehandle like objects to do read. if you have code written for this expectation and you cannot change the code to meet the PSGI specification, you can try the following middleware Plack::Middleware::AdaptFilehandleRead which will attempt to wrap your object in an interface that so conforms. 🧚

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 bestie ⚠️ 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. that's giving security breach, we do not stan. 💀

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 serve 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. bye bestie 👋

for Apache and Lighttpd, the mapping doesn't apply and setting the X-Sendfile-Type is enough. periodt.

---

$res->has_body

predicate which returns true when a body has been set. vibe check: passed? ✅

---

$res->code

alias for $res->status. same girl, different name 💅

---

$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. she's a guesser but a good one 🦋

---

$res->content_type_charset

shortcut for $res->headers->content_type_charset;

---

$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

cookies on cookies on cookies 🍓

---

$res->header

shortcut for $res->headers->header.

---

$res->headers

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. don't forget or it's just gonna keep going 😭

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. 🧚

note: if $url is an object that does ->as_string (such as URI, which is what you get from ->uri_for) we automatically call that to stringify. this should ease the common case usage

return $c->res->redirect( $c->uri_for(...));

---

$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. calling this method will finalize your headers and send the headers and status code response to the client (so changing them afterwards is a waste... be sure to set your headers correctly first, bestie 🫶).

you may call this as often as you want throughout your response cycle. you may even set a 'body' afterward. so for example you might write your HTTP headers and the HEAD section of your document and then set the body from a template driven from a database. in some cases this can seem to the client as if you had a faster overall response (but note that unless your server support chunked body your content is likely to get queued anyway — Starman and most other http 1.1 webservers support this). ✨

if there is an encoding set, we encode each line of the response (the default encoding is UTF-8).

---

$res->unencoded_write( $data )

works just like ->write but we don't apply any content encoding to $data. use this if you are already encoding the $data or the data is arriving from an encoded storage. iykyk 💅

---

$res->write_fh

returns an instance of Catalyst::Response::Writer, which is a lightweight decorator over the PSGI $writer object (see PSGI.pod\Delayed-Response-and-Streaming-Body).

in addition to proxying the write and close method from the underlying PSGI writer, this proxy object knows any application wide encoding, and provides a method write_encoded that will properly encode your written lines based upon your encoding settings. by default in Catalyst responses are UTF-8 encoded and this is the encoding used if you respond via write_encoded. if you want to handle encoding yourself, you can use the write method directly.

encoding only applies to content types for which it matters. currently the following content types are assumed to need encoding: text (including HTML), xml and javascript.

we provide access to this object so that you can properly close over it for use in 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 }); }

Like the `'write'` method, calling this will finalize headers. But unlike `'write'`, when you call this one it's assumed you're taking full control of the response, so the body is **never** finalized (there isn't one anyway) and you need to call the close method yourself. 💅

---

### ✨ `$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`. So go ahead and yeet your response object into anything that expects an `IO::Handle`, bestie. 🫶

### ✨ `$res->finalize_headers()` ✨

Writes headers to response if not already written. One and done, no double-dipping. ✨

### 🌈 `from_psgi_response` 🌈

Given a PSGI response (either three element `ARRAY` reference **OR** coderef expecting a `$responder`) set the response from it. Okay so you hand it that PSGI thing and it just… sets the response. Iconic.

Properly supports streaming and delayed response and / or async IO if running under an expected event loop. No cap.

If passed an object, will expect that object to do a method `"as_psgi"`. Periodt.

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)); }

sub streaming_body :Local { my ($self, $c) = @_; my $psgi_app = sub { my $respond = shift; my $writer = $respond->([200,["Content-Type" => "text/plain"]]); $writer->write("body"); $writer->close; }; $c->res->from_psgi_response($psgi_app); }

Please note this does **not** attempt to map or nest your PSGI application under the Controller and Action namespace or path. You may wish to review `'PSGI Helpers'` under `Catalyst::Utils` for help in properly nesting applications. Just saying. 💅

> **NOTE** If your external PSGI application returns a response that has a character set associated with the content type (such as `"text/html; charset=UTF-8"`) we set `$c->clear_encoding` to remove any additional content type encoding processing later in the application (this is done to avoid double encoding issues).

> **NOTE** If your external PSGI application is streaming, we assume you completely handle the entire jobs (including closing the stream). This will also bypass the output finalization methods on Catalyst (such as `'finalize_body'` which gets called but then skipped when it finds that output is already finished.) It's possible this might cause issue with some plugins that want to do `'things'` during those finalization methods. Just understand what is happening.

### 🎀 `encodable_content_type` 🎀

This is a regular expression used to determine of the current content type should be considered encodable. Currently we apply default encoding (usually `UTF8`) to text type contents. Here's the default regular expression:

This would match content types like:

text/plain text/html text/xml application/javascript application/xml application/vnd.user+xml

> **NOTE:** We don't encode JSON content type responses by default since most of the JSON serializers that are commonly used for this task will do so automatically and we don't want to double encode. If you are not using a tool like JSON to produce JSON type content, (for example you are using a template system, or creating the strings manually) you will need to either encoding the body yourself:

$c->response->body( $c->encoding->encode( $body, $c->_encode_check ) );

Or you can alter the regular expression using this attribute. Easy peasy. 💅

### 🌸 `encodable_response` 🌸

Given a `Catalyst::Response` return true if its one that can be encoded.

- make sure there is an encoding set on the response
- make sure the content type is encodable
- make sure no content type charset has been already set to something different from the global encoding
- make sure no content encoding is present.

Note this does not inspect a body since we do allow automatic encoding on streaming type responses. K? 💖

### 💀 `DEMOLISH` 💀

Ensures that the response is flushed and closed at the end of the request. Cleanup crew, assemble. 🧹✨

### 🦋 `meta` 🦋

Provided by `Moose`. That's it. 💅

---

# 👑 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. Periodt.

---

Okay bestie, that's the whole page! This was `Cataly...sponse(3pm)` from `perl v5.40.0`, dated `2024-11-15`. Mwah! 💋