[
https://issues.apache.org/jira/browse/CAMEL-6176?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13613647#comment-13613647
]
Daniel Goering commented on CAMEL-6176:
---------------------------------------
I don't have a working test suit here but from looking at your patch I don't
see why it should work as a last parameter; I think the password would be
truncated and the general parsing would probably crash with an unknown
parameter exception when trying to interpret the part of the password after the
)& string.
changing the {{RAW_TOKEN_END}} to something more distinct than a single
character should reduce the probability for conflicts significantly; using )RAW
will only lead to issues if a value contains )RAW&, which should not happen
very often by chance.
thanks a lot for your help!
> 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: Improvement
> Components: camel-core
> Affects Versions: 2.10.1
> Environment: Linux Java 1.6.0_35
> Reporter: Daniel Goering
> Assignee: Claus Ibsen
> Fix For: 2.11.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
