Details
-
Bug
-
Status: Resolved
-
Critical
-
Resolution: Fixed
-
2.9.0
-
None
-
Mac 10.7 Java 1.6.0_29
-
Unknown
Description
In the class org.apache.camel.util.URISupport which will be used to resolve endpoints (DefaultCamelContext#normalizeEndpointUri) the method parseParameters will be called.
At first the java.net.Uri#getQuery will be called with according to the javadoc "Returns the decoded query component of this URI" returns a decoded URI. If that fails the java.net.Uri#getSchemeSpecificPart method will be called which according to the javadoc "Returns the decoded scheme-specific part of this URI." returns a decoded URI.
So to summarize we get in any case a decoded URI.
This URI will then be than in the method org.apache.camel.util.URISupport#parseQuery(String) again decoded with java.net.URLDecoder#decode(String,String).
This code leads to the following behaviour:
If a % is properly encoded with %25test the %25test will be substituted by the first call to %test and the decoded again which leads to an Exception.
In the http://svn.apache.org/viewvc?view=revision&revision=1166508 commit you can see that the % was uncommented from org.apache.camel.util#UnsafeUriCharactersEncoder. Maybe this is related.
However... Double encoding of URIs seems quite odd. With any URI char there is no issue with that. But with % the % will be decoded again, which makes a % unusable in Camel.
Attachments
Attachments
Issue Links
- is cloned by
-
CAMEL-6176 Camel 2.10.1 incapable of working with + in endpoint URIs
- Resolved
- is related to
-
CAMEL-4425 Cleanup usage of improper URIs in Camel
- Resolved