When from_psgi_response, a bug when headers are already output and charset is set...

[catagits/Catalyst-Runtime.git] / lib / Catalyst / Response.pm

diff --git a/lib/Catalyst/Response.pm b/lib/Catalyst/Response.pm
index 94ee3f3..a9277b5 100644 (file)
--- a/lib/Catalyst/Response.pm
+++ b/lib/Catalyst/Response.pm
@@ -3,11 +3,12 @@ package Catalyst::Response;
 use Moose;
 use HTTP::Headers;
 use Moose::Util::TypeConstraints;
-use namespace::autoclean;
 use Scalar::Util 'blessed';
 use Catalyst::Response::Writer;
 use Catalyst::Utils ();
 
+use namespace::clean -except => ['meta'];
+
 with 'MooseX::Emulate::Class::Accessor::Fast';
 
 our $DEFAULT_ENCODE_CONTENT_TYPE_MATCH = qr{text|xml$|javascript$};
@@ -20,7 +21,7 @@ has encodable_content_type => (
 
 has _response_cb => (
     is      => 'ro',
-    isa     => 'CodeRef', 
+    isa     => 'CodeRef',
     writer  => '_set_response_cb',
     clearer => '_clear_response_cb',
     predicate => '_has_response_cb',
@@ -190,11 +191,13 @@ sub from_psgi_response {
             } else {
                 return $self->write_fh;
             }
-        });  
+        });
      } else {
         die "You can't set a Catalyst response from that, expect a valid PSGI response";
     }
 
+    return if $self->finalized_headers;
+
     # 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.
@@ -238,7 +241,7 @@ will turn the Catalyst::Response into a HTTP Response and return it to the clien
     $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 
+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).
@@ -263,7 +266,7 @@ 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, 
+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.
 
@@ -488,7 +491,7 @@ 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 (L<Starman> and most other 
+body your content is likely to get queued anyway (L<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
@@ -556,7 +559,7 @@ finalized (there isn't one anyway) and you need to call the close method.
 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 $self->finalize_headers($c)
+=head2 $res->finalize_headers()
 
 Writes headers to response if not already written
 
@@ -623,7 +626,7 @@ 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.  
+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