Bug in RAW URI encoding of endpoint

["markus.dahm@akquinet.de" <ma...@akquinet.de>]

Hi,

given the following URI (/note the blank in the file name/):

sftp://...../foo?fileName=RAW(bla .zip)

and the following code will break, i.e. will not download the file as
expected

public Exchange receive(final String uri) {
        final Endpoint endpoint =
consumerTemplate.getCamelContext().getEndpoint(uri);
        ...
        return consumerTemplate.receive(*endpoint*);
}

whereas the following code works as expected:

public Exchange receive(final String uri) {
        final Endpoint endpoint =
consumerTemplate.getCamelContext().getEndpoint(uri);
        ...
        return consumerTemplate.receive(*uri*);
}

through heavy debugging we found the reason:

The getEndpoint() call will cause the URI to be escaped as
...&fileName=RAW(bla%20.zip).
OK so far.

Yet within the receive() method the URI is escaped a *second* time!
This causes the final URI to read as ...&fileName=RAW(bla%2520.zip), i.e.
the % sign is escaped, too.

The download then fails of course... 

I' d regard this as a bug in Camel... (Tested with 2.16.3 and 2.18.3)

Cheers
    Markus




--
View this message in context: http://camel.465427.n5.nabble.com/Bug-in-RAW-URI-encoding-of-endpoint-tp5796603.html
Sent from the Camel Development mailing list archive at Nabble.com.

Re: Bug in RAW URI encoding of endpoint

["markus.dahm@akquinet.de" <ma...@akquinet.de>]

Hi Claus,

thank you for your quick reply!
I will try to refactor the code. It'll make things a little more
complicated...

However, the documentation

http://camel.apache.org/how-do-i-configure-endpoints.html
<http://camel.apache.org/how-do-i-configure-endpoints.html>  

says

"Configuring parameter values using raw values, *eg such as* passwords"

and thus suggests that RAW() can be used anywhere in the URI.
And in my opinion it should also be implemented that way. I.e., there is no
reason to restrict the use of RAW() to passwords.

Secondly, the bug applies for passwords, too. I just tried with a password
containing a space and that causes the same escaping behaviour...
Looking at the implementation of RAW the reason is obvious. It uses a
regular expression to handle RAW()
and that is applied twice...

Just a suggestion:
May be URIs should not be handled as plain strings internally, but be parsed
into some AST. That might
make many other things such as "functions" possible...
But that's probably beyond the scope of the current problem :-)

Cheers
    Markus






--
View this message in context: http://camel.465427.n5.nabble.com/Bug-in-RAW-URI-encoding-of-endpoint-tp5796603p5796685.html
Sent from the Camel Development mailing list archive at Nabble.com.

Re: Bug in RAW URI encoding of endpoint

[Claus Ibsen <cl...@gmail.com>]

RAW is intended for passwords etc.

The file component is for consuming files, and if you want to pickup
specific files, then use the filter options.
You can implement a filter where you can match the file with space
etc. Or use one of the filters that uses reg exp style where you can
specific a pattern that matches your file.



On Tue, Mar 28, 2017 at 4:23 PM, markus.dahm@akquinet.de
<ma...@akquinet.de> wrote:
> Hi,
>
> given the following URI (/note the blank in the file name/):
>
> sftp://...../foo?fileName=RAW(bla .zip)
>
> and the following code will break, i.e. will not download the file as
> expected
>
> public Exchange receive(final String uri) {
>         final Endpoint endpoint =
> consumerTemplate.getCamelContext().getEndpoint(uri);
>         ...
>         return consumerTemplate.receive(*endpoint*);
> }
>
> whereas the following code works as expected:
>
> public Exchange receive(final String uri) {
>         final Endpoint endpoint =
> consumerTemplate.getCamelContext().getEndpoint(uri);
>         ...
>         return consumerTemplate.receive(*uri*);
> }
>
> through heavy debugging we found the reason:
>
> The getEndpoint() call will cause the URI to be escaped as
> ...&fileName=RAW(bla%20.zip).
> OK so far.
>
> Yet within the receive() method the URI is escaped a *second* time!
> This causes the final URI to read as ...&fileName=RAW(bla%2520.zip), i.e.
> the % sign is escaped, too.
>
> The download then fails of course...
>
> I' d regard this as a bug in Camel... (Tested with 2.16.3 and 2.18.3)
>
> Cheers
>     Markus
>
>
>
>
> --
> View this message in context: http://camel.465427.n5.nabble.com/Bug-in-RAW-URI-encoding-of-endpoint-tp5796603.html
> Sent from the Camel Development mailing list archive at Nabble.com.



-- 
Claus Ibsen
-----------------
http://davsclaus.com @davsclaus
Camel in Action 2: https://www.manning.com/ibsen2