view release on metacpan or  search on metacpan

lib/Catalyst/Response.pm  view on Meta::CPAN

    # Finalize headers if someone manually writes output
    $self->_context->finalize_headers unless $self->finalized_headers;

    $buffer = q[] unless defined $buffer;

    my $len = length($buffer);
    $self->_writer->write($buffer);

    return $len;
}

sub finalize_headers {
    my ($self) = @_;
    return;
}

sub from_psgi_response {
    my ($self, $psgi_res) = @_;
    if(blessed($psgi_res) && $psgi_res->can('as_psgi')) {
      $psgi_res = $psgi_res->as_psgi;
    }
    if(ref $psgi_res eq 'ARRAY') {
        my ($status, $headers, $body) = @$psgi_res;
        $self->status($status);
        $self->headers(HTTP::Headers->new(@$headers));
        # Can be arrayref or filehandle...
        if(defined $body) { # probably paranoia
          ref $body eq 'ARRAY' ? $self->body(join('', @$body)) : $self->body($body);
        }
    } elsif(ref $psgi_res eq 'CODE') {

        # Its not clear to me this is correct.  Right now if the PSGI application wants
        # to stream, we stream immediately and then completely bypass the rest of the
        # Catalyst finalization process (unlike if the PSGI app sets an arrayref).  Part of
        # me thinks we should override the current _response_cb and then let finalize_body
        # call that.  I'm not sure the downside of bypassing those bits.  I'm going to leave
        # this be for now and document the behavior.

        $psgi_res->(sub {
            my $response = shift;
            my ($status, $headers, $maybe_body) = @$response;
            $self->status($status);
            $self->headers(HTTP::Headers->new(@$headers));
            if(defined $maybe_body) {
                # Can be arrayref or filehandle...
                ref $maybe_body eq 'ARRAY' ? $self->body(join('', @$maybe_body)) : $self->body($maybe_body);
            } else {
                return $self->write_fh;
            }
        });
     } 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

lib/Catalyst/Response.pm  view on Meta::CPAN

In addition to proxying the C<write> and C<close> method from the underlying PSGI
writer, this proxy object knows any application wide encoding, and provides a method
C<write_encoded> that will properly encode your written lines based upon your
encoding settings.  By default in L<Catalyst> responses are UTF-8 encoded and this
is the encoding used if you respond via C<write_encoded>.  If you want to handle
encoding yourself, you can use the C<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 L<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. Unlike 'write' when you
can this it is assumed you are taking control of the response so the body is never
finalized (there isn't one anyway) and you need to call the close method.

=head2 $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 L<IO::Handle>.

=head2 $res->finalize_headers()

Writes headers to response if not already written

=head2 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.

If passed an object, will expect that object to do a method C<as_psgi>.

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 L<Catalyst::Utils> for help in properly nesting applications.

B<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).

B<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.)  Its possible
this might cause issue with some plugins that want to do 'things' during those
finalization methods.  Just understand what is happening.

=head2 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

B<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 L<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.

=head2 encodable_response

Given a L<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.

=cut

sub encodable_response {
  my ($self) = @_;
  return 0 unless $self->_context; # Cases like returning a HTTP Exception response you don't have a context here...
  return 0 unless $self->_context->encoding;

  # The response is considered to have a 'manual charset' when a charset is already set on
  # the content type of the response AND it is not the same as the one we set in encoding.
  # If there is no charset OR we are asking for the one which is the same as the current
  # required encoding, that is a flag that we want Catalyst to encode the response automatically.
  my $has_manual_charset = 0;
  if(my $charset = $self->content_type_charset) {
    $has_manual_charset = (uc($charset) ne uc($self->_context->encoding->mime_name)) ? 1:0;
  }

  # Content type is encodable if it matches the regular expression stored in this attribute
  my $encodable_content_type = $self->content_type =~ m/${\$self->encodable_content_type}/ ? 1:0;

  # The content encoding is allowed (for charset encoding) only if its empty or is set to identity
  my $allowed_content_encoding = (!$self->content_encoding || $self->content_encoding eq 'identity') ? 1:0;

  # The content type must be an encodable type, and there must be NO manual charset and also
  # the content encoding must be the allowed values;
  if(
      $encodable_content_type and
      !$has_manual_charset and
      $allowed_content_encoding
  ) {
    return 1;
  } else {
    return 0;
  }
}

=head2 DEMOLISH

Ensures that the response is flushed and closed at the end of the
request.

=head2 meta

Provided by Moose

=cut

sub print {
    my $self = shift;
    my $data = shift;

    defined $self->write($data) or return;

    for (@_) {
        defined $self->write($,) or return;
        defined $self->write($_) or return;
    }
    defined $self->write($\) or return;