One Star

cCXFRS override content-type and accept headers

Hi,
Is there any way of overriding content-type and accept header values ? I need to set those values so something custom (application/json;odata=verbose), and cannot find how to do that. If I use a cSetHeader in the route, it gets overriden by the values from the cCXFRS component.
Any ideas ? Thanks ...
PS : The same is true when I use the tRestClient in a job : in the tRestClient, I can set custom headers in the "Advanced settings", but when I try to set accept and content-type, the content-type is overriden by the component, and I get 2 values for the accept (application/json and application/json;odata=verbose)
6 REPLIES
One Star

Re: cCXFRS override content-type and accept headers

Hello
using Mediation Routes you should be able to set the CamelContentType header
g.
One Star

Re: cCXFRS override content-type and accept headers

Hi gusto2,
Could you explain a bit more ?
I am using mediation routes. I have tried several ways to set those headers, but they always get overriden by the cCXFRS component...
Employee

Re: cCXFRS override content-type and accept headers

Hi,
As far as tRestClient is concerned, I can not reproduce the duplication of Content-Type at Apache CXF level which is used internally by tRESTClient. Specifically, tRESTClient does webClient.type(contentType) and then it iterates over all the extra headers and calls webClient.header(name, value). I created a local test and was able to update Content-Type. 
Accept is accumulating the values, but it can contain multiple values.
Can you try setting Accept to ANY, but also to a specific value in the extra headers ? You will get a wildcard media type followed by a concrete type, which is reasonable, example, browsers always include a wildcard alongside more concrete types though browsers do allocate a low 'qs' to a wildcard
Try it please, Sergey
One Star

Re: cCXFRS override content-type and accept headers

Hi Sergey,
Thanks for your answer. I had already tried that.
Unfortunately, I am using Sharepoint REST API, and it seems to be extra "careful" about the value of the accept header. It wants to get "application/json;odata=verbose", and nothing else (I could verify that using another rest client, I always get a 406 error). So your solution does not work in my specific use case. Although I am pretty sure it can work in other cases.
One Star

Re: cCXFRS override content-type and accept headers

Hi,
is there any progress regarding this topic?
I'm also having a cCXFRS -> cCXRRS -> cProcessor route in mediation
When checking the headers in cProcessor after getting/forwarding the request to the target system, there is no Content-Type filled in. Even if it is filled in manually in cProcessor (exchange.getIn().setHeader("Content-Type","application/zip")Smiley Wink, the final response raw data does have this parameter overriden to "Content-Type: application/octet-stream" and all the other parameters are gone.
So far, I've managed to make a workaround in Integration perspective, with a job that looks like:
tRESTRequest -> tJavaRow -> tFileFetch -> tFileInputRaw -> tRESTResponse
and on the tRESTResponse component, in the Component -> Advanced settings, I've added multiple Response headers, which appear in the final response of the service.
One Star

Re: cCXFRS override content-type and accept headers

Hi,
I am having a similar issue. I am sending custom headers from Salesforce. Google Chrome Rest Client will see them correctly but when doing the GET request with tRestClient component the custom headers won't appear on response header. I have tried adding them into HTTP headers section without any result.
Any glues how this should work?
Regards
Peter