davsclaus opened a new pull request, #28991: URL: https://github.com/apache/camel/pull/28991
Fixes [CAMEL-26508](https://issues.apache.org/jira/browse/CAMEL-26508). ## What was wrong With `transferExchange=true` the TCP consumer first set the headers it derives from the connection (`CamelNettyRemoteAddress`, `CamelNettyLocalAddress`, `CamelNettyChannelHandlerContext`, `CamelNettySSLSession` and, with `sslClientCertHeaders=true`, the `CamelNettySSLClientCert*` headers) in `NettyEndpoint.updateMessageHeader`. Then `NettyPayloadHelper.setIn` unmarshalled the received `DefaultExchangeHolder`, and `DefaultExchangeHolder.unmarshal` replaces all in headers with the ones of the transferred exchange and merges its exchange properties. So the route saw the connection headers of the transferred exchange, not the ones of the connection the consumer accepted. ## What changed With `transferExchange` the consumer keeps its own connection headers: the connection it accepted is the source of truth. - `NettyPayloadHelper.setIn` / `setOut` unmarshal a holder through a new private `unmarshal` method: it keeps the connection headers and exchange properties the receiving side set before (so the values `NettyEndpoint.updateMessageHeader` derived from the connection, no duplicated code), removes the connection headers/properties that came with the transferred exchange (in and out message, and properties), and sets the kept values again. A connection header in the transferred exchange is not kept when the receiving side has no value for it (for example no client certificate on the connection, so no `CamelNettySSLClientCert*` headers). - Keys: `CamelNettyChannelHandlerContext`, `CamelNettyMessageEvent`, `CamelNettyRemoteAddress`, `CamelNettyLocalAddress`, `CamelNettyChannel`, `CamelNettySSLSession`, `CamelNettySSLClientCertSubjectName`, `...IssuerName`, `...SerialNumber`, `...NotBefore`, `...NotAfter`. - UDP: the envelope path calls the same method, and still sets the sender address as header and property afterwards, as before. - Client side (`ClientChannelHandler` -> `NettyPayloadHelper.setOut`/`setIn` with a transferExchange reply): same pattern, so it applies there too. The producer does not set connection headers on a reply, so the reply no longer carries connection headers from the consumer's exchange; connection headers the request message already had (for example from an upstream netty consumer) are kept. - `transferExchange` option description (`NettyConfiguration`) says the connection headers are always the ones of the receiving side. ## Tests `NettyTransferExchangeConnectionHeadersTest` (both fail without the change): - TCP + `transferExchange`: the sender's exchange carries String `CamelNettyRemoteAddress`, `CamelNettyLocalAddress`, `CamelNettySSLClientCertSubjectName`, `CamelNettySSLClientCertSerialNumber` headers and a `CamelNettyRemoteAddress` property. The route sees the consumer's `InetSocketAddress` values, no client cert headers and no such property; a normal header is kept. The reply the producer gets has no `CamelNettySSLClientCertSubjectName` set by the consumer route. - SSL + `needClientAuth=true` + `sslClientCertHeaders=true` + `transferExchange`: the sender sets its own `CamelNettySSLClientCert*` headers; the route sees the subject, issuer and serial number of the real client certificate. Full `camel-netty` suite with `-Psourcecheck`: 148 tests, 0 failures (9 skipped). ## Docs and generated files - Regenerated `netty.json` / `netty-http.json` (component and catalog) and the endpoint/component DSL builders for the new option description (`netty-http` shares `NettyConfiguration`). - Upgrade guide 4.24: new `camel-netty` entry. ## Not changed - `DefaultExchangeHolder` in `camel-support` is unchanged. - Control headers such as `CamelNettyCloseChannelWhenComplete` and `CamelNettyRequestTimeout` are not connection headers and are still taken from the transferred exchange. - #28985 (CAMEL-26504) changes `NettyPayloadHelper.getIn`/`getOut` to leave the transport headers out when marshalling. The two are complementary: that PR covers the sending side, this one the receiving side, which also covers a sender without that change and the `CamelNettySSLClientCert*` headers. The `#28985` patch applies on top of this one without conflict; once both are merged the two key lists could be merged into one. _Claude Code on behalf of Claus Ibsen (davsclaus)_ 🤖 Generated with [Claude Code](https://claude.com/claude-code) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
