oscerd opened a new pull request, #26183: URL: https://github.com/apache/camel/pull/26183
## Issue [CAMEL-24424](https://issues.apache.org/jira/browse/CAMEL-24424) ## Problem `VertxHttpRestHeaderFilterStrategy.applyFilterToCamelHeaders()` delegated to the wrong super method: ```java @Override public boolean applyFilterToCamelHeaders(String headerName, Object headerValue, Exchange exchange) { boolean answer = super.applyFilterToExternalHeaders(headerName, headerValue, exchange); return filterCheck(templateUri, queryParameters, headerName, answer); } ``` `applyFilterToExternalHeaders` consults the **inbound** filter, while the method implements the **outbound** direction. `VertxHttpHeaderFilterStrategy.initialize()` only populates the *out* filter (via `HttpUtil.addCommonFilters`), so on a REST producer that filter was never applied: a Camel message header named `Content-Length`, `Transfer-Encoding`, `Host`, `Connection`, `Via`, `Cache-Control`, `Date`, `Pragma`, `Trailer`, `Upgrade` or `Warning` was copied straight onto the outgoing HTTP request. The sibling REST strategies in `camel-http-common`, `camel-netty-http` and `camel-undertow` all delegate to the matching super method — `vertx-http` was the only one left with the mismatch. ## Investigation - The mismatch has been present since the class was introduced in `CAMEL-15283` (Vert.x HTTP client component); it is a copy-paste slip, not a deliberate decision. `CAMEL-20163` later factored the template/query token check out into `HttpUtil.filterCheck` but left the wrong delegation in place. - A sweep of every `super.applyFilterTo*` call site across `components/`, `core/` and `dsl/` confirms this was the last remaining direction mismatch. - The strategy is only installed when the route does **not** supply its own `headerFilterStrategy` (`VertxHttpComponent.createProducer`), so a custom strategy is unaffected. ## Fix Delegate to `super.applyFilterToCamelHeaders(...)`, matching every sibling component. ## Test `VertxHttpRestProducerHeaderFilterTest` drives a `rest:get:foo/{id}` producer bound to `vertx-http` against an `undertow` test server and asserts what actually reaches the wire: - `Via` and `Cache-Control` — excluded on the outbound direction, must not arrive - `id` — consumed by the URI template, must not be sent as an HTTP header as well (guards the existing `filterCheck` behaviour) - `X-Custom` — not filtered on either direction, must arrive Verified the test **fails before the fix** (`expected: null but was: "1.1 rogue-proxy"`) and passes after it. Full `camel-vertx-http` suite: 91/91 green. Full reactor build clean, no regenerated artifacts. `camel-rest` is added in test scope so the REST producer path can be exercised, mirroring what `camel-undertow` already declares for `UndertowProducerContentTypeTest`. ## Documentation Behaviour change documented in `camel-4x-upgrade-guide-4_23.adoc`. --- _Claude Code on behalf of oscerd_ 🤖 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]
