[
https://issues.apache.org/jira/browse/CAMEL-6176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Goering updated CAMEL-6176:
----------------------------------
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.
As workaround for CAMEL-4954 all % are encoded, i.e. replaced by %25.
The URI will then be decoded again in the method
org.apache.camel.util.URISupport#parseQuery(String) with
java.net.URLDecoder#decode(String,String).
This code leads to the following behaviour:
If a + is properly encoded with foo%2Bbar the foo%2Bbar will be substituted by
the first call with foo+bar and then decoded again which leads to foo bar.
If the + is not encoded at all foo+bar will be decoded to foo bar in the first
step and not be changed again in the second step.
If the + is double encoded to foo%252Bbar the first call will transform it to
foo%2Bbar, then the workaround for CAMEL-4954 will change it back to
foo%252Bbar and the final decode will change it again to foo%2Bbar.
Thus, currently there is no way to use a + in passwords or similar parameter
values if the parameter has to be supplied via endpoint URIs.
was:
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.
> Camel 2.10.1 incapable of working with + in endpoint URIs
> ---------------------------------------------------------
>
> Key: CAMEL-6176
> URL: https://issues.apache.org/jira/browse/CAMEL-6176
> Project: Camel
> Issue Type: Bug
> Components: camel-core
> Affects Versions: 2.9.0
> Environment: Mac 10.7 Java 1.6.0_29
> Reporter: Daniel Goering
> Assignee: Hadrian Zbarcea
> Priority: Critical
> Fix For: 2.9.1, 2.10.0
>
>
> 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.
> As workaround for CAMEL-4954 all % are encoded, i.e. replaced by %25.
> The URI will then be decoded again in the method
> org.apache.camel.util.URISupport#parseQuery(String) with
> java.net.URLDecoder#decode(String,String).
> This code leads to the following behaviour:
> If a + is properly encoded with foo%2Bbar the foo%2Bbar will be substituted
> by the first call with foo+bar and then decoded again which leads to foo bar.
> If the + is not encoded at all foo+bar will be decoded to foo bar in the
> first step and not be changed again in the second step.
> If the + is double encoded to foo%252Bbar the first call will transform it
> to foo%2Bbar, then the workaround for CAMEL-4954 will change it back to
> foo%252Bbar and the final decode will change it again to foo%2Bbar.
> Thus, currently there is no way to use a + in passwords or similar parameter
> values if the parameter has to be supplied via endpoint URIs.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
