cxf-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Konrad Windszus (JIRA)" <>
Subject [jira] [Commented] (CXF-6122) JAX-RS proxy client with @QueryParam is not encoding the parameter value
Date Mon, 01 Dec 2014 17:20:13 GMT


Konrad Windszus commented on CXF-6122:

The problem occurs only if you try to modify the request URI in your ClientRequestFilter.
I tried to replace the path by something else and I used the following code

{{URI newUri = new URI(requestContext.getUri().getScheme(), requestContext.getUri().getAuthority(),
<newPath>, requestContext.getUri().getQuery(), requestContext.getUri().getFragment())}}

This code does not work, because the URI class from Java will not decode the "+" correctly.
This issue only occurs because escaping for
is different than the URLEncoding being performed by,%20java.lang.String%29.

If the original (URLEncoded) URI is (which is the x-www-form-urlencoded
"+value ")
Then the newURI becomes (which is obviously no longer correct).

Do you have a good example for how to modify the path part of the request within you ClientRequestFilter?

> JAX-RS proxy client with @QueryParam is not encoding the parameter value
> ------------------------------------------------------------------------
>                 Key: CXF-6122
>                 URL:
>             Project: CXF
>          Issue Type: Bug
>          Components: JAX-RS
>    Affects Versions: 3.0.2
>            Reporter: Konrad Windszus
> If I create a JAX-RS client with the proxy pattern outlined at
and the proxy interface looks like this
> {code}
> @PUT
> 	@Path("/admin/user/{id}.json")
> 	@Produces(value = { "application/json" })
> 	public User updateUser(@PathParam("id") String userId, @QueryParam("country") String
country, @QueryParam("description") String role, @QueryParam("telephone") String phone);
> {code}
> all URL parameters are not correctly encoded.
> E.g. if phone contains a "+" this will not be converted to %2B or if the role contains
an umlaut this will not be encoded either.
> Another related question is: Which character set will be used here (I guess UTF-8 makes
sense) once that bug is fixed? Also how would it be possible to override the character set?

This message was sent by Atlassian JIRA

View raw message