[Jifty-commit] r4353 - jifty/trunk/lib/Jifty

[jifty-commit at lists.jifty.org]

Author: audreyt
Date: Thu Nov  1 13:13:52 2007
New Revision: 4353

Modified:
   jifty/trunk/lib/Jifty/I18N.pm

Log:
* Jifty::I18N::promote_encoding - r4286 by yours truly broke 
  auto-decoding for POST requests.
  
  This is a better fix to avoid the "Unquoted / not allowed in
  Content-Type" warning (which arugably is a Email::MIME::ContentType
  glitch), by scanning the Content-Type header for the substring
  "charset" before parsing it.

  This way, when "charset" is not found in that header,
  we still fallback to Encode::Guess, regardless of whether
  the request was of type "multipart/form-data".

Modified: jifty/trunk/lib/Jifty/I18N.pm
==============================================================================
--- jifty/trunk/lib/Jifty/I18N.pm	(original)
+++ jifty/trunk/lib/Jifty/I18N.pm	Thu Nov  1 13:13:52 2007
@@ -230,12 +230,10 @@
     my $content_type = shift;
     my $charset;
 
-    if ($content_type) {
-        # Multi-part form data have no notion of charsets, so we return the string
-        # verbatim here, to avoid the "Unquoted / not allowed in Content-Type"
-        # warnings when the Base64-encoded MIME boundary string contains "/".
-        return $string if $content_type =~ /^multipart\b/;
-
+    # Don't bother parsing the Content-Type header unless it mentions "charset".
+    # This is to avoid the "Unquoted / not allowed in Content-Type" warnings when
+    # the Base64-encoded MIME boundary string contains "/".
+    if ($content_type and $content_type =~ /charset/i) {
         $content_type = Email::MIME::ContentType::parse_content_type($content_type);
         $charset = $content_type->{attributes}->{charset};
     }