You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by Christian <ch...@gmail.com> on 2016/02/16 18:43:39 UTC
Re: WebClient - Content-Type Override?
Hi Sergey,
We are facing a similar issue; we are trying to send a GET with a
Content-Type header, as the service called requires it.
Just wondering if the workaround with the interceptor is still required?
We are trying to set a particular Content-Type (application/json), but it
gets stripped out at some point before the request gets sent, and the call
fails. Is that cxf's doing?
Regards,
Christian
Sergey Beryozkin wrote
> Ok, thanks for this info.
> You've found the workaround which is good, another option is to
> register a custom CXF out interceptor which would reset Content-Type
> to the required value, it can be registered with
> JAXRSClientFactoryBean:
>
> JAXRSClientFactoryBean bean = new JAXRSClientFactoryBean();
> bean.setAddress(address);
> bean.getOutInterceptors().add(new CustomOutInterceptor());
> bean.createWebClient();
>
> I'll try fix it as well
> Sergey
>
>
> On Sun, Jul 31, 2011 at 10:17 PM, Jeff Wang <
> jeff.wang@
> > wrote:
>> We're trying to use Amazon's query string authentication. We can set
>> Content-Type to "", or heck, to any other string. It's just that the
>> server uses the content type as part of its signature calculation. So
>> when we generate the signature, we expected to set it with some content
>> type (tried it with either "" or an actual type, it doesn't matter.) If
>> it gets overridden, like what happens with webClient.get(), then the
>> signatures will be wrong and auth will get rejected. The actual header
>> has no meaning in a GET, but we do need to control what it is so that the
>> signatures match.
>>
>> Jeff
>>
>>
>> -----Original Message-----
>> From: Sergey Beryozkin [mailto:
> sberyozkin@
> ]
>> Sent: Sun 7/31/2011 11:00 AM
>> To:
> users@.apache
>> Subject: Re: WebClient - Content-Type Override?
>>
>> Hi,
>>
>> Does the server expect Content-Type being set even in case of GET
>> requests ?
>>
>> Cheers, Sergey
>> On 28/07/11 22:45, Jeff Wang wrote:
>>> Looking through the code, it seems that if the body is null (which has
>>> to be the case considering it's a get, then the content type is
>>> overwritten with wildcards.
>>> Using client.invoke("GET",""); solved the problem for me.
>>>
>>> Jeff
>>>
>>> -----Original Message-----
>>> From: Jeff Wang [mailto:
> jeff.wang@
> ]
>>> Sent: Wednesday, July 27, 2011 5:29 PM
>>> To:
> users@.apache
>>> Subject: WebClient - Content-Type Override?
>>>
>>> I'm trying to act as a proxy to a third party webservice, and need to
>>> transform a REST request. One issue that I have is that the
>>> Content-Type header seems to get overridden no matter what I do. The
>>> code is actually very simple (context is an @Context MessageContext
>>> variable):
>>>
>>> WebClient client = WebClient.create(url)
>>> .header("real-header-removed",
>>> "auth-string-removed")
>>> // .header("Content-Type",
>>> context.getHttpHeaders().getMediaType().toString());
>>> .type(context.getHttpHeaders().getMediaType());
>>>
>>> Response resp = client.get();
>>> return (InputStream)resp.getEntity();
>>>
>>> Neither the .header nor the .type worked. The tcpmon output of the
>>> request is:
>>> Content-Type: */*
>>> real-header-removed: auth-string-removed
>>> Accept: application/xml
>>> User-Agent: Apache CXF 2.3.5
>>> Cache-Control: no-cache
>>> Pragma: no-cache
>>>
>>> How do I avoid the content Type override (or rather, why is it
>>> happening?)
>>> Btw, while looking for answers, I found my CXF server side answers
>>> relatively easily either via google or the archive. But client
>>> questions seems to be rather rare, and mostly on the SOAP calls. Are
>>> most people using other packages?
>>>
>>> thanks
>>> Jeff
>>
>>
>>
>
>
>
> --
> Sergey Beryozkin
>
> http://sberyozkin.blogspot.com
> Talend - http://www.talend.com
--
View this message in context: http://cxf.547215.n5.nabble.com/WebClient-Content-Type-Override-tp4640790p5765944.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: WebClient - Content-Type Override?
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi
I guess the workaround is required given that 2.7.x is not being
released any longer
Cheers, Sergey
On 16/02/16 18:08, Andrew Clark wrote:
> Hi Sergey
>
> Unfortunately we are currently restricted to using 2.x, we are currently on version 2.7.15.
>
>
> Sent from my iPhone
>
>> On 16 Feb 2016, at 17:49, "Sergey Beryozkin" <sb...@gmail.com> wrote:
>>
>> Hi Christian
>>
>> Starting with CXF 3.1.5 (or may be even 3.1.4) you should be able to set a custom Content-Type and it will go on the wire
>>
>> Cheers, Sergey
>>> On 16/02/16 17:43, Christian wrote:
>>> Hi Sergey,
>>>
>>> We are facing a similar issue; we are trying to send a GET with a
>>> Content-Type header, as the service called requires it.
>>>
>>> Just wondering if the workaround with the interceptor is still required?
>>>
>>> We are trying to set a particular Content-Type (application/json), but it
>>> gets stripped out at some point before the request gets sent, and the call
>>> fails. Is that cxf's doing?
>>>
>>> Regards,
>>> Christian
>>>
>>>
>>>
>>> Sergey Beryozkin wrote
>>>> Ok, thanks for this info.
>>>> You've found the workaround which is good, another option is to
>>>> register a custom CXF out interceptor which would reset Content-Type
>>>> to the required value, it can be registered with
>>>> JAXRSClientFactoryBean:
>>>>
>>>> JAXRSClientFactoryBean bean = new JAXRSClientFactoryBean();
>>>> bean.setAddress(address);
>>>> bean.getOutInterceptors().add(new CustomOutInterceptor());
>>>> bean.createWebClient();
>>>>
>>>> I'll try fix it as well
>>>> Sergey
>>>>
>>>>
>>>> On Sun, Jul 31, 2011 at 10:17 PM, Jeff Wang <
>>>
>>>> jeff.wang@
>>>
>>>> > wrote:
>>>>> We're trying to use Amazon's query string authentication. We can set
>>>>> Content-Type to "", or heck, to any other string. It's just that the
>>>>> server uses the content type as part of its signature calculation. So
>>>>> when we generate the signature, we expected to set it with some content
>>>>> type (tried it with either "" or an actual type, it doesn't matter.) If
>>>>> it gets overridden, like what happens with webClient.get(), then the
>>>>> signatures will be wrong and auth will get rejected. The actual header
>>>>> has no meaning in a GET, but we do need to control what it is so that the
>>>>> signatures match.
>>>>>
>>>>> Jeff
>>>>>
>>>>>
>>>>> -----Original Message-----
>>>>> From: Sergey Beryozkin [mailto:
>>>
>>>> sberyozkin@
>>>
>>>> ]
>>>>> Sent: Sun 7/31/2011 11:00 AM
>>>>> To:
>>>
>>>> users@.apache
>>>
>>>>> Subject: Re: WebClient - Content-Type Override?
>>>>>
>>>>> Hi,
>>>>>
>>>>> Does the server expect Content-Type being set even in case of GET
>>>>> requests ?
>>>>>
>>>>> Cheers, Sergey
>>>>>> On 28/07/11 22:45, Jeff Wang wrote:
>>>>>> Looking through the code, it seems that if the body is null (which has
>>>>>> to be the case considering it's a get, then the content type is
>>>>>> overwritten with wildcards.
>>>>>> Using client.invoke("GET",""); solved the problem for me.
>>>>>>
>>>>>> Jeff
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Jeff Wang [mailto:
>>>
>>>> jeff.wang@
>>>
>>>> ]
>>>>>> Sent: Wednesday, July 27, 2011 5:29 PM
>>>>>> To:
>>>
>>>> users@.apache
>>>
>>>>>> Subject: WebClient - Content-Type Override?
>>>>>>
>>>>>> I'm trying to act as a proxy to a third party webservice, and need to
>>>>>> transform a REST request. One issue that I have is that the
>>>>>> Content-Type header seems to get overridden no matter what I do. The
>>>>>> code is actually very simple (context is an @Context MessageContext
>>>>>> variable):
>>>>>>
>>>>>> WebClient client = WebClient.create(url)
>>>>>> .header("real-header-removed",
>>>>>> "auth-string-removed")
>>>>>> // .header("Content-Type",
>>>>>> context.getHttpHeaders().getMediaType().toString());
>>>>>> .type(context.getHttpHeaders().getMediaType());
>>>>>>
>>>>>> Response resp = client.get();
>>>>>> return (InputStream)resp.getEntity();
>>>>>>
>>>>>> Neither the .header nor the .type worked. The tcpmon output of the
>>>>>> request is:
>>>>>> Content-Type: */*
>>>>>> real-header-removed: auth-string-removed
>>>>>> Accept: application/xml
>>>>>> User-Agent: Apache CXF 2.3.5
>>>>>> Cache-Control: no-cache
>>>>>> Pragma: no-cache
>>>>>>
>>>>>> How do I avoid the content Type override (or rather, why is it
>>>>>> happening?)
>>>>>> Btw, while looking for answers, I found my CXF server side answers
>>>>>> relatively easily either via google or the archive. But client
>>>>>> questions seems to be rather rare, and mostly on the SOAP calls. Are
>>>>>> most people using other packages?
>>>>>>
>>>>>> thanks
>>>>>> Jeff
>>>>
>>>>
>>>>
>>>> --
>>>> Sergey Beryozkin
>>>>
>>>> http://sberyozkin.blogspot.com
>>>> Talend - http://www.talend.com
>>>
>>>
>>>
>>>
>>>
>>> --
>>> View this message in context: http://cxf.547215.n5.nabble.com/WebClient-Content-Type-Override-tp4640790p5765944.html
>>> Sent from the cxf-user mailing list archive at Nabble.com.
>>
>>
>> --
>> Sergey Beryozkin
>>
>> Talend Community Coders
>> http://coders.talend.com/
Re: WebClient - Content-Type Override?
Posted by Andrew Clark <an...@hotmail.com>.
Hi Sergey
Unfortunately we are currently restricted to using 2.x, we are currently on version 2.7.15.
Sent from my iPhone
> On 16 Feb 2016, at 17:49, "Sergey Beryozkin" <sb...@gmail.com> wrote:
>
> Hi Christian
>
> Starting with CXF 3.1.5 (or may be even 3.1.4) you should be able to set a custom Content-Type and it will go on the wire
>
> Cheers, Sergey
>> On 16/02/16 17:43, Christian wrote:
>> Hi Sergey,
>>
>> We are facing a similar issue; we are trying to send a GET with a
>> Content-Type header, as the service called requires it.
>>
>> Just wondering if the workaround with the interceptor is still required?
>>
>> We are trying to set a particular Content-Type (application/json), but it
>> gets stripped out at some point before the request gets sent, and the call
>> fails. Is that cxf's doing?
>>
>> Regards,
>> Christian
>>
>>
>>
>> Sergey Beryozkin wrote
>>> Ok, thanks for this info.
>>> You've found the workaround which is good, another option is to
>>> register a custom CXF out interceptor which would reset Content-Type
>>> to the required value, it can be registered with
>>> JAXRSClientFactoryBean:
>>>
>>> JAXRSClientFactoryBean bean = new JAXRSClientFactoryBean();
>>> bean.setAddress(address);
>>> bean.getOutInterceptors().add(new CustomOutInterceptor());
>>> bean.createWebClient();
>>>
>>> I'll try fix it as well
>>> Sergey
>>>
>>>
>>> On Sun, Jul 31, 2011 at 10:17 PM, Jeff Wang <
>>
>>> jeff.wang@
>>
>>> > wrote:
>>>> We're trying to use Amazon's query string authentication. We can set
>>>> Content-Type to "", or heck, to any other string. It's just that the
>>>> server uses the content type as part of its signature calculation. So
>>>> when we generate the signature, we expected to set it with some content
>>>> type (tried it with either "" or an actual type, it doesn't matter.) If
>>>> it gets overridden, like what happens with webClient.get(), then the
>>>> signatures will be wrong and auth will get rejected. The actual header
>>>> has no meaning in a GET, but we do need to control what it is so that the
>>>> signatures match.
>>>>
>>>> Jeff
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: Sergey Beryozkin [mailto:
>>
>>> sberyozkin@
>>
>>> ]
>>>> Sent: Sun 7/31/2011 11:00 AM
>>>> To:
>>
>>> users@.apache
>>
>>>> Subject: Re: WebClient - Content-Type Override?
>>>>
>>>> Hi,
>>>>
>>>> Does the server expect Content-Type being set even in case of GET
>>>> requests ?
>>>>
>>>> Cheers, Sergey
>>>>> On 28/07/11 22:45, Jeff Wang wrote:
>>>>> Looking through the code, it seems that if the body is null (which has
>>>>> to be the case considering it's a get, then the content type is
>>>>> overwritten with wildcards.
>>>>> Using client.invoke("GET",""); solved the problem for me.
>>>>>
>>>>> Jeff
>>>>>
>>>>> -----Original Message-----
>>>>> From: Jeff Wang [mailto:
>>
>>> jeff.wang@
>>
>>> ]
>>>>> Sent: Wednesday, July 27, 2011 5:29 PM
>>>>> To:
>>
>>> users@.apache
>>
>>>>> Subject: WebClient - Content-Type Override?
>>>>>
>>>>> I'm trying to act as a proxy to a third party webservice, and need to
>>>>> transform a REST request. One issue that I have is that the
>>>>> Content-Type header seems to get overridden no matter what I do. The
>>>>> code is actually very simple (context is an @Context MessageContext
>>>>> variable):
>>>>>
>>>>> WebClient client = WebClient.create(url)
>>>>> .header("real-header-removed",
>>>>> "auth-string-removed")
>>>>> // .header("Content-Type",
>>>>> context.getHttpHeaders().getMediaType().toString());
>>>>> .type(context.getHttpHeaders().getMediaType());
>>>>>
>>>>> Response resp = client.get();
>>>>> return (InputStream)resp.getEntity();
>>>>>
>>>>> Neither the .header nor the .type worked. The tcpmon output of the
>>>>> request is:
>>>>> Content-Type: */*
>>>>> real-header-removed: auth-string-removed
>>>>> Accept: application/xml
>>>>> User-Agent: Apache CXF 2.3.5
>>>>> Cache-Control: no-cache
>>>>> Pragma: no-cache
>>>>>
>>>>> How do I avoid the content Type override (or rather, why is it
>>>>> happening?)
>>>>> Btw, while looking for answers, I found my CXF server side answers
>>>>> relatively easily either via google or the archive. But client
>>>>> questions seems to be rather rare, and mostly on the SOAP calls. Are
>>>>> most people using other packages?
>>>>>
>>>>> thanks
>>>>> Jeff
>>>
>>>
>>>
>>> --
>>> Sergey Beryozkin
>>>
>>> http://sberyozkin.blogspot.com
>>> Talend - http://www.talend.com
>>
>>
>>
>>
>>
>> --
>> View this message in context: http://cxf.547215.n5.nabble.com/WebClient-Content-Type-Override-tp4640790p5765944.html
>> Sent from the cxf-user mailing list archive at Nabble.com.
>
>
> --
> Sergey Beryozkin
>
> Talend Community Coders
> http://coders.talend.com/
Re: WebClient - Content-Type Override?
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi Christian
Starting with CXF 3.1.5 (or may be even 3.1.4) you should be able to set
a custom Content-Type and it will go on the wire
Cheers, Sergey
On 16/02/16 17:43, Christian wrote:
> Hi Sergey,
>
> We are facing a similar issue; we are trying to send a GET with a
> Content-Type header, as the service called requires it.
>
> Just wondering if the workaround with the interceptor is still required?
>
> We are trying to set a particular Content-Type (application/json), but it
> gets stripped out at some point before the request gets sent, and the call
> fails. Is that cxf's doing?
>
> Regards,
> Christian
>
>
>
> Sergey Beryozkin wrote
>> Ok, thanks for this info.
>> You've found the workaround which is good, another option is to
>> register a custom CXF out interceptor which would reset Content-Type
>> to the required value, it can be registered with
>> JAXRSClientFactoryBean:
>>
>> JAXRSClientFactoryBean bean = new JAXRSClientFactoryBean();
>> bean.setAddress(address);
>> bean.getOutInterceptors().add(new CustomOutInterceptor());
>> bean.createWebClient();
>>
>> I'll try fix it as well
>> Sergey
>>
>>
>> On Sun, Jul 31, 2011 at 10:17 PM, Jeff Wang <
>
>> jeff.wang@
>
>> > wrote:
>>> We're trying to use Amazon's query string authentication. We can set
>>> Content-Type to "", or heck, to any other string. It's just that the
>>> server uses the content type as part of its signature calculation. So
>>> when we generate the signature, we expected to set it with some content
>>> type (tried it with either "" or an actual type, it doesn't matter.) If
>>> it gets overridden, like what happens with webClient.get(), then the
>>> signatures will be wrong and auth will get rejected. The actual header
>>> has no meaning in a GET, but we do need to control what it is so that the
>>> signatures match.
>>>
>>> Jeff
>>>
>>>
>>> -----Original Message-----
>>> From: Sergey Beryozkin [mailto:
>
>> sberyozkin@
>
>> ]
>>> Sent: Sun 7/31/2011 11:00 AM
>>> To:
>
>> users@.apache
>
>>> Subject: Re: WebClient - Content-Type Override?
>>>
>>> Hi,
>>>
>>> Does the server expect Content-Type being set even in case of GET
>>> requests ?
>>>
>>> Cheers, Sergey
>>> On 28/07/11 22:45, Jeff Wang wrote:
>>>> Looking through the code, it seems that if the body is null (which has
>>>> to be the case considering it's a get, then the content type is
>>>> overwritten with wildcards.
>>>> Using client.invoke("GET",""); solved the problem for me.
>>>>
>>>> Jeff
>>>>
>>>> -----Original Message-----
>>>> From: Jeff Wang [mailto:
>
>> jeff.wang@
>
>> ]
>>>> Sent: Wednesday, July 27, 2011 5:29 PM
>>>> To:
>
>> users@.apache
>
>>>> Subject: WebClient - Content-Type Override?
>>>>
>>>> I'm trying to act as a proxy to a third party webservice, and need to
>>>> transform a REST request. One issue that I have is that the
>>>> Content-Type header seems to get overridden no matter what I do. The
>>>> code is actually very simple (context is an @Context MessageContext
>>>> variable):
>>>>
>>>> WebClient client = WebClient.create(url)
>>>> .header("real-header-removed",
>>>> "auth-string-removed")
>>>> // .header("Content-Type",
>>>> context.getHttpHeaders().getMediaType().toString());
>>>> .type(context.getHttpHeaders().getMediaType());
>>>>
>>>> Response resp = client.get();
>>>> return (InputStream)resp.getEntity();
>>>>
>>>> Neither the .header nor the .type worked. The tcpmon output of the
>>>> request is:
>>>> Content-Type: */*
>>>> real-header-removed: auth-string-removed
>>>> Accept: application/xml
>>>> User-Agent: Apache CXF 2.3.5
>>>> Cache-Control: no-cache
>>>> Pragma: no-cache
>>>>
>>>> How do I avoid the content Type override (or rather, why is it
>>>> happening?)
>>>> Btw, while looking for answers, I found my CXF server side answers
>>>> relatively easily either via google or the archive. But client
>>>> questions seems to be rather rare, and mostly on the SOAP calls. Are
>>>> most people using other packages?
>>>>
>>>> thanks
>>>> Jeff
>>>
>>>
>>>
>>
>>
>>
>> --
>> Sergey Beryozkin
>>
>> http://sberyozkin.blogspot.com
>> Talend - http://www.talend.com
>
>
>
>
>
> --
> View this message in context: http://cxf.547215.n5.nabble.com/WebClient-Content-Type-Override-tp4640790p5765944.html
> Sent from the cxf-user mailing list archive at Nabble.com.
>
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/