[
https://issues.apache.org/jira/browse/CAMEL-7246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14030401#comment-14030401
]
Sergey Beryozkin commented on CAMEL-7246:
-----------------------------------------
Hi Aki
Let me clarify the actual issue here briefly mentioned in my first comment
above.
Consider the fact that many clients expecting some data back add a redundant
wildcard Content-Type, for example:
Content-Type: */*
Accept: application/json, application/xml;q=0.8
and we have a JAX-RS method:
@Produces("application/xml", "application/json")
Only the runtime will know what the correct response Content-Type is here, even
in this simple case figuring out the correct response CT manually is not a good
idea.
CXF knows the response CT when it matched a request URI against a given request
method, still on the in chain, and saves it on the exchange as I noted above
for the out chain to set it.
But we have the incoming "*/*" overriding the correctly calculated response
Content-Type. Alexey described another scenario.
We can keep adding removeHeader() for Content-Type and Content-Length.
But is it ever a good idea to put these 2 incoming specific headers into the
outgoing CXF chain ?
Sergey
> [cxfrs] SimpleConsumer returns wrong Content-Type
> -------------------------------------------------
>
> Key: CAMEL-7246
> URL: https://issues.apache.org/jira/browse/CAMEL-7246
> Project: Camel
> Issue Type: Bug
> Components: camel-cxf
> Affects Versions: 2.12.2
> Reporter: Alexey Markevich
> Attachments: camel-cxfrs-content-type.zip
>
>
> Looks like Content-Type is taken from request
--
This message was sent by Atlassian JIRA
(v6.2#6252)
