---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/24449/#review50033
---
/trunk/java/common/src/test/java/org/apache/shindig/protocol/JsonRpcServletTest.java
https://reviews.apache.org/r/24449/#comment87538
Instead of changing the behavior of the existing tests, can you add an
additional test for using the default encoding? I want to ensure the old
behavior stands when DiskFileItem.getCharSet() != null
- Stanton Sievers
On Aug. 7, 2014, 1:48 p.m., Andreas Kohn wrote:
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/24449/
---
(Updated Aug. 7, 2014, 1:48 p.m.)
Review request for shindig.
Bugs: SHINDIG-1981
https://issues.apache.org/jira/browse/SHINDIG-1981
Repository: shindig
Description
---
When using RPC requests with multipart/form-data encoding (due to file
uploads) the request content is currently assumed to either have an explicit
Content-Type with a 'charset' parameter set, or be encoded in ISO-8859-1.
With HTML 5 this breaks:
1. non-file items must not have any content-type header, and
2. the encoding should come from the encoding of the form (accept-charset),
and
3. if that is not known the default is _UTF-8_.
The attached patch changes the behavior of JsonRpcServlet and the
CommonsFormDataItem to handle this case:
1. JsonRpcServlet provides the request encoding when getting the content of a
non-file item as string, and
2. CommonsFormDataItem uses that encoding unless there is an explicit
encoding known for that specific item
Diffs
-
/trunk/java/common/src/main/java/org/apache/shindig/protocol/JsonRpcServlet.java
1616468
/trunk/java/common/src/main/java/org/apache/shindig/protocol/multipart/CommonsFormDataItem.java
1616468
/trunk/java/common/src/main/java/org/apache/shindig/protocol/multipart/FormDataItem.java
1616468
/trunk/java/common/src/test/java/org/apache/shindig/protocol/JsonRpcServletTest.java
1616468
Diff: https://reviews.apache.org/r/24449/diff/
Testing
---
Used in our application with uses RPC with multipart/form-data encoding and
non-ASCII characters in the 'request' content.
Tested with Firefox nightly on Linux, other browser tests are still ongoing.
Thanks,
Andreas Kohn
