Must percent-encoded special characters in a Camel message endpoint URI
be wrapped in RAW() in order for Camel to correctly process the URI?

For example: I believe the following is a valid [Camel endpoint URI of
schema "aws-sqs"][1]:

    
<aws-sqs://my-sqs-queue?accessKey=AKIADKB5LS3V6L9XWB2&secretKey=wvAUnoM%2BRLZzdWmyBDIYdLRGEHa8BY57sKjy0tXO>

That would refer to an AWS SQS queue named my-sqs-queue, available with
AWS access key AKIADKB5LS3V6L9XWB2 and secret key
wvAUnoM+RLZzdWmyBDIYdLRGEHa8BY57sKjy0tXO.

Because the "+" in that secret key is a [reserved character in URI
syntax][2], we must [percent-encode][3] it when composing a URI with
that secret key, whether the intended use be Camel or anything else.

It's unclear to me whether the problem reported with [CAMEL-5453][4]
("An AWS key with "+" gets stripped out by
DefaultCamelContext.normalizeEndointUri and URISupport.parseQuery for at
least the SQS Component") then described as fixed with [CAMEL-6176][5]
("Camel 2.10.1 incapable of working with + in endpoint URIs"), was
actually *fixed* (i.e., Camel now works correctly with some valid URIs,
such as my example), or the result was simply the addition of a new
feature that can be used to work around the problem (i.e., Camel still
fails with some valid URIs, such as my example, but offers RAW() for use
in working around this flaw.

Although I find discussion of the availability of RAW() in the [Camel
"How do I configure endpoints?" FAQ entry][5], I see no indication in
the [Camel architecture: URIs documentation][7] or in the [Camel SQS
Component documentation][3] that use of RAW() is required under any
circumstance.


References:

 [1]: <https://camel.apache.org/aws-sqs.html>
 [2]: <https://tools.ietf.org/html/std66#section-2.2>
 [3]: <https://tools.ietf.org/html/std66#section-2.1>
 [4]: <https://issues.apache.org/jira/browse/CAMEL-5453>
 [5]: <https://issues.apache.org/jira/browse/CAMEL-6176>
 [6]: <https://camel.apache.org/how-do-i-configure-endpoints.html>
 [7]: <https://camel.apache.org/uris.html>

-- 
Phil Mocek
https://mocek.org

Reply via email to