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
