[
https://issues.apache.org/jira/browse/CAMEL-26508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18136816#comment-18136816
]
Claus Ibsen commented on CAMEL-26508:
-------------------------------------
PR: https://github.com/apache/camel/pull/28991
With transferExchange the consumer keeps its own connection headers (the
connection it accepted is the source of truth): the connection headers and
properties are set again after the received exchange is unmarshalled, and the
ones in the transferred exchange are not kept, also when the consumer has no
value for them. The producer receiving a transferExchange reply does the same.
Option description and upgrade guide updated.
_Claude Code on behalf of Claus Ibsen (davsclaus)_
> camel-netty - with transferExchange the consumer keeps its own connection
> headers
> ---------------------------------------------------------------------------------
>
> Key: CAMEL-26508
> URL: https://issues.apache.org/jira/browse/CAMEL-26508
> Project: Camel
> Issue Type: Improvement
> Components: camel-netty
> Reporter: Claus Ibsen
> Assignee: Claus Ibsen
> Priority: Major
> Fix For: 4.24.0
>
>
> With transferExchange=true the TCP consumer first sets the headers it derives
> from the connection (CamelNettyRemoteAddress, CamelNettyLocalAddress and,
> with a client certificate, the CamelNettySSLClientCert* headers), and then
> unmarshals the received exchange, which replaces all headers with the ones in
> the transferred exchange.
> The connection headers describe the connection the consumer itself accepted,
> so they should stay the values of the consumer: set them again after the
> exchange is unmarshalled, and do not take CamelNetty* transport headers from
> the transferred exchange. Document this on the transferExchange option.
> _Claude Code on behalf of Claus Ibsen (davsclaus)_
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
