decoded results from the CPAN

Catalyst-Runtime
     } else {
        die "You can't set a Catalyst response from that, expect a valid PSGI response";
    }

    # Encoding compatibilty.   If the response set a charset, well... we need
    # to assume its properly encoded and NOT encode for this response.  Otherwise
    # We risk double encoding.

    # We check first to make sure headers have not been finalized.  Headers might be finalized
    # in the case where a PSGI response is streaming and the PSGI application already wrote
    # to the output stream and close the filehandle.
    if(!$self->finalized_headers && $self->content_type_charset) {
      # We have to do this since for backcompat reasons having a charset doesn't always
      # mean that the body is already encoded :(
      $self->_context->clear_encoding;
    }
}

=head1 NAME

Catalyst::Response - stores output responding to the current client request

=head1 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;

=head1 DESCRIPTION

This is the Catalyst Response class, which provides methods for responding to
the current client request. The appropriate L<Catalyst::Engine> for your environment
will turn the Catalyst::Response into a HTTP Response and return it to the client.

=head1 METHODS

=head2 $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 L<IO::Handle> type of object (Something that implements the getline method
in the same fashion), or a filehandle GLOB. These will be passed down to the PSGI
handler you are using and might be optimized using server specific abilities (for
example L<Twiggy> will attempt to server a real local file in a non blocking manner).

If you are using a filehandle as the body response you are responsible for
making sure it conforms to the L<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.  If you open a filehandle with a L<PerlIO> layer you probably
are not fine.  You can usually fix this by explicitly using binmode to set
the IOLayer to :raw.  Its possible future versions of L<Catalyst> will try to
'do the right thing'.

When using a L<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 C<getline>, not just
C<read>.  Older versions of L<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 L<PSGI> specification, you can try the following
middleware L<Plack::Middleware::AdaptFilehandleRead> which will attempt to
wrap your object in an interface that so conforms.

Starting from version 5.90060, when using an L<IO::Handle> object, you
may want to use L<Plack::Middleware::XSendfile>, to delegate the
actual serving to the frontend server. To do so, you need to pass to
C<body> an IO object with a C<path> method. This can be achieved in
two ways.

Either using L<Plack::Util>:

  my $fh = IO::File->new($file, 'r');
  Plack::Util::set_io_path($fh, $file);

Or using L<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]);

L<Plack::Middleware::XSendfile> can be loaded in the application so:

 __PACKAGE__->config(
     psgi_middleware => [
         'XSendfile',
         # other middlewares here...
        ],
 );

B<Beware> that loading the middleware without configuring the
webserver to set the request header C<X-Sendfile-Type> to a supported
type (C<X-Accel-Redirect> for nginx, C<X-Sendfile> for Apache and
( run in 0.835 second using v1.01-cache-2.11-cpan-e1769b4cff6 )