[
https://issues.apache.org/jira/browse/CAMEL-6176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Goering reopened CAMEL-6176:
-----------------------------------
Estimated Complexity: Moderate (was: Unknown)
thanks a lot for this prompt fix!
unfortunately your approach still leads to problems if the password contains
the character ), which may easily happen using automatically generated
passwords with special characters.
maybe a BASE64 function instead of RAW or a function URLENCODED, which
guarantees that the enclosed text is decoded exactly once and only after
parameter splitting could provide a way to use arbitrary values for passwords
and similar parameters in URIs.
> 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
