I see a test like this:
@Test
public void testClonePctEncoded() throws Exception {
URI uri = new URI("http://bar";);
URI newUri = new UriBuilderImpl(uri)
.path("{a}").path("{b}")
.matrixParam("m", "m1 ", "m2+%20")
.queryParam("q", "q1 ",
"q2+q3%20").clone().buildFromEncoded("a+ ", "b%2B%20 ");
assertEquals("URI is not built correctly",
"http://bar/a+%20/b%2B%20%20;m=m1%20;m=m2+%20?q=q1+&q=q2%2Bq3%20";,
newUri.toString());
}
Note a 'q' query parameter has 2 values, one of them is
"q2+q3%20" so here we have a valid %-encoded representation.
The test asserts it is encoded as:
"q2%2Bq3%20"
i.e it stays untouched.
I nearly 100% sure this test was added as part of the TCK work, but do
not hesitate to test Jersey further if you'd like
Sergey
On 04/03/16 11:11, Sergey Beryozkin wrote:
Can you experiment with JAX-RS RI UriBuilder and double check that
passing to it a query parameter like "%DE" will not encode it ?
I'm pretty sure they won't. I have done a lot of work with UriBuilder to
make sure it passed JAX-RS 1.1 and the early 2.0 TCK that was available
to Apache. So I'd be surprised if I had to fix UriBuilder further given
that a lot of TCK tests are targeted at UriBuilder.
If Jersey does encode it then I'll review it and see what may need to be
done
Sergey
On 04/03/16 10:56, Sergey Beryozkin wrote:
As I said, CXF proxy runtime uses JAX-RS UriBuilder.
And UriBuilder does not touch valid percent-encoded representations.
And this is how the RS client runtime will continue operating.
Sergey
On 04/03/16 10:45, Volkov Sergey wrote:
"100%25BETTER VALID STRING"
instead of
"100%BETTER VALID STRING"
"100%25BETTER VALID STRING" is correct way to urlencode "100%BETTER
VALID
STRING" - so actually CXF is over-smart now, when it skips all %xx
sequence
instead of encode % as %25
"100%VALID STRING" at the moment encodes by cxf as "100%25VALID STRING"
In the former case it it has no characters that can be used to form the
hex %-encoded representations.
The bottom line is, you should not expect the runtime auto-encode '%'
given that this symbol plays a special role in having correct URIs
being
created.
If CXF will try to me over-smart then the next day someone will report
that it started producing
"100%25BETTER VALID STRING"
instead of
"100%BETTER VALID STRING"
Sergey
On 04/03/16 07:43, Volkov Sergey wrote:
Looks like POST request and @FormParam could be used, but I think this
behavior of @QueryParam may lead to tricky bugs in many places
where it
used
2016-03-04 10:37 GMT+03:00 Volkov Sergey <[hidden email]
<http://cxf.547215.n5.nabble.com/user/SendEmail.jtp?type=node&node=5766616&i=0>>:
Yes, I don't understand why it does not touch this sequences.
It's a bit strange because I can successfully transfer "100%VALID
STRING"
but not "100%BETTER VALID STRING"
Both this string not percent encoded, but second contains %BE which
just
looks like percent encoded.
If instead of
org.apache.cxf.jaxrs.utils.HttpUtils#encodePartiallyEncoded
cxf just urlencode parameter value when building query string both
examples
would be transferred correctly.
If you are saying that
when you pass something like "%D1%82", or to make it clearer,
"%D1" and expect CXF do "%25D1", then no, it won't work.
UriBuilder does not touch percent-encoded sequences %XX.
May be try building the query with UriBuilder before passing it to
the
proxy, something like
UriBuilder.fromUri("{a}%D21").build("%").toString()
Though not sure it will be cheaper.
Sergey
On 03/03/16 21:27, Sergey Beryozkin wrote:
From the original post in this thread:
When I pass string "т" (Cyrillic symbol) to generated client in
encodes
to
"%D1%82" in url and decodes as "т" on server what is fine, but
when
i
pass
"%D1%82" rather then "%25D1%2582" in encodes also to "%D1%82"
and
decodes
also to "т".
I honestly don't get what the problem is. You pass a Cyrillic
symbol
either as is or already percent encoded and in both case, as you
say
above, you get this Cyrillic symbol.
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
