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 >
