updated the encoding pod a bit 5.90094
John Napiorkowski [Fri, 24 Jul 2015 20:09:35 +0000 (15:09 -0500)]
lib/Catalyst/Delta.pod
lib/Catalyst/UTF8.pod

index 1366f09..a47c884 100755 (executable)
@@ -7,6 +7,20 @@ Catalyst::Delta - Overview of changes between versions of Catalyst
 This is an overview of the user-visible changes to Catalyst between major
 Catalyst releases.
 
+=head2 VERSION 5.90094
+
+=head3 Multipart form POST with character set headers
+
+When we did the UTF8 work, we punted on Form POSTs when the POST envelope was
+multipart and each part had complex headers such as content-types, character
+sets and so forth.  In those cases instead of returning a possibly incorrect
+value, we returned an object describing the part so that you could figure it
+out manually.  This turned out to be a bad workaround as people did not expect
+to find that object.  So we changed this to try much harder to get a correct
+value.  We still return an object if we fail but we try much harder now.  If
+you used to check for the object you might find that code is no longer needed
+(although checking for it should not hurt or break anything either).
+
 =head2 VERSION 5.90091
 
 =head3 'case_sensitive' configuration
index 40ba088..d8bce96 100644 (file)
@@ -307,10 +307,16 @@ In this case we've created a POST request but each part specifies its own conten
 character set (and setting a content encoding would also be possible).  Generally one
 would not run into this situation in a web browser context but for completeness sake
 Catalyst will notice if a multipart POST contains parts with complex or extended
-header information and in those cases it will not attempt to apply decoding to the
-form values.  Instead the part will be represented as an instance of an object
-L<Catalyst::Request::PartData> which will contain all the header information needed
-for you to perform custom parser of the data.
+header information.  In these cases we will try to inspect the meta data and do the
+right thing (in the above case we'd use SHIFT_JIS to decode, not UTF-8).  However if
+after inspecting the headers we cannot figure out how to decode the data, in those cases it
+will not attempt to apply decoding to the form values.  Instead the part will be represented as
+an instance of an object L<Catalyst::Request::PartData> which will contain all the header 
+information needed for you to perform custom parser of the data.
+
+Ideally we'd fix L<Catalyst> to be smarter about decoding so please submit your cases of
+this so we can add inteligence to the parser and find a way to extract a valid value out
+of it.
 
 =head1 UTF8 Encoding in Body Response