Wrong Character enconding on % in parameter

[nagelfargithub]

I have an interface containing a method like this @GET RestResponse<List<KundenDTO>> searchKunden(@QueryParam(TERMINAL_ID) long terminalId, @QueryParam(KUNDEN_SEARCH) String kundenSearch);

If I now set the parameter "kundenSearch" to something like '%cargo' this doesn't get properly URL encoded but sent as is so at my server I receive '[unprintable_character]rgo as %ca gets interpreted as a special, encoded character.

My question, is this to be expected? Do we have to properly encode all our parameters before passing them or is this a bug?

[scottslewis]

Hi. I'm still looking into this. Apparently the behavior of WebTarget.queryParam (which is what is used by ECF proxy impl at runtime to handle the QueryParam annotations on client side) is implementation-dependent. In this case currently Jersey 2.30.1)...and it seems that the encoding might not be done correctly:

https://linuxtut.com/en/ee817c1e792adcd07e5d/

I'm still tracking down whether this is true specifically for Jersey 2.30.1. If the above is still true for this version of Jersey, then you might try doing as they suggest...i.e. manually encoding/decoding to handle the % (which should be url encoded as %25 I think).

Unfortunately, since Jersey is doing the real work here, I can't fix this problem. I might be able to impose a work-around (doing this encoding specifically for % only) if it does turn out to still be Jersey's behavior...but before doing that I want to understand better what Jersey is doing. Could you please try encoding the % chars as %25 manually before call and report what happens here? Thanks.

[nagelfargithub]

Yes, I can confirm this is exactly what we are seeing, %cargo breaks as c and a are hex, %reis works as r is not hex. I tried manually encoding % to %25 and it works so I understand this is not a bug, let alone in your implementation but works as "expected". We'll look into using a Filter (or similar) to do this on a default level. Thanks for your feedback!

[scottslewis]

Ok, thanks for checking and reporting here. FWIW, the JaxRSProvider allows you to use OSGI services to setup a javax.ws.rs.client.ClientRequestFilter implementation. As an example, see this bundle:

https://github.com/ECF/JaxRSProviders/tree/master/examples/org.eclipse.ecf.example.jersey.client.basicauth

This creates a ClientRequestFilter to pass basic auth data along with the request. Note from the src here:

https://github.com/ECF/JaxRSProviders/blob/master/examples/org.eclipse.ecf.example.jersey.client.basicauth/src/org/eclipse/ecf/example/jersey/client/basicauth/BasicAuthClientRequestFilter.java

this annotation:

@Component(immediate=true,property = {"jaxrs-service-exported-config-target=ecf.jaxrs.jersey.client" })

defines this as an declarative services Component. The property = {"jaxrs-service-exported-config-target=ecf.jaxrs.jersey.client" } definition allows you to target a specific config name for your filter. Yours should be similar...i.e. "ecf.jaxrs.jersey.client". As long as this Component is registered before importing the remote service (e.g. on starup), the Component with the property will be registered to the client as a ClientRequestFilter and filter method will be called every time request/method call is made. I think that you can then used the ClientRequestContext.getParameterMap() to get the relevant parameter value, url encode any % and then put the new value in the parameter map.