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: > [email protected] >> 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: > [email protected] >>> 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.
