You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by Romain Guignard <ro...@gmail.com> on 2015/03/02 16:01:13 UTC
CXF JAXRS and Single Header value
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
Re: CXF JAXRS and Single Header value
Posted by Romain Guignard <ro...@gmail.com>.
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 <sb...@gmail.com> 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.[@.@.E .........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....\@.@.9..........Y..p....t......c......
>>> .;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 <sb...@gmail.com> 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 <sb...@gmail.com>
>>>>> 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
>
Re: CXF JAXRS and Single Header value
Posted by Sergey Beryozkin <sb...@gmail.com>.
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.[@.@.E .........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....\@.@.9..........Y..p....t......c......
>> .;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 <sb...@gmail.com> 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 <sb...@gmail.com>
>>>> 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
Re: CXF JAXRS and Single Header value
Posted by Sergey Beryozkin <sb...@gmail.com>.
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.[@.@.E .........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....\@.@.9..........Y..p....t......c......
> .;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 <sb...@gmail.com> 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 <sb...@gmail.com> 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
>>
>
Re: CXF JAXRS and Single Header value
Posted by Romain Guignard <ro...@gmail.com>.
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.[@.@.E .........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....\@.@.9..........Y..p....t......c......
.;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 <sb...@gmail.com> 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 <sb...@gmail.com> 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
>
Re: CXF JAXRS and Single Header value
Posted by Sergey Beryozkin <sb...@gmail.com>.
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 <sb...@gmail.com> 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
Re: CXF JAXRS and Single Header value
Posted by Romain Guignard <ro...@gmail.com>.
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 <sb...@gmail.com> 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
>>
>>
>
Re: CXF JAXRS and Single Header value
Posted by Sergey Beryozkin <sb...@gmail.com>.
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
>