oscerd opened a new pull request, #25571: URL: https://github.com/apache/camel/pull/25571
Fixes [CAMEL-24418](https://issues.apache.org/jira/browse/CAMEL-24418). Companion to #25569 — same contract, different layer. ## Problem Four sites resolved property placeholders on the value of the `CamelHttpUri` **header**: | Site | Guarded? | |---|---| | `camel-http` `HttpMethodHelper.createMethod` | by `skipControlHeaders`, which defaults to `false` | | `camel-http-common` `HttpHelper.createMethod` | no | | `camel-http-common` `HttpHelper.createURL` | no — resolves on `CamelHttpUri` whenever the endpoint is not bridging | | `camel-undertow` `UndertowHelper.createMethod` | no | ```java uriString = exchange.getContext().resolvePropertyPlaceholders(uriString); ``` That header carries message content, while property placeholders are a route/configuration authoring feature resolved at build time on the endpoint URI written in the route — the same contract CAMEL-24282 restored for `toD` and `enrich`. Note **camel-http-common backs camel-servlet and camel-jetty**, so the two unguarded paths there reach considerably more deployments than the camel-http one that at least had an off switch. ## Deliberately not changed `UndertowHelper.createURL` still resolves placeholders, and that is intentional. Its URI comes either from the `CamelRestHttpUri` header — which sits inside the `Camel*` namespace and is therefore blocked on the inbound path by the default header filter — or from the endpoint URI, already resolved at build time. It is never message content. Folding it in for consistency is worth doing but is a separate change, so I left it visible rather than sweeping it in. Removing the calls left the `RuntimeExchangeException` import unused in two files; both removed. ## Tests `HttpUriHeaderPlaceholderTest` lives in camel-http, because camel-http-common has no `http` component registered and an endpoint cannot be created there. It covers both directions: - a placeholder in the header stays literal - a placeholder in the **endpoint URI** is still resolved, exactly as before One behaviour detail the test pins down: the literal token comes back **percent-encoded** (`%7B%7BsecretValue%7D%7D`) via `UnsafeUriCharactersEncoder`, like any other unsafe character in a header-supplied URI. ``` mvn test -Dtest=HttpUriHeaderPlaceholderTest # 2 passed mvn clean install -DskipTests # full reactor, BUILD SUCCESS ``` ## Backport **main only**, matching CAMEL-24282 and #25569. Behaviour change, upgrade-guide entry included. --- _Claude Code on behalf of -- 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]
