[
https://issues.apache.org/jira/browse/CAMEL-7246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14029324#comment-14029324
]
Raúl Kripalani edited comment on CAMEL-7246 at 6/12/14 4:26 PM:
----------------------------------------------------------------
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 fully control and lock down possible 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. Different wire formats, i.e. different
Content-Types and Accepts at each edge.
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.
was (Author: raulvk):
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)
