Behavior of URL encoding for query parameter changed

[bushwakko]

After updating to newest version (10.7.4) the way query parameters are encoded seems to have changed. I am using JAXRSContract and an interface like this (PS: I didn't design this API, and would never use GET to create an entity):

@GET @Path("/method") PaymentMethodResponse createTransaction(@QueryParam("redirect_url") final String redirectUrl);

Doing client.createTransaction("http://test") would usually encode this as: http%3A%2F%2Ftest
but would now end up being: http%3A//test (the reason being that decodeSlash would both be set default to true, and be invoked for query-parameters.

This behavior also applies when using the @RequestLine annotations, but can be solved by setting decodeSlash = false.

Since there is no way to set "decodeSlash" via the jaxrs-annotations or to configure the JAXRSContract to have it default "false", a very dirty fix for us was to do the following:
`
private static class NoDecodeSlashJAXRSContract extends JAXRSContract {
public NoDecodeSlashJAXRSContract() {
super();
}

    @Override
    protected MethodMetadata parseAndValidateMetadata(Class<?> targetType, Method method) {
        final MethodMetadata methodMetadata = super.parseAndValidateMetadata(targetType, method);
        final RequestTemplate template = methodMetadata.template();
        template.uri("", true);
        template.decodeSlash(false);
        return methodMetadata;
    }
}

`

The template.uri is set here to not get NPE on missing uri when setting decodeSlash via the method, and the decodeSlash is then set to false. This brings back the previous behavior.

I suspect this is somehow a introduced when this code path was recently rewritten.

[kdavisk6]

@bushwakko

You are correct, we do not expose decodeSlash outside of the main contract. I've put a longer explanation in #1190.

For your use case, a custom Contract could get you through in the short term, though I know it's not ideal. I'll confer with the other maintainers, but I'm open to suggestions on how we can solve this for you in the near term while we work on #1019

[kdavisk6]

Closing in favor of #1190