[
https://issues.apache.org/jira/browse/CAMEL-7246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14029324#comment-14029324
]
Raúl Kripalani commented on CAMEL-7246:
---------------------------------------
Hi guys,
Sorry I didn't realise I was mentioned above.
Header propagation has always been a major plus of Camel, and also a major PITA
many times. I always recommend customers to implement a common
HeaderFilterStrategy to get rid of these oddities. After all, Camel is an
integration platform. We could be connecting camel-http accepting text/plain as
a consumer, with camel-cxfrs as a producer, dispatching to an endpoint that
requires JSON. It's quite normal for a mediation platform to have to
intermediate between two different wireformats. And unfortunately Camel is not
intuitive in this sense because of header propagation. You get this effect with
Content-Type, Accept, Accept-Encoding, Content-Length, etc. I've seen this
issue with many, many of these protocol headers which are normally calculated
automatically by the underlying stack.
Now – after this rant – let's discuss solutions ;-)
# Make it very clear in the documentation of "vulnerable" components that
headers are propagated and weird interactions like this one could happen.
# Suppress propagating these headers in all vulnerable components, by adjusting
their default header filter strategies => I would -1 this one because it's a
breaking change, and as a user I may want to know if the client sent JSON or
HTTP by inspecting the Content-Type.
# Make the suppression optional by providing a switch in all
HeaderFilterStrategies (not just HTTP). However, we have the problem of
deciding which headers to suppress and which not, and in what direction.
However, it gets complicated: I may not want to suppress the Content-Type in a
consumer when receiving the request, but I would like ignore any existing
Content-Type headers when I send back the response, so that the stack can
decide for itself – this is what would help the OP in this case.
As you can see, the level of customisation required to make any "auto-magic" or
"intelligent" logic work defeats the purpose of making it automatic in the
first place...
I'm sure there are many more creative solutions we can put to work. But I have
little time now to continue thinking :( Perhaps we could take a look at how
other frameworks handle this header propagation across adapters?
Hope this helps, and it doesn't confuse everybody more :)
Regards,
Raúl.
> [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)
