Thanks a lot for you help. Indeed your test is working. I will debug again and try to find the issue.
Best On 2 March 2015 at 19:04, Sergey Beryozkin <[email protected]> wrote: > The only other option is to provide a test case - though I hope you will > find the source of the problem after a debugging session > > > > On 02/03/15 18:00, Sergey Beryozkin wrote: > >> I've no idea where you have these brackets coming from. If CXF itself >> were adding such brackets it would break lots of users's applications. >> >> I've just rebuild a basic demo and updated >> >> https://git-wip-us.apache.org/repos/asf?p=cxf.git;a=blob;f= >> distribution/src/main/release/samples/jax_rs/basic/src/main/ >> java/demo/jaxrs/server/CustomerService.java;h= >> 480c2c9ddcf209030f676a5ce201f8b1c096eedb;hb=HEAD#l46 >> >> >> to return Customer, instead of "return c" as >> >> return Response.ok(c).header("X-Owner", >> "0d1ad896-7938-11e4-a487-000c29484743").build(); >> >> I have an old Apache TCP trace utility installed, it shows that >> >> GET /customerservice/customers/123 >> >> returns >> >> HTTP/1.1 200 OK >> Date: Mon, 02 Mar 2015 17:50:57 GMT >> Content-Type: text/xml >> Date: Mon, 02 Mar 2015 17:50:57 GMT >> X-Owner: 0d1ad896-7938-11e4-a487-000c29484743 >> Content-Length: 105 >> Server: Jetty(9.2.3.v20140905) >> >> <?xml version="1.0" encoding="UTF-8" >> standalone="yes"?><Customer><id>123</id><name>John</name></Customer> >> >> >> I recommend you debug the CXF server itself, starting from >> >> https://git-wip-us.apache.org/repos/asf?p=cxf.git;a=blob;f= >> rt/transports/http/src/main/java/org/apache/cxf/transport/ >> http/Headers.java;h=5507f40d658f72c515261227600436c64384ed19;hb=HEAD#l441 >> >> >> and then drill down into the actual Servlet implementation stack. I >> suspect you have a bug lurking somewhere at the low level HTTP runtime >> implementation >> >> Sergey >> >> >> >> >> On 02/03/15 17:33, Romain Guignard wrote: >> >>> Below, a capture realised with TCPDUMP on the service that return the >>> response: >>> >>> 18:29:23.087530 IP 172.27.0.30.afs3-callback > 172.27.0.11.44312: Flags >>> [.], ack 769, win 251, options [nop,nop,TS val 2805678924 ecr >>> 2276623103], >>> length 0 >>> E..4.[@[email protected] .........Y..p....t......X...... >>> .;CL.... >>> 18:29:23.358859 IP 172.27.0.30.afs3-callback > 172.27.0.11.44312: Flags >>> [.], seq 1:2897, ack 769, win 251, options [nop,nop,TS val 2805678992 ecr >>> 2276623103], length 2896 >>> E....\@[email protected]...... >>> .;C.....HTTP/1.1 200 OK >>> Content-Disposition: [attachment; filename="application.png"] >>> Content-Type: application/octet-stream >>> Date: Mon, 02 Mar 2015 17:29:23 GMT >>> ETag: "75358335dff9f387ee9422dbcde70c11" >>> Last-Modified: Thu, 26 Feb 2015 14:01:08 GMT >>> X-Owner: [0d1ad896-7938-11e4-a487-000c29484743] >>> Content-Length: 2710 >>> >>> >>> On 2 March 2015 at 18:12, Sergey Beryozkin <[email protected]> wrote: >>> >>> Can you use wireshark or some other tcp trace utility and post the >>>> captured response here ? >>>> >>>> >>>> On 02/03/15 17:10, Romain Guignard wrote: >>>> >>>> Exactly, we have discuseed it on CXF IRC. I continue to debug this >>>>> point >>>>> and I have realized others tests. >>>>> >>>>> >>>>> This is the response header captured with chrome debugger: >>>>> >>>>> >>>>> Connection:Keep-Alive >>>>> >>>>> Content-Disposition: [attachment; filename="test.png"] >>>>> >>>>> Content-Length:2710 >>>>> >>>>> Content-Type:application/png >>>>> >>>>> Date:Mon, 02 Mar 2015 17:02:40 GMT >>>>> >>>>> ETag:"75358335dff9f387ss9422dbcde70c11" >>>>> >>>>> Keep-Alive:timeout=5, max=100 >>>>> >>>>> Last-Modified:Thu, 27 Feb 2015 14:01:08 GMT >>>>> >>>>> X-Owner:[0d1ad896-7938-11e4-a487-000c29484743] >>>>> >>>>> >>>>> >>>>> As you can see, only additional headers (Content-Disposition and >>>>> X-Object) >>>>> are between brackets. >>>>> >>>>> Consequently, Chrome cannot interpret the Content-Disposition >>>>> header. To >>>>> validate this, I placed a reverse proxy that rewrites the >>>>> Content-Disposition header response without bracket. And in this case, >>>>> chrome correctly interpreted the header >>>>> >>>>> >>>>> >>>>> >>>>> On 2 March 2015 at 16:25, Sergey Beryozkin <[email protected]> >>>>> wrote: >>>>> >>>>> Hi >>>>> >>>>>> >>>>>> I have discussed it on CXF IRC recently (possibly with yourself), I do >>>>>> not >>>>>> think CXF JAX-RS wraps single header values in square brackets, as >>>>>> I said >>>>>> on IRC it must be a debugging output, >>>>>> >>>>>> Any HTTP header is typically represented as a key to list of values >>>>>> pair, >>>>>> and hence you see though brackets. >>>>>> >>>>>> Run it all through a TCP trace utility to confirm no brackets is on >>>>>> the >>>>>> wire >>>>>> >>>>>> Cheers, Sergey >>>>>> On 02/03/15 15:01, Romain Guignard wrote: >>>>>> >>>>>> Hi guys >>>>>> >>>>>>> >>>>>>> I have a question about REST header management and the possibility to >>>>>>> add >>>>>>> a >>>>>>> single header value. >>>>>>> >>>>>>> When I put customs header on a REST response: >>>>>>> >>>>>>> *response.header("Object-Meta-Owner ", >>>>>>> "0d1ad896-7938-11e4-a487-000c29484743"))*, it appears that the >>>>>>> header >>>>>>> value >>>>>>> is contains between brackets like this >>>>>>> >>>>>>> *X-Object-Meta-Owner: [0d1ad896-7938-11e4-a487-000c29484743]* >>>>>>> >>>>>>> >>>>>>> Is there a way to put a single value header and consequently to >>>>>>> return a >>>>>>> response header without these brackets? >>>>>>> >>>>>>> >>>>>>> I have the same problem by setting a “content-disposition” header >>>>>>> that >>>>>>> must >>>>>>> be directly interpreted by browsers. But, because the value is >>>>>>> between >>>>>>> brackets some browsers cannot interpreted the header (it’s the >>>>>>> case of >>>>>>> Chrome for example) >>>>>>> >>>>>>> >>>>>>> For information, I use CXF-RT-* version 3.0.1 >>>>>>> >>>>>>> >>>>>>> Thanks in advance >>>>>>> >>>>>>> >>>>>>> Romain >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>> -- >>>> Sergey Beryozkin >>>> >>>> Talend Community Coders >>>> http://coders.talend.com/ >>>> >>>> Blog: http://sberyozkin.blogspot.com >>>> >>>> >>> >> > > -- > Sergey Beryozkin > > Talend Community Coders > http://coders.talend.com/ > > Blog: http://sberyozkin.blogspot.com >
