Details
-
Type:
Bug
-
Status:
Closed
-
Priority:
Major
-
Resolution: Fixed
-
Affects Version/s: 3.0.0-M4
-
Fix Version/s: 3.1.0
-
Component/s: Transport: HTTP(S) / Jetty
-
Labels:None
-
Environment:
WindowsXP SP3, Sun JDK 1.6.0_14
-
User impact:Medium
-
Similar Issues:None
Description
Hi.
At first, please check out MULE-4911.
I found a one more problem in HttpRequestBodyToParamMap class.
HttpRequestBodyToParamMap uses java.net.URLDecoder.
But when multibytes string is used, URLDecoder sometimes can't decode query string which encoded by URLCodec.
For example, Japanese Hiragana characher "\u30a8" is encoded to...
=> "%83%47" (by URLEncoder)
=> "%83G" (by URLCodec)
===== sample code =====
import java.net.URLDecoder;
import java.net.URLEncoder;
import org.apache.commons.codec.net.URLCodec;
import org.junit.Assert;
import org.junit.Test;
public class URLDecoderTest {
private static final String encoding = "Windows-31J";
private static final String value = "\u30a8"; // a Japanese hiragana character ![]()
@Test
public void testDecode() throws Exception {
System.out.println(URLEncoder.encode(value, encoding));
System.out.println(new URLCodec().encode(value, encoding));
Assert.assertEquals(value, URLDecoder.decode(new URLCodec().encode(value, encoding), encoding));
}
}
===== sample code =====
And according to RFC3986 (Sec 2.3)...
> For consistency, percent-encoded octets in the ranges of ALPHA
> (%41-%5A and %61-%7A), DIGIT (%30-%39), hyphen (%2D), period (%2E),
> underscore (%5F), or tilde (%7E) should not be created by URI
> producers
In the case of "\u30a8", "%83G"(by URLCodec) is preferred result. (correct?)
But URLDecoder can't decode "%83G" to "\u30a8". and URLCodec#decode() can.
So I think that URLCodec#docode() should be used here instead of URLDecoder.
Here is a patch for this problem and functional tests.
(this patch includes all the content of the patch for MULE-4911)
best regards.
Activity
| Field | Original Value | New Value |
|---|---|---|
| Attachment | URLDecoder.patch [ 12808 ] |
| Attachment | NEW-URLDecoder.patch [ 12810 ] |
| Affects Version/s | 3.0.0-M4 [ 10832 ] | |
| Affects Version/s | 3.x [ 10674 ] |
| Assignee | Dirk Olmes [ dirk ] |
| Link | This issue relates to BL-131 [ BL-131 ] |
| Priority | To be reviewed [ 6 ] | Major [ 3 ] |
| Status | Open [ 1 ] | In Progress [ 3 ] |
| Status | In Progress [ 3 ] | Closed [ 6 ] |
| Fix Version/s | 3.1.0 [ 10898 ] | |
| Resolution | Fixed [ 1 ] |
| Transition | Time In Source Status | Execution Times | Last Executer | Last Execution Date | |||||
|---|---|---|---|---|---|---|---|---|---|
|
114d 21h 47m | 1 | Dirk Olmes | 10/Oct/10 10:58 PM | |||||
|
38d 10h 58m | 1 | Dirk Olmes | 18/Nov/10 08:57 AM |
- Repository mule on http://foo.bar/ failed: Error in remote call to 'FishEye 0 (http://foo.bar/)' (http://foo.bar) [AbstractRestCommand{path='/rest-service-fe/changeset-v1/listChangesets/', params={expand=changesets[-21:-1].revisions[0:29], comment=MULE-4912, p4JobFixed=MULE-4912, rep=mule}, methodType=GET}] : java.net.UnknownHostException: foo.bar
Here is a patch for this problem and functional tests.
(this patch includes all the content of the patch for
MULE-4911)MULE-4911)