Just double checked that using WebClient directly (in that test I pointed out to) works as well. So IMHO the problem is somewhere at the lower level.

Sergey
On 07/04/16 12:24, Sergey Beryozkin wrote:
Hi

One thing I'd like to point out - CXF checks the matrix parameters on
the request URI, obtained from:

(HttpServletRequest)req.getRequestURI();

which must not return the query part.

So the source of the problem is that either:
- the container mistakenly returns the query as part of the request URI
- the question mark is mistakenly encoded on the client side, which
would result the combined value after being decoded on the client side.

Can you please confirm with HTTP trace enabled (TCP trace utility) that
a question mark is either encoded or not ?

Thanks, Sergey


On 06/04/16 17:20, Sergey Beryozkin wrote:
Hi Christian

I simply updated this test:

https://github.com/apache/cxf/blob/master/systests/jaxrs/src/test/java/org/apache/cxf/systest/jaxrs/JAXRSClientServerBookTest.java#L1954



I tried

"http://localhost:"; + PORT +
"/bookstore/segment/matrix;first=12;second=3?loc=123"

and only with a single matrix param:

"http://localhost:"; + PORT + "/bookstore/segment/matrix;first=12?loc=123"

and then I put a breakpoint in:

https://github.com/apache/cxf/blob/master/systests/jaxrs/src/test/java/org/apache/cxf/systest/jaxrs/BookStore.java#L764



and checked '?loc=123' was not there.

The test runs on top of Jetty

Cheers, Sergey
On 06/04/16 17:00, Christian Balzer wrote:
Hi Sergey,

Thank you for looking into this. We are using an internal framework at
work that makes use of CXF - which means that it's not that easy to
just swap CXF out, unfortunately.
Having said that, a colleague started work to replace CXF 2.x by CXF
3.x today. But it'll be a few days before everything will be ported
over; so we can't yet say whether CXF 3.x is affected or not.

In the meantime, we did create another project from scratch, and
implemented an endpoint for GET.
Here are the results:

1 - USING CXF CLIENT VIA LOCAL (INTEGRATION TEST)
* matrix before query: ;m=1?q=2
* no QUERY_STRING entry in XMLMessage map
* result (fails):
    * matrix param populated with matrix param value concatenated with
all of query string: 1?q=2
    * query param populated correctly: 2

2 - USING CFX CLIENT VIA HTTP TO SERVER
* matrix before query: ;m=1?q=2
* QUERY_STRING present in XMLMessage map
* all works

3 - USING CHROME POSTMAN EXTENSION TO SERVER
* matrix before query: ;m=1?q=2
* query param value: 2
* marix param vaule: 1
* all works

4 - USING CHROME POSTMAN EXTENSION TO SERVER
* query before matrix: ?q=2;m=1
* query string contains the matrix parma: 2;m=1
* query param value: <null>
* matrix param value: 2;m=1
* arguably, this one could be considered ok if you argued that the
matrix param relates to the query param

Running via Chrome Postman extension to the server, here is the TCP
dump (I removed proprietary headers):
GET /bar/test?q=2;m=1 HTTP/1.1
Host: 10.221.29.152:7001
Connection: keep-alive
Accept: application/json
Cache-Control: no-cache
Content-Type: application/json
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64)
AppleWebKit/537.36 (KHTML, like Gecko) Chrome/48.0.2564.82
Safari/537.36
Postman-Token: 1bc0c914-80a3-1829-ec9d-8352118792ec
Accept-Encoding: gzip, deflate, sdch
Accept-Language: en-GB,en;q=0.8,en-US;q=0.6,de;q=0.4

HTTP/1.1 200 OK
Cache-Control: private, no-cache, no-store, no-transform
Date: Wed, 06 Apr 2016 13:59:38 GMT
Content-Length: 0
Operation: (GET)/bar/test
X-Powered-By: Servlet/3.0 JSP/2.2

Also, org.apache.cxf.message.Message holds (amongst others):
QUERY_STRING -> "q=2;m=1"
"HTTP.REQUEST" -> "[
GET /bar/test?q=2;m=1 HTTP/1.1
...
]"

Now, why it fails for LOCAL transport for matrix before query, and for
query before matrix via HTTP, we don't quite know.
But I think it's fair to say it's probably nothing to do with the
encoding of the question mark...
(The Message map for test case 1 holds "org.apache.cxf.request.uri" ->
"/dates/test;one=1?two=2".)

Could you maybe share your test project with us, so we can compare
what you are doing, please? :-)

Kind regards,

Christian

On Tue, Apr 5, 2016 at 1:37 PM, Sergey Beryozkin
<sberyoz...@gmail.com> wrote:
Hi

I've experimented with a local test, I can not reproduce it.

Can you please add some logging on the client/server, or preferably,
pass it
via some TCP tracer, I wonder if the question mark ends up being
encoded,
etc, may be the client (HttpUrlConnection) gets confused about PUT
and query
parameters.

What about GET ?

Can you also double check CXF 3.1.x (just to confirm this issue is
2.7.x
specific)

Cheers, Sergey

On 05/04/16 11:35, Christian Balzer wrote:

Hi all,

We are restricted to the 2.x branch of cxf.

When we call our REST endpoint and provide a matrix parameter
(;id=123), followed by a query parameter (?loc=abc), cxf populates the
String argument annotated with the @MatrixParam bind annotation with
the merged String of matrix value and query parameter, i.e.
123?loc=abc

Any idea why and what we can do to stop that from happening?

We are basically using the following to fire up the request (via local
protocol) from our integration test:

client.path("foo/987")
    .type(MediaType.APPLICATION_JSON)
    .accept(MediaType.APPLICATION_JSON)
// adding headers here...
    .matrix("id", "123")
    .query("loc", "abc")
     .put(TEST_PAYLOAD);

Here is the method signature we are using for the endpoint:

@PUT
@Consumes({APPLICATION_JSON})
@Produces({"application/json;charset=UTF-8"})
public Response doStuff(
          @BeanParam B b,  // pulls out 987
          @MatrixParam("id") String id,
          @QueryParam("loc") String loc,
          MySchema mySchema,
          @HeaderParam("bar") String header,
          @Context UriInfo uriInfo)
          throws Exception {

This results in loc being set to "abc" and id to "123?loc=abc"... :-(

Any help is much appreciated!

Kind regards,

Christian



--
Sergey Beryozkin

Talend Community Coders
http://coders.talend.com/






--
Sergey Beryozkin

Talend Community Coders
http://coders.talend.com/

Reply via email to