Inconsistecy between endpoint uri and intercepted uri (in.header.CamelInterceptedEndpoint)

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Inconsistecy between endpoint uri and intercepted uri (in.header.CamelInterceptedEndpoint)

Marco Crivellaro
I have stumbled across a small issue while comparing the uri of the endpoint the route is pushing to and the uri set by interceptSendToEndpoint on the in header CamelInterceptedEndpoint: they don't compare.

The CamelInterceptedEndpoint header seems the representation UnsafeUriCharactersEncoder encoded version of original uri.
I am wondering if this is how it is supposed to be or there is an issue.
It looks like the same kind of issue is shown with the header CamelToEndpoint set by Aggregator.

For the time being I am using UnsafeUriCharactersEncoder.encode(originalUri) to find the endpoint in my endpoint collection when using the interceptor.


A couple of examples

original uri (to):
ftp://user@hostname?password=RAW(12&34)&tempFileName=RAW(${file:name.noext}.${in.header.x-feed_id}.tmp)

intercepted:
ftp://user@hostname?password=RAW(12&34)&tempFileName=RAW($%7Bfile:name.noext%7D.$%7Bin.header.x-feed_id%7D.tmp)



original uri (to):
ftp://user@hostname?password=RAW(12&34)&tempFileName=RAW($%7Bfile:name.noext%7D.$%7Bin.header.x-feed_id%7D.tmp)

intercepted:
ftp://user@hostname?password=RAW(12&34)&tempFileName=RAW($%257Bfile:name.noext%257D.$%257Bin.header.x-feed_id%257D.tmp)
Reply | Threaded
Open this post in threaded view
|

Re: Inconsistecy between endpoint uri and intercepted uri (in.header.CamelInterceptedEndpoint)

Marco Crivellaro
I have figured out the intercepted endpoint uri can be obtained by using resolveEndpoint of ExchangeHelper:


String resolvedEndpointURI = ExchangeHelper.resolveEndpoint(exch, originalUri).getEndpointUri();


with camel 2.8.6 I could use the resolvedEndpointUri as the URI to be passed to a recipient list, with camel 2.15.3-SNAPSHOT this is no longer true as the originalUri and resolved uri differs, a password containing % would be encoded as follow and no longer work:

original: password=RAW(12%34)
after resolve endpoint: password=RAW(12%2534)

just wondering if this is the expected behaviour as using password=RAW(12%2534) on my route wouldn't work when the password of the enpoint is 12%34